Emil Lundberg wrote:
Is there documentation backing up the claim that 64-bit ppc code is slower on 64-bit ppc machines than 32-bit ppc code? I've seen benchmark numbers that show this. I'll see if I can dig them up.
OK, I found some of the comparisons I was thinking of: a Linux-based one with several benchmarks[1], and two Darwin-based ones using Geekbench, on Tiger[2] and Leopard[3]. [1] <http://lixom.net/~olof/64bit-perf.pdf> [2] <http://www.geekpatrol.ca/2006/09/32-bit-vs-64-bit-performance/> [3] <http://www.primatelabs.ca/blog/2007/10/leopard-performance-october-2007/> I'll have access to a G5 in a few days' time, so if no one beats me to it, I'll run some other comparisons.
Thought I'd chip in. We use a wide array of hardware at our site; ppc & x86, 32 and 64-bit. Some applications DO need the 64-bit binaries (need to address 6+ Gb arrays), and the major hurdle in using 64-bit is not in the apps themselves but in all the libraries that they use.
From our perspective, it is more important to support building fat 32/64-bit binaries than ppc/x86, as we do not generally share or sync the macports file tree between machines (way too risky and servers tend to be out of sync library- and OS-wise anyway). Thus a particular machine does not require dual architetures but may require 32/64-bit binaries/libraries, depending on the apps that use them.
Your situation is fairly rare though, isn't it? It seems like a perfect use case for variants.conf.
Also, the rest of the OS nowadays is quad-fat, so so should MacPorts, right... :-)
Well, no. The libraries are (mostly) 4-arch, but AFAICT none of the actual programs (including command-line ones) that ship with Leopard have 64-bit code, with the exception of XCode and Chess. Cheers, Josh