Re: [LAU] OT(ish): Strange coding problem (audio related)

From: Philipp Überbacher <hollunder@email-addr-hidden>
Date: Sun Jan 30 2011 - 15:46:21 EET

Excerpts from fons's message of 2011-01-29 13:46:19 +0100:
> On Sat, Jan 29, 2011 at 01:22:10PM +0100, Philipp Überbacher wrote:
>
> > I thought that log2() might use a different routine if the argument is a
> > power of 2. I guess that even if it does it's nothing to rely on because
> > another libm implementation might not do the same thing.
>
> There are very good reasons why math routines don't do such things.

What are those?

> > Why did you choose 1e-6 specifically?
>
> It does the job. 1e-6f will also work for single precision.
>
> > ... Without optimisation the output is quite
> > different, but beginning with -O2 the machine code appears all the same.
>
> That could well be completely different on an another CPU and compiler,
> and even more so if tested ***in context***. Such tests are really
> pointless, in particular if you consider the actual use of this code.
> It isn't executed 100 times for each audio sample.

Thanks, I see this now after Peter did another test with quite different
results. I looked at it out of context because I simply don't understand
the context. I only know what a ft does but not how it works, nor have I
implemented a fft, so the code with its two-letter variables is
meaningless to me.

> > If the optimised code really is the same is it worth it to use funky bit
> > shifting operations?
>
> There's nothing funky about them, they are part of C and C++.

They were funky to me mainly because I had to look them up but also
because operating on the bit representation requires a different mode of
thinking. I bet it also has its own set of pitfalls.
It's quite interesting that it still seems to make a difference
performance-wise. Thanks for your insights.

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sun Jan 30 16:15:05 2011

This archive was generated by hypermail 2.1.8 : Sun Jan 30 2011 - 16:15:05 EET