[Pythonmac-SIG] Universal binary installer
bob at redivi.com
Thu Mar 16 04:43:00 CET 2006
On Mar 15, 2006, at 6:01 PM, Graham Cummins wrote:
> I recently downloaded Ronald Doussoren's universal binary installer
> for MacPython. This installed fine on my Macbook Pro, and the
> resulting python version was able to build most of my favorite
> extensions (except PyOpenGL, which I can't get to build on any Mac
> recently - I'll post a separate issue about that.).
> I also compiled the source from the universal svn tree (revision 41).
> This required that I edit
> Lib/distutils/unixccompiler.py as follows:
> --- python/Lib/distutils/unixccompiler.py (revision 41)
> +++ python/Lib/distutils/unixccompiler.py (working copy)
> @@ -42,8 +42,11 @@
> # should just happily stuff them into the preprocessor/compiler/
> # options and carry on.
> def _darwin_compiler(compiler_so, cc_args):
> compiler_so = list(compiler_so)
> + stripArch=0
> + stripSysroot=0
> if os.uname() < '8.':
> stripArch = stripSysroot = 1
> This just clears up a bug where some variables can end up undefined
> if an if condition comes up false. After this modification, the
> source complied fine with --enable-framework. I didn't use --enable-
> universal-sdk, so I guess I compiled an Intel-only version of the
> framework. I then built some extensions for this version also.
> My reason to comment here has to do with the relevant performance of
> the Universal vs locally compiled pythons. In particular, I make
> heavy use of numarray, so I have a standard benchmark that tests many
> of the most computation intensive numarray routines with a variety of
> different data types. According to this benchmark, I'm getting much
> (>3X) better performance out of the local version than out of the
> Universal one.
I don't believe that. 3X performance different can only be explained
by Rosetta, not universal vs. i386-only. I think you were probably
running the benchmark on 2.4.1 or something.
> For both python frameworks, I built numarray 1.5.1 using the basic
> "python setup.py install" (starting with clean source). The
> benchmarks I got were (in seconds to completion) about 24 seconds for
> the Universal, and only 7.2 seconds for the locally compiled python.
> For comparison, the older PPC only MacPython 2.4.1, with numarray
> installed via the included package manager took 32.6 seconds.
> The native code on the MacBook compares very well to other machines.
> Native code on my dual G5 takes 8.4 seconds on this task. The only
> machine I've seen that's as fast as this MacBook was an SGI Altix 330
> (Itanium 2), and even it wasn't any faster. This makes me pretty
> happy about the Intel Core Duo, but somewhat worried about Universal
> binaries (in general, but for python in particular) since the binary
> seems closer in performance to rosetta than to native code.
I blame the tests. Make sure to check platform.mac_ver() to make
sure that it's actually running the version that's compiled for
i386. Perhaps you had a lingering python executable that was
compiled PPC only that was executing instead of the i386 version. It
could've still linked against the universal framework, but would've
started up under Rosetta.
$ /usr/local/bin/python -c "import platform; print platform.mac_ver()
; import test.pystone; test.pystone.main(50000)"
Pystone(1.1) time for 50000 passes = 1.93
This machine benchmarks at 25906.7 pystones/second
$ /usr/libexec/oah/oah750 /usr/local/bin/python -c "import platform;
print platform.mac_ver(); import test.pystone; test.pystone.main
Pystone(1.1) time for 50000 passes = 5.27
This machine benchmarks at 9487.67 pystones/second
The difference in pystones between PPC and i386 is ~2.73, which
roughly proves that you were benchmarking the universal build under
More information about the Pythonmac-SIG