maybe you should also make sqrt~ should call the true functionwhile at it?
references https://github.com/pure-data/pure-data/issues/1906 / https://github.com/pure-data/pddp/issues/125#issuecomment-1353459554
cheers
Em dom., 26 de mai. de 2024 às 06:16, Miller Puckette < mpuckette@cloud.ucsd.edu> escreveu:
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:
- 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?
- 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.
- 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
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev