[PD] more about float limitation

Miller Puckette msp at ucsd.edu
Mon Feb 2 17:16:25 CET 2015


There are indeed two matters here.  What (rather little) I know about it is
this...  On Mac OSX, it's easy to compare the performance of the 32 and 64
bit versions of Pd on a single 64-bit machine - and the 64 bit Pd consistently 
out-performs the 32-bit one by, as I recall, 15-20%.

I believe Katja's benchmarks show that it would be possible to make a Pd
for Mac that not only runs "in 64 bit" (compiled fro a different instruction
set than the 32-bit version, and with 64-bit pointers) but also making  Pd's
"float" and audio samples use double precision, and still eseitially get the
same performance (i.e., there would be little penalty for increasing the 
precision of all numerical calculations in Pd).

This raises horrible compatibility problems, of which the worst might be that
there would then have to be three formats for externs on Mac and linux.  But
another ugly thing is that someone could develop a patch in 64 bits which
wouldn't work in 32 bits - that could cause a world of misery and confusion.

So although I'm strongly tempted to add new "double" versions of Pd for Mac
and linux, I simply don't know whether the benefits really outweight the
dangers.

cheers
Miller

On Mon, Feb 02, 2015 at 03:49:03PM +0000, Jonathan Wilkes via Pd-list wrote:
> I think you're talking about several things at once.  Katja's Pd Double is essentially about changing t_float to be a double-precision floating point number.  But as I understand it she also revised the code in some of the core tilde classes like osc~ and phasor~ to optimize their performance.  Those optimizations matter even if you compile her version of Pd to have a _single_ precision t_float.  (I.e., with single-precision it will still outperform Pd Vanilla in her tests.)
> 
> That's a different issue than what happens when you run Pd on a 64-bit architecture.  I don't understand how a 64-bit architecture would improve efficiency for math involving double-precision floats.  Does it?
> 
> -Jonathan
> 
>      On Sunday, February 1, 2015 11:52 PM, Alexandre Torres Porres <porres at gmail.com> wrote:
>    
> 
>  >> sure, but it still runs faster if compiled to 64 bits in a 64 bit OS, right?
> >>
> 
> >why?
> 
> The only thing I have to back this assumption up is a recollection of a message by miller to the list saying that tests with the 64 bit version showed it was running faster, but I don't know anything about it, really. Still trying to learn from you.
> I'd also suspect that a double precision in Pd would make it much slower, but the benchmarks from Katja didn;t point this out.
> Seems like some future version of Pd running in full double precision is not too crazy, huh?
> cheers
> 2015-02-01 19:08 GMT-02:00 IOhannes m zmölnig <zmoelnig at iem.at>:
> 
> On 02/01/2015 06:05 PM, Alexandre Torres Porres wrote:
> >>
> >> Seems Pd runs faster if compiled to 64 bits in a 64 bit OS than if it were
> >> compiled as 32, which does makes sense. That's all?
> >>
> >
> > "*no : pd compiled for 64 bit system will not run on 32 bit sytem, and it
> > will not load 32 bit externals.*"
> >
> > sure, but it still runs faster if compiled to 64 bits in a 64 bit OS, right?
> >
> 
> why?
> 
> if you run a 32bit binary on a 64bit OS, there might be some overhead
> involved (bit then i really don't know much about the performance of
> multi-arch systems)
> 
> if you run a 32bit binary on a 32bit OS on a 64bit CPU (x86_64, which is
> compatible with 32bit CPUs), then it might be slightly slower than
> compared to a full 64bit system.
> 
> 
> the real advantages are:
> - memory access!
>  a 32bit application/OS uses 32bit pointers to access memory. this
> limits the accessible memory to 4GB (your OS might be able to manage
> more using PAE; but the application itself will have a maximum of 4GB.)
>  a 64bit application uses 64bit pointers to access memory. thats much
> more as you are likely to ever see in your lifetime (but then: 2640k are
> enough" anybody?)
> 
> - modern OSs are 64bit (even the not-so-modern w32[sic!] has started to
> become a 64bit system).
> it seems silly to run 32bit applications on such systems (and a waste of
> ressources, as you need to install a 32bit version the entire
> runtime-environment)
> 
> 
> also check out: http://en.wikipedia.org/wiki/64-bit_computing
> 
> fgrsam
> IOhannes
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 
> 
>    

> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list




More information about the Pd-list mailing list