Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate

[Philip Balister]

On 01/24/2012 01:43 PM, ziyang wrote:
> On 01/24/2012 07:12 PM, Nick Foster wrote:
>> On Tue, Jan 24, 2012 at 9:56 AM, ziyang <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>>     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?
>>
>>
>> Very likely. Make sure that orcc is somewhere that pkgconfig can find
>> it, and make sure its version is > 0.4.10.
> 
> This is what it shows when I run a "opkg list-installed | grep orc" check:
> 
> liborc-0.4-0 - 0.4.16-r1.0.9
> liborc-test-0.4-0 - 0.4.16-r1.0.9
> orc - 0.4.16-r1.0.9
> 
> I don't understand why orc/liborc cannot be detected by CMake. The
> options for CMake are:
> 
> cmake -DCMAKE_INSTALL_PREFIX=/usr
> -DCMAKE_CXX_FLAGS:STRING="-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp
> -g" -DCMAKE_C_FLAGS:STRING="-mcpu=cortex-a8 -mfpu=neon
> -mfloat-abi=softfp -g" ../
> 
> Could you tell me what might be the problem? Thanks.

Add -DENABLE_ORC=ON to the cmake command line.

Philip

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