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

[Hans-Christoph Steiner]

On Oct 3, 2011, at 12:00 PM, Charles Henry wrote:

> 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.

Wouldn't setting t_sample, t_float, and t_int to 64-bit or 32-bit in  
m_pd.h combined with sizeof() be enough for this?

.hc




>>>> 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.
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


----------------------------------------------------------------------------

"A cellphone to me is just an opportunity to be irritated wherever you  
are." - Linus Torvalds