OK, so in a few years every new PC will probably have ARM or other RISC architecture.
I just made the interesting discovery that, on Mac ARMs, there is a difference, probably a slight decrease, in numerical accuracy in Pd's DSP objects. So we've lost exact compatibliity and only have pretty-good-approximate compatibility. On one piece I tested the divergence is about -100 dB relative to maximum amplitude and in another, which I think has unstable feedback paths, the results are further off.
SO... I can now relax my insistence on exact back-compatibility for osc~ and cos~ and ... make them more accurate! I think I should do this for 0.55.
Now for the questions:
1. Unfortunately COSTABLESIZE (512) is declared in m_pd.h. Can I change this value (conditionally, increasing it for 64-bit PDs and for some or all ARM architectures) without breaking externals that might use the built-in cosine table?
2. should I make the table size variable, either by a new [declare] flag, or by passing a flag to osc~ and cos~? This could affect run time - I'd want to investigate that.
3. Alternatively, should I just leave COSTABSIZEE at 512 for specific architectures in non-double (Intel for compatibilty, and possibly RPI if there turns out to be a bad performance hit). I'd choose a new one after doing some profiling because at some point increasing table size will lead to bad cache behavior. (Historical note: the number 512 gives a 4096-point table which is the memory page size of the Intel I860, beyond qhich performance dropped by a factor of 10 or more. Recently I tested a 2048-point table, which is 36dB lower-noise, on a bog-standard Intel Linuix machine and... saw no penalty at all).
I'm afraid it will take me (and whoever else is interested in this) some time to figure everything out. But I think at 0.55 we're still at a point where we don't have to be extremely strict about numerical reproducibilty on ARM/Macintosh or on Pd-double, and so this seems a good time to attack this. It's been a long-standing problem.
cheers
Miller