discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Nick Foster
Subject: Re: [Discuss-gnuradio] performance improvements and using volk
Date: Tue, 8 Nov 2011 20:46:58 -0800

On Tue, Nov 8, 2011 at 6:16 PM, Marcus D. Leech <address@hidden> wrote:
> 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.

That's kinda what Volk is for, actually. It decides at runtime which
implementation to use, depending on what architecture you're running
and what implementations are available. There's even a volk_profile
utility which profiles each implementation and writes a "hints" file
to select the fastest on your machine. In the absence of the
volk_prefs file Volk will make an educated guess. Since all Volk
blocks include a "generic" C++ fallback implementation, when you Volk
up a block it doesn't matter if there's an accelerated version for
your platform or not; it will fall back gracefully to the generic
implementation.

--n

>
> 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
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



reply via email to

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