Re: [Discuss-gnuradio] Speed Optimization and Application for ATSC Receivers

[West, Nathan]

Hi Josh,

Glad you're interested in GSoC and GNU Radio.  These suggestions from Andy are pretty good, and any work that you've done on or with GNU Radio by the time we make decisions definitely improves the credibility and strength of your application (that's true for *all* students by the way... it really helps to show us that you've done *anything* with GNU Radio). Now I will add some commentary :-).

Valgrind is a really fantastic debugging tool, but I've found it to be mostly useless for performance profiling (maybe I'm using it wrong and someone can school me) because it runs everything in this slow environment that traces all memory accesses and whatever else valgrind does. oprofile is pretty good, but I'm a huge fan of the perf-tools that come with the kernel like perf top and perf record.

On Sun, Mar 6, 2016 at 4:08 PM, Andy Walls <address@hidden> wrote:

On Sun, 2016-03-06 at 08:49 -0500, address@hidden
wrote:
> Message: 5
> Date: Sun, 06 Mar 2016 06:45:13 +0000 (GMT)
> From: Joshua Lilly


> Hello,
> My name is Josh and I am interested in getting involved in GNU radio.
> Specifically, I would like to work on the above project idea for
> google summer of code 2016 by implementing Viterbi and demux
> algorithms in volk and testing the speed improvements. I have
> experience with python, c/c++, boost, and profiling with valgrind. I
> currently have read the getting involved page, compiled the code, I am
> working my way through some of the tutorials, and I have read through
> the code in volk. Even if I don't get accepted to google summer of
> code, I would still like to get involved in fixing bugs, or something
> since this seems like a really awesome project.

4. Create volk kernels to replace the main operations in the work()
functions of these blocks, if you can.  Since adding a constant is so
simple, and ORC is very good about optimizing simple things, the volk
implementations should include an ORC implementation if possible.  Odds
are the ORC implementation will beat hand-written SIMD versions for x86
processors.  Use volk_profile to prove my guess about ORC right or
wrong. :)

I disagree to that point that the next time ORC makes me sad I'm going to rage-delete it from ORC (kidding). It's an OK starting point for some kernels, but comes with it's own learning curve on top of everything else in VOLK.

 

5. Create volk-ized versions of the add_const blocks and remeasure their
performance.  How much improvement did you get?


6. Don't forget to add QA tests for the new volk functions.
 

As an alternate to the above:

1. Improve the performance of the nlog10_ff block by using log2,
algebra, volk, and skipping the add of k at the end, if k == 0.0.

2. Create a new approx_nlog10_ff block by taking advantage of the fact
that the log2 exponent in IEEE floats can be obtained with a mask and
shift operation.  Don't forget to add a GRC .xml file for the block and
QA test code.

Regards,
Andy

By the way, if you choose to do this please don't be afraid to ask questions; this is a pretty well defined problem, but also very dense with GNU Radio and VOLK assumed knowledge (it's sometimes hard to talk about such things without doing this). Take a look at the VOLK docs, especially the top-level pages, to get started http://libvolk.org/doxygen/index.html

Also, now that I mention that link, I noticed a very simple bug! The polar {de,en}coder kernels didn't get listed in the kernels page so they show up in the top level page listing.

Cheers,

Nathan