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