discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] blocks.complex_to_arg() implementation


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] blocks.complex_to_arg() implementation
Date: Thu, 14 Aug 2014 09:10:11 -0400

On Thu, Aug 14, 2014 at 5:15 AM, Daniele Nicolodi <address@hidden> wrote:
On 13/08/2014 16:37, Tom Rondeau wrote:
> The version we have in there is much (MUCH) faster than the libm atan2
> function. So yes, we trade off a bit of error for a massive
> computational gain. The error is very small from what I recall, expect
> in a few instances (near 0 or near pi/2 or something like that). Having
> a graph of the error somewhere would be helpful.

I think it depends on the point of view, for me it is a bit of
computational gain for a massive error :)


You say "massive error", but I've plotted the error between the fast atan and the libm atan function before and have not noticed any error to be "massive". On the other hand, the "bit" of computational gain is, indeed, quite a lot.

 
> The fast atan method we use is still faster than what we have in VOLK. I
> remember testing this out myself, which included putting that code into
> the constructor. However, take a look at this post:
>
> http://www.trondeau.com/blog/2012/2/17/volk-benchmarking.html

I don't see anything specific to the atan2() and alignment there.

Nothing specific to the atan function. The post shows that changing from not using alignment to using alignment provides a boost in performance even before adding actual calls to VOLK. That's what the difference between the red and blue bars shows.

Tom

 
> We see an improvement in speed of blocks by doing the alignment.
> Actually, I think that all blocks should probably have their alignment
> set whether or not they use VOLK. But that would be a lot of work to do
> correctly with all of our blocks to make sure it's done right and is
> actually giving us a benefit. But having test this one in particular,
> no, I don't see any need to remove this code.

I see. Probably a comment in the code mentioning this, to avoid other
being puzzled, is in order here :)

Cheers,
Daniele



reply via email to

[Prev in Thread] Current Thread [Next in Thread]