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 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
