plans for 64bit support

[Joshua Root]

Ryan Schmidt wrote:
> On Dec 18, 2007, at 23:46, Joshua Root wrote:
>> 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).

>> There's also a related problem: not all ports will necessarily build
>> correctly for all architectures. Switching to building everything 64-bit
>> right now is a gamble.
> 
> It's not a gamble; I guarantee you a largish number of ports will fail.
> Just like a largish number of ports fail to build 2-way 32-bit universal
> binaries today, which is why +universal is not the default.

Right, I meant it's a gamble in the sense that for any given user, maybe
the ports they want to use will work and maybe they won't.

> I think we really need to think about how we want our universal support
> to work as a whole before we start adding little extra things into
> MacPorts.

Agreed.

- Josh