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

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