Performance improvements and using volk

GNU Radio
#1

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
type.

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

#2

On 08/11/11 09:08 PM, Josh B. wrote:

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 :slight_smile:

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

#3

On Tue, Nov 8, 2011 at 9:08 PM, Josh B. [email protected] wrote:

I hope that this gives users a good starting point for optimizing
gnuradio blocks with volk!

-Josh

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.

Thanks!
Tom

#4

On Tue, Nov 8, 2011 at 6:58 PM, Tom R. [email protected]
wrote:

for users to extend blocks to support new data types. You can see the
type.
the adder (tested on a sse machine).
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.
Thanks!
Tom

The best part is it took Josh and I longer to figure out what to call
it than it took Josh to code it up.

–n

#5

On Tue, Nov 8, 2011 at 6:16 PM, Marcus D. Leech [email protected]
wrote:

branch here: http://gnuradio.org/cgit/jblum.git/log/?h=gr_basic

I hope that this gives users a good starting point for optimizing
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

#6

I just added a gr_basic_add_const and gr_basic_multiply_const. Nick
added the volk (and orc) implementations for the float32 and complex
float32 implementations of the multiplier.

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

Trying to avoid math so from gnuradio import math doesnt interfere with
python’s math import. Thats unfortunate, but I think this will be nicer
with the python namespace changes you mentioned.

#example import:
from gnuradio import gr
gr.filter.fir_interp(…)
gr.math.add(…)
gr.digital.costas_loop(…)

Was that the goal? I think we can make this happen without too much
trouble

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.

So, my thoughts were: make new blocks that replicate the functionality
in gr-core like filters, adders, etc. We dont delete the old blocks, so
the API doesn’t change. But if you want the performance improvement, you
use the new blocks.

Hopefully with these new blocks, we use volk where applicable, use new
naming convention to make it easier to fit alternative data types, and
avoid generation when possible.

Eventually, gnuradio-core becomes nothing but the block framework and
runtime. gr-filter takes the filter implementations and gr-<???> takes
the very basic blocks like simple math operators, type conversions, and
stream conversions.

Hows that sound?

-Josh

#7

On Wed, Nov 9, 2011 at 5:25 PM, Josh B. [email protected] wrote:

to
gr.math.add(…)
gr.digital.costas_loop(…)

Was that the goal? I think we can make this happen without too much trouble

Yeah, this should be easy. But I think most people are pretty used to
“from
gnuradio import something”, so you’re right about the potential problems
of
a collision between gr.math and math.

The goal? To allow for easy development and control over properly
segmented
groups of blocks without driving the users crazy by constantly changing
or
adding new groups. That’s one reason why I think stuffing everything in
your gr-basic into the gr namespace, so people would still have the
familiar “from gnuradio import gr” way of getting to most of the core
blocks.

Agreed. Eventually, we’d want to get rid of the old blocks (reduce
cruft,
etc). Of course, that’d be a huge api change since these are blocks
used
frequently for many tasks.

Hopefully with these new blocks, we use volk where applicable, use new
naming convention to make it easier to fit alternative data types, and
avoid generation when possible.

No disagreement there.

Eventually, gnuradio-core becomes nothing but the block framework and
runtime. gr-filter takes the filter implementations and gr-<???> takes
the very basic blocks like simple math operators, type conversions, and
stream conversions.

Hows that sound?

-Josh

I’d say that gnuradio-core would also contain a few blocks that are
really
only used for development/testing purposes (gr_nop, gr_annotator, etc.).
But I otherwise agree.

I’m still advocating for gr-basic to become gr-blocks as the place for
all
of the generic blocks to go into, but they would be installed in gr.

Tom