[Pythonmac-SIG] Universal binary installer

[Bob Ippolito]

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/
> linker
> #     options and carry on.
> +
> def _darwin_compiler(compiler_so, cc_args):
>       compiler_so = list(compiler_so)
> +    stripArch=0
> +    stripSysroot=0
>       if os.uname()[2] < '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()[2] 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() 
[2]; import test.pystone; test.pystone.main(50000)"
i386
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()[2]; import test.pystone; test.pystone.main 
(50000)"
PowerPC
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  
PPC emulation.

-bob