Re: [Discuss-gnuradio] performance improvements and using volk

[Marcus D. Leech]

On 08/11/11 09:08 PM, Josh Blum wrote:
> Hey list,
>
> I have been itching to make some new gnuradio blocks that make use of
> volk. So to avoid disturbing the delicate balance of code in
> gnuradio-core, I have produced a new component called gr-basic.
>
> The goal of gr-basic is to replace many of the blocks in gnuradio-core
> with vector optimized blocks that call into volk; and to make it easy
> for users to extend blocks to support new data types. You can see the
> branch here: http://gnuradio.org/cgit/jblum.git/log/?h=gr_basic
>
> So far, gr-basic has the familiar add, multiply, subtract and divide
> block, but with 2 major differences:
>
> 1)
> It is very easy to add new data types to these blocks. So it doesn't
> suffer from the confusing code generation or naming convention issues
> with the existing adder. So rather than generating gr_add_* for each
> data type, there is one block add, which takes as a parameter, the data
> type.
>
> 2)
> Some of the adder implementations use volk routines. We happened to
> already have a volk routine for adding floats, so rather than calling
> into the generic implementation, we call into a work function that calls
> the volk add routine, seen here:
> http://gnuradio.org/cgit/jblum.git/tree/gr-basic/lib/gr_basic_add.cc?h=gr_basic#n45
>
> Just as a rough benchmark, you can expect a 30% savings in overhead from
> the adder (tested on a sse machine).
>
> I hope that this gives users a good starting point for optimizing
> gnuradio blocks with volk!
>
> -Josh
>
>   
Once again, Josh posts evidence that he's actually a consortium of
tightly-cooperating
  cerebella, rather than a single entity :-)

Cool stuff here, Josh.  I like numbers like "30% savings".  Those are
good numbers. 

One of my thoughts today about the VOLK thing is that GRC might easily
decide at generate-time
  whether to satisfy a basic block with "standard" or "volked"
routines.  Maybe even at runtime.

The performance envelope is going to get more and more interesting now
that 8-bit sampling has arrived
  with USRP hardware.  I should probably try an 8-bit 50Msps uhd_fft.py
at some point, on my 6-core AMD
  machine to see if it can do it at all.

-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org