plans for 64bit support (Joshua Root)

[Emil Lundberg]

>>> The default should be to build 32-bit binaries on ppc64 machines,  
>>> since
>>> ppc64 code is generally slower. There should be a config file  
>>> option so
>>> those on ppc64 hardware can build everything 64-bit if they want. On
>>> x86_64 machines, 64-bit binaries should be the default.
>>>
>>> +universal should default to building for ppc32, x86, and x86_64.  
>>> That
>>> will generally give the best performance everywhere.
>>
>> An interesting perspective. 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.
>
>>
> From a theoretical perspective, it's pretty clear that a PPC chip
> running in 64-bit mode must be at least a little bit slower than the
> same chip running in 32-bit mode, since pointers are twice as wide.  
> They
> take up twice as much room in the caches and in memory. They also take
> twice as many instructions to load and store.
>
> That's only when the code doesn't take advantage of the 64-bit
> architecture, of course. Going to ppc64 can be a win if you need to  
> use
> huge amounts of RAM in a single process, if your code can be  
> simplified
> by making use of the 64-bit address space (e.g. mmap()ing a 200 GB
> file), or if you use 64-bit integer arithmetic (which is emulated by  
> the
> compiler on 32-bit).

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. Also, the  
rest of the OS nowadays is quad-fat, so so should MacPorts, right... :-)

Regarding +universal; unless someone can prove that there is a MAJOR,  
real-life, performance hit when using ppc64, my vote is on building  
the most competent binary possible, including the ppc64, for  
consistency and simplicity (given that the port actually builds, of  
course). Either that or split it into say +univ_arch and +univ_bit,  
but I'm all for simplicity.

Of course, as Ryan said: it's not a matter of the building itself, but  
tying it all together at the end. I realise this no small matter,  
either.

Best regards,

/Emil