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




_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev