I'd agree that the costable size could be increased. I think we can
leave it constant, possibly configurable at compile time. At most, I
would make it configurable via a command line argument. But this can
always be done as a later step.
If we want to keep exposing the cos table to externals, we should export
a dedicated function to get the table size at runtime, e.g.
cos_table_size(), so we are free to change the size without breaking
existing externals. If we decide to keep a fixed table size (for now),
COSTABSIZE should be reserved for internal use (as an optimization).
Are there any existing externals that do use cos_table? When in doubt,
we could keep the old cos_table around, but deprecate it. In the future
we can remove the cos_table symbol, so old externals simply won't load.
For example:
<m_pd.h>
#ifdef PD_INTERNAL
#define LOGCOSTABSIZE 9
#define COSTABSIZE (1<<LOGCOSTABSIZE)
#endif
/* the cos table */
EXTERN float *pd_cos_table;
/* get the cos table size at runtime; always a power of two! */
EXTERN int cos_table_size(void);
/* old cos table for backwards compatibility with old externals; do not use! */
PD_DEPRECATED EXTERN float *cos_table;
Alternatively, we can break source compatibility and remove cos_table
altogether, but keep exporting it "secretely", like we do with the
error() function.
Cheers,
Christof
On 26.05.2024 11:16, Miller Puckette wrote:
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
[email protected]
https://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev
