[PD-dev] double precision Pd: .patch files, tests and benchmarks

Charles Henry czhenry at gmail.com
Mon Oct 3 18:00:30 CEST 2011


On Mon, Oct 3, 2011 at 10:19 AM, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2011-10-03 16:31, Hans-Christoph Steiner wrote:
>>
>>> These all sound like good ideas to try.  My only concern is that we
>>> might let the deployment issues distract from the issues at hand about
>>> getting it actually working first.
>
> i'm definitely with you here.
> what is still missing in terms of "getting it actually working first"?
>
> afaict, katja's patches do make pd itself double-precision ready (the
> patches might have to be reviewed as far as coding-style is concerned
> though)
>
> otoh, i wouldn't start "porting" externals before we have a deployment
> strategy.
>
>
>
> one important thing missing right now, is how to compile Pd in a given
> precision without having to edit m_pd.h
> technically i think that the define stuff and the like should go into a
> separate file "types.h" (probably "m_types.h") which is generated from
> m_types.h.in during configure time, and which is included by m_pd.h
> (which should remain non-generated)
> the question is, what miller would think of such a thing.

Would you prefer to set the types at configure time through a file--or
for example by adding a -DDOUBLE compiler flag?  The affected
locations of code defining the types could just use #ifdef DOUBLE

In either case, the configure option seems necessary.  It still seems
an open question how best to offer the double-precision types to
externals developers.

In some cases, the setup() function allocates memory, which needs to
be aware of the data type size.
Otherwise, memory for signals is allocated through Pd's DSP graph
generation routines, so that only changes to externals is to compile
perform routines with the given data type.

Adding additional methods seems unnecessary--unless specific
performance problems can be avoided.


>
>>> In terms of packaging, I can see having 64-bit distros run
>>> double-precision Pd for all packages, and 32-bit distros run single
>>> precision.  That should cover the bulk of situations, the other
>>> situations can be covered by custom builds.  Having all the 64-bit
>>> packages use double-precision Pd is of course going to happen after a
>>> while, once we have the bugs worked out.  Here I can see an advantage of
>>> the monolithic Pd-extended package: its an easy, self-contained test bed.
>
> definitely, the traditional Pd-extended will have an easier time here.
>
> nevertheless, the advent of ~/pd-externals for the user has made things
> significantly more complicated in terms of "just works".
>
> fgmasdr
> IOhannes

I don't anticipate any problems with running 64-bit Pd on a 32-bit
system, in principle, just as long as the correct data types are set
for pointers (same size as t_int) and signals (size of t_sample)
differently.



More information about the Pd-dev mailing list