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@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list