Re: plans for 64bit support (Joshua Root)
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
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
On 2007-12-20 17:59:25 +1100, Joshua Root wrote:
[1] <http://lixom.net/~olof/64bit-perf.pdf> [2] <http://www.geekpatrol.ca/2006/09/32-bit-vs-64-bit-performance/>
I don't understand why they say that 5 instructions are needed for constants in 64-bit binaries. Can't the PowerPC load the constant from the memory with a single instruction? This is the solution chosen on the ARM for complex constants (if they are in the cache, this should be fast enough). But many constants are simple enough to be loaded with a single instruction (on the ARM, these are 8-bit values rotated by an even number of positions), in particular after optimizing the code. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Dec 20, 2007, at 5:03 PM, Vincent Lefevre wrote:
On 2007-12-20 17:59:25 +1100, Joshua Root wrote:
[1] <http://lixom.net/~olof/64bit-perf.pdf> [2] <http://www.geekpatrol.ca/2006/09/32-bit-vs-64-bit-performance/>
I don't understand why they say that 5 instructions are needed for constants in 64-bit binaries. Can't the PowerPC load the constant from the memory with a single instruction? This is the solution chosen on the ARM for complex constants (if they are in the cache, this should be fast enough). But many constants are simple enough to be loaded with a single instruction (on the ARM, these are 8-bit values rotated by an even number of positions), in particular after optimizing the code.
If I remember correctly, all powerpc instructions have a length of 32 bit. Given that you need some bits for the opcode, a mere 16 bit remain to stuff a constant value to it (for the load high/add intermediate instructions). So, for a 64 bit value to load, you need to do a -2x loadhigh (2x high 16 bit) -2x add immediate (2x low 16 bit) -1x some combine statement (some shift operation or whatever) Keep in mind that these 64 bit constants only cost you for pointers. If you want a 32 bit integer, you don't need to load 64 bit -- even in 64 bit mode. Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/
On Dec 20, 2007, at 10:22 PM, Markus Weissmann wrote:
On Dec 20, 2007, at 5:03 PM, Vincent Lefevre wrote:
On 2007-12-20 17:59:25 +1100, Joshua Root wrote:
[1] <http://lixom.net/~olof/64bit-perf.pdf> [2] <http://www.geekpatrol.ca/2006/09/32-bit-vs-64-bit-performance/>
I don't understand why they say that 5 instructions are needed for constants in 64-bit binaries. Can't the PowerPC load the constant from the memory with a single instruction? This is the solution chosen on the ARM for complex constants (if they are in the cache, this should be fast enough). But many constants are simple enough to be loaded with a single instruction (on the ARM, these are 8-bit values rotated by an even number of positions), in particular after optimizing the code.
If I remember correctly, all powerpc instructions have a length of 32 bit. Given that you need some bits for the opcode, a mere 16 bit remain to stuff a constant value to it (for the load high/add intermediate instructions). So, for a 64 bit value to load, you need to do a -2x loadhigh (2x high 16 bit) -2x add immediate (2x low 16 bit) -1x some combine statement (some shift operation or whatever)
Keep in mind that these 64 bit constants only cost you for pointers. If you want a 32 bit integer, you don't need to load 64 bit -- even in 64 bit mode.
Oh, and don't forget that 64 bit Intel code is actually most often faster than 32 bit code, thanks to the double amount of registers and some other goodies; I've compiled a 32bit/64bit universal `bzcat' and ran both version three times on my Core 2 Duo machine. For this randomly chosen (!) benchmark, I get an impressive edge of ~20% for 64 bit mode: $ time ./bzcat-64 gcc-core-4.3-20071214.tar.bz2 >/dev/null real 0m5.889s user 0m5.168s sys 0m0.096s $ time ./bzcat-64 gcc-core-4.3-20071214.tar.bz2 >/dev/null real 0m5.516s user 0m5.120s sys 0m0.088s $ time ./bzcat-64 gcc-core-4.3-20071214.tar.bz2 >/dev/null real 0m5.489s user 0m5.137s sys 0m0.085s $ time ./bzcat-32 gcc-core-4.3-20071214.tar.bz2 >/dev/null real 0m7.407s user 0m6.707s sys 0m0.107s $ time ./bzcat-32 gcc43/gcc-core-4.3-20071214.tar.bz2 >/dev/null real 0m6.966s user 0m6.540s sys 0m0.097s $ time ./bzcat-32 gcc43/gcc-core-4.3-20071214.tar.bz2 >/dev/null real 0m7.051s user 0m6.583s sys 0m0.103s Regards, -Markus PS: To force the system to run `xy' in 32/64 bit mode (or even Rosetta), just make a copy of the executable with just the arch you want, e.g. `lipo -extract i386 bzcat -output bzcat-32' to extract 32 bit intel code from bzcat and store it into bzcat-32. -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/
On 2007-12-20 22:22:51 +0100, Markus Weissmann wrote:
If I remember correctly, all powerpc instructions have a length of 32 bit.
That's not different from the ARM.
Given that you need some bits for the opcode, a mere 16 bit remain to stuff a constant value to it (for the load high/add intermediate instructions).
You missed the point: there is no need to encode the constant in the instructions since it can be somewhere else in the memory (e.g. in a "constant pool").
Keep in mind that these 64 bit constants only cost you for pointers.
If all pointers are sufficiently close to each other, another solution is to keep a base pointer in some register, and compute the other ones with an addition to a 16-bit or a 32-bit constant (2 or 3 instructions). -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Hi, I can't get mozilla-dev built. It gives lots and lots of errors. I started fixing some, but after an while I kinda though I'd first ask if anyone has succeeded with it before, so that maybe it's just a local misconfiguration. Among the things I fixed so far are: 1) some of the headers of the package confuse signal.h (they #define some things that mess up signal.h) so I had to move signal.h to the top of the include list in those cases. 2) the interface to freetype is broken. the mozilla-dev uses funtion pointers with non-const arguments, while ft2 seems to expect them to be with const arguments (moveto, lineto, cubicto...), so I added const qualifiers in the correesponding function declarations. another thing I didn't fix yet is NSOID being undefined in lots of places. I just couldn't find where it is defined. This only shows btw. when there is an array of NSOID defined. The compiler merilly compiles pointer statements (NSOID *). My system is osx leopard on a core2duo mbp. I took over the macports tree from my tiger installation, but that had no problems...so far :). I recently did selfupdate (to 1.6) and upgrade outdated successfully. Daniel
On Dec 28, 2007, at 02:08, Daniel Oberhoff wrote:
I can't get mozilla-dev built. It gives lots and lots of errors. I started fixing some, but after an while I kinda though I'd first ask if anyone has succeeded with it before, so that maybe it's just a local misconfiguration. Among the things I fixed so far are:
1) some of the headers of the package confuse signal.h (they #define some things that mess up signal.h) so I had to move signal.h to the top of the include list in those cases.
2) the interface to freetype is broken. the mozilla-dev uses funtion pointers with non-const arguments, while ft2 seems to expect them to be with const arguments (moveto, lineto, cubicto...), so I added const qualifiers in the correesponding function declarations.
another thing I didn't fix yet is NSOID being undefined in lots of places. I just couldn't find where it is defined. This only shows btw. when there is an array of NSOID defined. The compiler merilly compiles pointer statements (NSOID *).
My system is osx leopard on a core2duo mbp. I took over the macports tree from my tiger installation, but that had no problems...so far :). I recently did selfupdate (to 1.6) and upgrade outdated successfully.
mozilla and mozilla-devel ports are not being maintained, and appear to be old. Why do you want to install mozilla 1.8b1? Migrating a MacPorts tree from Tiger to Leopard (or across any major OS release version, or from one architecture processor to another) can be problematic. In the case of moving from Tiger to Leopard, you probably still have a lot of ports installed that have the "darwin_8" variant. Examine "port installed" to see. You should forcibly uninstall each of those (sudo port -f uninstall foo) (making note of which other variants you selected), then reinstall them (sudo port install foo +whatever), so they lose the now-inappropriate darwin_8 variant and gain (if necessary) the darwin_9 variant.
Hi, Ok, yes, I had lots of those darwin_8 thingies. While deinstalling openssl macports just broke (it seems the whole ports system depended on openssl) so now I had to shoot it and reinstall, and lost interest along the way :o (other things where more interesting ^^). Anyhow, I wanted the mozilla-dev to build the mugshot tracker, for which there is no osx version yet, and it uses gecko-sdk, which again bases on the mozilla-sdk. Once I get back on track with this I will update here if it works. Best Daniel Am 28.12.2007 um 16:44 schrieb Ryan Schmidt:
On Dec 28, 2007, at 02:08, Daniel Oberhoff wrote:
I can't get mozilla-dev built. It gives lots and lots of errors. I started fixing some, but after an while I kinda though I'd first ask if anyone has succeeded with it before, so that maybe it's just a local misconfiguration. Among the things I fixed so far are:
1) some of the headers of the package confuse signal.h (they #define some things that mess up signal.h) so I had to move signal.h to the top of the include list in those cases.
2) the interface to freetype is broken. the mozilla-dev uses funtion pointers with non-const arguments, while ft2 seems to expect them to be with const arguments (moveto, lineto, cubicto...), so I added const qualifiers in the correesponding function declarations.
another thing I didn't fix yet is NSOID being undefined in lots of places. I just couldn't find where it is defined. This only shows btw. when there is an array of NSOID defined. The compiler merilly compiles pointer statements (NSOID *).
My system is osx leopard on a core2duo mbp. I took over the macports tree from my tiger installation, but that had no problems...so far :). I recently did selfupdate (to 1.6) and upgrade outdated successfully.
mozilla and mozilla-devel ports are not being maintained, and appear to be old. Why do you want to install mozilla 1.8b1?
Migrating a MacPorts tree from Tiger to Leopard (or across any major OS release version, or from one architecture processor to another) can be problematic. In the case of moving from Tiger to Leopard, you probably still have a lot of ports installed that have the "darwin_8" variant. Examine "port installed" to see. You should forcibly uninstall each of those (sudo port -f uninstall foo) (making note of which other variants you selected), then reinstall them (sudo port install foo +whatever), so they lose the now- inappropriate darwin_8 variant and gain (if necessary) the darwin_9 variant.
Ok, I rebuilt now, and still get the same set of errors. Am 30.12.2007 um 01:58 schrieb Daniel Oberhoff:
Hi,
Ok, yes, I had lots of those darwin_8 thingies. While deinstalling openssl macports just broke (it seems the whole ports system depended on openssl) so now I had to shoot it and reinstall, and lost interest along the way :o (other things where more interesting ^^). Anyhow, I wanted the mozilla-dev to build the mugshot tracker, for which there is no osx version yet, and it uses gecko-sdk, which again bases on the mozilla-sdk. Once I get back on track with this I will update here if it works.
Best
Daniel
Am 28.12.2007 um 16:44 schrieb Ryan Schmidt:
On Dec 28, 2007, at 02:08, Daniel Oberhoff wrote:
I can't get mozilla-dev built. It gives lots and lots of errors. I started fixing some, but after an while I kinda though I'd first ask if anyone has succeeded with it before, so that maybe it's just a local misconfiguration. Among the things I fixed so far are:
1) some of the headers of the package confuse signal.h (they #define some things that mess up signal.h) so I had to move signal.h to the top of the include list in those cases.
2) the interface to freetype is broken. the mozilla-dev uses funtion pointers with non-const arguments, while ft2 seems to expect them to be with const arguments (moveto, lineto, cubicto...), so I added const qualifiers in the correesponding function declarations.
another thing I didn't fix yet is NSOID being undefined in lots of places. I just couldn't find where it is defined. This only shows btw. when there is an array of NSOID defined. The compiler merilly compiles pointer statements (NSOID *).
My system is osx leopard on a core2duo mbp. I took over the macports tree from my tiger installation, but that had no problems...so far :). I recently did selfupdate (to 1.6) and upgrade outdated successfully.
mozilla and mozilla-devel ports are not being maintained, and appear to be old. Why do you want to install mozilla 1.8b1?
Migrating a MacPorts tree from Tiger to Leopard (or across any major OS release version, or from one architecture processor to another) can be problematic. In the case of moving from Tiger to Leopard, you probably still have a lot of ports installed that have the "darwin_8" variant. Examine "port installed" to see. You should forcibly uninstall each of those (sudo port -f uninstall foo) (making note of which other variants you selected), then reinstall them (sudo port install foo +whatever), so they lose the now- inappropriate darwin_8 variant and gain (if necessary) the darwin_9 variant.
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
participants (6)
-
Daniel Oberhoff
-
Emil Lundberg
-
Joshua Root
-
Markus Weissmann
-
Ryan Schmidt
-
Vincent Lefevre