discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Volk


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Volk
Date: Mon, 13 Dec 2010 12:29:36 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7

Hey Tom,

Great work implementing the libvolk. I had a chance to take a peek at
the implementation, so now I have constructive criticism. :-)

I see that the various vector functions are all implemented in headers,
and at compile time, a python application generates them into the table
look-up-code. I would like to purpose an alternative for registering the
functions that is a little more modular.

Ideally, the functions should register themselves automatically into the
volk registry (and this would happen dynamically at runtime). That way,
you can put the implementations into their own respective c++ files that
are fully encapsulated and just list them into the library sources. In
addition, users of gnuradio could register their own vectorized
implementations into volk for out-of-tree private projects. And, this
may make it easier to integrate liborc.

So let me go about the primitives

---------------------------------------------------
-- registering a function
---------------------------------------------------
//vectorized adder.cc

static void add_ff_v(data in0, data in1, data out){
        //impl here
}

STATIC_BLOCK(register_add_fcn_this_arch){
        volk_register_fcn(<tag name>, <arch type>, &add_ff_v);
}

...and so on

Now, the static block is a macro that creates and instantiates an object
for the purpose of static initialization. Example in UHD:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/include/uhd/utils/static.hpp#L31

---------------------------------------------------
-- The function registry
---------------------------------------------------
The function registry is essentially a dictionary mapping tags to a
dictionary of architectures to function pointers. Whenever volk_register
is called, its adds an entry into the registry.

Now there should also be a function to access the registry.
volk_get_fcn(<tag name>) would grab a pointer to the most efficient
implementation, and then be cast from void * to whatever is useful.

This isnt the same as just calling a function from a header. Since
volk_get_fcn would have overhead, it should not be called in the fast
path, but once at initialization int he block's constructor to extract
the function pointer.

As an alternative to fetching the function pointer, you might instead
fetch a opaque table object that has the reference to a set of
vectorized functions. It may be useful to select among functions at
runtime based on alignment of the input data. I think liborc does this.

---------------------------------------------------
-- Tag names
---------------------------------------------------
This goes back to the same debates about tag names for the tags
streaming interface stuff. In any case, it just has to be something
identifiable. It could be enums. I would just make it strings (since its
out of the fast path), where a set of functions and their usage
implementation agrees on a string name. A string would be an identifying
signature like add_v_f32_......

Let me know what you think,
-Josh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]