On Friday, 24 May 2019 at 17:04:33 UTC, Alex wrote:
On Friday, 24 May 2019 at 13:57:30 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 24 May 2019 at 12:24:02 UTC, Alex wrote:
If it truly is a 27x faster then then that is very relevant
and knowing why is important.
Of course, a lot of that might simply be due to LDC and I
wasn't able to determine this.
Just one more thing you really ought to consider:
It isn't obvious that a LUT using double will be more precise
than computing sin using single precision float.
So when I use single precision float with ldc and "-O3
-ffast-math" then I get roughly 300ms. So in that case the LUT
is only 3 times faster.
Perhaps not worth it then. You might as well just use float
instead of double.
The downside is that -ffast-math makes all your computations
more inaccurate.
It is also possible that recent processors can do multiple
sin/cos as simd.
Too many options… I know.
The thing is, the LUT can have as much precision as one wants.
One could even spend several days calculating it then loading
it from disk.
With linear interpolation of what is effectively a discrete time
signal, you get an extra 12db signal to noise ratio each time you
2x oversample the input. So basically if you start with LUT of 4
samples, that should give you about 8dbs at baseline, each time
you double the length you get an extra 12dbs.
Or in simpler terms double the table length get 2 bits less
error. So 8192 table size should give you approximately 24 bits
clear of errors.
But be aware that error is relative to the maximum magnitude of
the signal in the table.
