Performance of tables slower than built in?

[NaN]

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.