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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
