Re: [Discuss-gnuradio] Using volk kernels on basic operations of gr_complex, in my own custom blocks.

[West, Nathan]

It won't give you time spent, but 'perf top' is a nice tool that gives function-level performance counters for all running code. It comes with linux-tools and uses performance counters built in to the kernel. There's also a couple of other perf subtools you can explore.

Regarding your full buffers, I think that's a result of GNU Radio's scheduler.

 If you have a flowgraph with A->B and B takes a very long time to process all of its samples then A will always have full output buffers since it operates much faster. It's not necessarily bad or cause for concern, but performance improvements should focus on B.

-nathan

On Sun, Feb 28, 2016 at 10:48 PM, Gonzalo Arcos <address@hidden> wrote:

Thanks to all of you for your very informative answers.

Douglas, i feel good now because you have described perfectly all the things i did / thought on how to improve the performance :), i also agree that merging blocks should be a last time resort. I have used the performance monitor and managed to improve the perofrmance of the most expensive blocks. What i could not achieve though, is profiling the program with a mainstream profiler, like valgrind or oprofile, or some other profilers for python. I remember than when visualizing the data, all the time was spent in the start() of the top block, and i could not get information pertaining each blocks general work, let alone functions executed within the block. After discovering the performance monitor, i used it in conjuntion with calls to clock() to determine the time spent in each function within each block, to get a rough measurement. But if it is possible to get this information automatically, i am very interested in learning how to do it. Could you help me?

There is also another interesting aspect of improving performance, which is blocks being blocked due to the output buffer being full. Ive tried playing around a bit with the min and max output buffer sizes, but the performance did not seem to be affected.

After using the performance monitor to analyze the buffer average full %, i see that most of them are relatively full, however, i do not know if they are full enough to make an upstream block to have to wait to push data into the buffer.

2016-02-28 19:39 GMT-03:00 Douglas Geiger <address@hidden>:

The phenomenon Sylvain is pointing at is basically the fact that as compilers improve, you should expect the 'optimized' proto-kernels to no longer have as dramatic an improvement compared with the generic ones. As to your question of 'is it worth it' - that comes down to a couple of things: for example - how much of an improvement do you require to be 'worth it' (i.e., how much is your time worth and/or how much of an performance improvement do you require for your application). Similarly, is it worth it to you to get cross-platform improvements (which is one of the features of VOLK)? Or, perhaps, is it worth it to you just to learn how to use VOLK?

A couple of thoughts here: in general, when I have a flowgraph that is not meeting my performance requirements, my first step is to do some course profiling (i.e. via gr-perf-monitorx) to determine if there is a single block that is my primary performance bottleneck. If so - that is the block I will concentrate on for optimizations (both via VOLK, and/or any algorithmic improvements - e.g. can I turn any run-time calculations into a look-up table calculated either at compile-time, or within the constructor).

 If there is not a clear bottleneck, then next I look a little deeper using perf/oprofile to look at what functions my flowgraph is spending a lot of time in: can I e.g. create a faster version of some primitive calculation that all my blocks use a lot, and therefore get a speed-up across many blocks which should translate into a fast over-all application.

 Finally, if I still need more improvements I would look at collecting many blocks together into a single, larger block. This is generally less desirable, since you now have a (more) application-specific block, and it becomes harder to re-use in later projects, but if you have performance requirements that drive you there, then it absolutely is an option. At this point you likely have multiple operations being done to your incoming samples, and it becomes easy to collect all of those into a single larger VOLK call (and from there, create a SIMD-ized proto-kernel that targets your particular platform). So, while re-usability of code drives you away from this scenario, it offers the greatest potential for performance improvements, and thus is where many applications with high performance requirements tend to gravitate towards. Ideally you can strike a balance between the two: i.e. have widely re-usable blocks, but with a set of operations inside them that you can take advantage of e.g. SIMD-ized function calls to make them high-performance. If you can craft the block to be widely re-usable for a certain class of things (e.g. look at how the OFDM blocks are setup to be easily re-configurable for the many ways an OFDM waveform can be crafted). In the long-run having more knobs to turn to customize your existing code base to deal with whatever new scenario you are looking at in 1/2/10 years from now is always better than a brittle solution that solves today's problem, but is difficult to re-use to deal with tomorrow's.

Hope that was helpful. If you are interested in learning more about how to use VOLK - certainly have a look at libvolk.org - the documentation is (I think) fairly good at introducing the concepts and intent, as well as how the API looks/works. And certainly don't be shy about asking more questions here.

 Good luck,

  Doug

On Sun, Feb 28, 2016 at 1:58 AM, Sylvain Munaut <address@hidden> wrote:

> Just wanted to ask the more experienced users if you think this idea is
> worth a shot, or the performance improvement will be marginal.

Performance improvement is vastly dependent of the operation you're doing.

You can get an idea of the improvement by comparing the volk-profile
output for the generic kernel (coded in pure C) and the sse/avx ones.

For instance, on my laptop : for some very simple one (like float
add), the generic is barely slower than simd. Most likely because it's
so simple than even the compiler itself was able to simdize it by
itself.
But for other things (like complex multiply), the SIMD version is 10x faster ...


Cheers,

   Sylvain

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--

Doug Geiger
address@hidden

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio