On 01/19/2012 07:13 PM, Nick Foster wrote:
Optimizing an algorithm is a hard and sometimes counterintuitive
process. You might benchmark the following:
- Gnuradio's atan2 WITHOUT any Volk multiplications (just comment out
the volk mults in your block)
- The Volk multiplications WITHOUT Gnuradio's atan2 (just comment out
the atan2 in your block)
This will let you determine where the bottleneck is. In addition, try
running over a MUCH larger dataset. The clock resolution at <1ms is
not very good and the scheduler will have a correspondingly larger
effect at smaller timescales.
I think you'll find the atan2 part takes vastly longer than the
multiplications do, and that will be where you have to look for
performance improvements.
--n
Hi Nick,
I have been doing some tests about the demodulation module. As you said,
the atan2 part takes much longer than the multiplication. So in order to
maximize the performance improvement that volk could bring to the
processing, I took a division and a multiplication out of atan2, and use
volk-ified divider and multiplier instead. Then I run tests using a much
larger dataset.
But from the test results, I did not observe a performance improvement.
In fact, the average processing time even increase a little bit. So I
was wondering if what I did was not a good way to improve the performance?
Another issue is that when I ran Cmake to build Gnuradio on E100, it
reported this:
-- Available arches: generic;neon
-- Available machines: generic;neon
-- Did not find liborc and orcc, disabling orc support...
But from the "opkg list-installed | grep orc" check, both orc and liborc
are installed. Could this lack of orc support be part of the reason why
my implementation did not have a performance improvement?
I will appreciate it if you could give me a hand on this. Thanks.
Best Regards,
Terry
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio