30 Jan
2011
30 Jan
'11
2:46 p.m.
Excerpts from fons's message of 2011-01-29 13:46:19 +0100:
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.
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.
On Sat, Jan 29, 2011 at 01:22:10PM +0100, Philipp
Überbacher wrote:
What are those?
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. 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. 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++.