[Top][All Lists]

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

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

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] performance improvements and using volk
Date: Tue, 8 Nov 2011 21:58:14 -0500

On Tue, Nov 8, 2011 at 9:08 PM, Josh Blum <address@hidden> 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:

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

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:

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!


So I like everything about this but the name.  We could stuff all of this under the "gnuradio.gr" namespace in Python, or we could name this "gr-math."

Actually, while I was typing this, I'm thinking we rename the directory to be "gr-blocks" but put them under the "gnuradio.gr" namespace. I'm expecting that since you've used different names for the blocks because of the data-type handling that they won't collide with what's in guradio-core right now.



reply via email to

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