[Python-Dev] Building a Faster Python
Our current Mac OS X builds use GCC-4.2. On Python2.7, I ran a comparison of gcc-4.2.1 builds versus gcc-4.8.1 and found that the latter makes a much faster Python. PyBench2.0 shows the total running time dropping from 5653ms to 4571ms. The code is uniformly better in just about every category. Raymond --- PYBENCH 2.0 --- * using CPython 2.7.5+ (2.7:f8df7c50132f, Jul 21 2013, 15:57:46) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] * disabled garbage collection * system check interval set to maximum: 2147483647 * using timer: time.time Calibrating tests. Please wait... done. Running 10 round(s) of the suite at warp factor 10: * Round 1 done in 5.775 seconds. * Round 2 done in 5.794 seconds. * Round 3 done in 5.743 seconds. * Round 4 done in 5.736 seconds. * Round 5 done in 5.758 seconds. * Round 6 done in 5.787 seconds. * Round 7 done in 5.779 seconds. * Round 8 done in 5.781 seconds. * Round 9 done in 5.782 seconds. * Round 10 done in 5.811 seconds. --- Benchmark: 2013-07-21 16:02:39 --- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID:Darwin-12.4.0-x86_64-i386-64bit Processor: i386 Python: Implementation: CPython Executable: /Users/raymondhettinger/py27/python.exe Version:2.7.5+ Compiler: GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Bits: 64bit Build: Jul 21 2013 15:57:46 (#2.7:f8df7c50132f) Unicode:UCS2 Test minimum average operation overhead --- BuiltinFunctionCalls:112ms114ms0.22us0.178ms BuiltinMethodLookup: 76ms 83ms0.08us0.207ms CompareFloats: 78ms 80ms0.07us0.237ms CompareFloatsIntegers: 73ms 74ms0.08us0.178ms CompareIntegers: 86ms 87ms0.05us0.354ms CompareInternedStrings: 85ms 86ms0.06us0.895ms CompareLongs: 72ms 72ms0.07us0.207ms CompareStrings: 66ms 66ms0.07us0.603ms CompareUnicode: 75ms 76ms0.10us0.455ms ComplexPythonFunctionCalls: 96ms 98ms0.49us0.298ms ConcatStrings:166ms179ms0.36us0.346ms ConcatUnicode: 80ms 82ms0.27us0.231ms CreateInstances:111ms115ms1.03us0.242ms CreateNewInstances: 84ms 87ms1.04us0.250ms CreateStringsWithConcat: 95ms 97ms0.10us0.602ms CreateUnicodeWithConcat: 70ms 72ms0.18us0.236ms DictCreation: 77ms 77ms0.19us0.237ms DictWithFloatKeys: 81ms 82ms0.09us0.442ms DictWithIntegerKeys: 84ms 85ms0.07us0.591ms DictWithStringKeys: 78ms 79ms0.07us0.590ms ForLoops: 69ms 70ms2.81us0.042ms IfThenElse: 73ms 74ms0.06us0.445ms ListSlicing: 69ms 70ms4.98us0.079ms NestedForLoops: 83ms 84ms0.06us0.016ms NestedListComprehensions:103ms105ms8.78us0.061ms NormalClassAttribute: 85ms 86ms0.07us0.298ms NormalInstanceAttribute: 81ms 81ms0.07us0.299ms PythonFunctionCalls: 94ms 95ms0.29us0.179ms PythonMethodCalls:109ms111ms0.49us0.093ms Recursion:134ms137ms2.74us0.297ms SecondImport:110ms111ms1.11us0.119ms SecondPackageImport:113ms115ms1.15us0.159ms SecondSubmoduleImport:143ms146ms1.46us0.119ms SimpleComplexArithmetic: 70ms 70ms0.08us0.237ms SimpleDictManipulation: 84ms 86ms0.07us0.297ms SimpleFloatArithmetic: 75ms 75ms0.06us0.355ms SimpleIntFloatArithmetic: 67ms 67ms0.05us0.355ms SimpleIntegerArithmetic: 68ms 68ms0.05us0.354ms SimpleListComprehensions: 93ms 94ms7.82us0.061ms SimpleListManipulation: 69ms 71ms0.06us0.386ms SimpleLongArithmetic: 81ms 82ms0.12us0.178ms SmallLists: 94ms 98ms0.14us0.237ms
Re: [Python-Dev] Building a Faster Python
> PyBench2.0 shows the total running time dropping from 5653ms to 4571ms. That's very cool -- a significant improvement. Is this the kind of change that could go into 2.7.6 binaries? As a Windows user, it makes me wonder if compiling with the latest version of the Microsoft compiler would improve things similarly? (Though updating project files to that is almost certainly a bigger project than the gcc update.) -Ben ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building a Faster Python
On Sun, Jul 21, 2013 at 6:46 PM, Ben Hoyt wrote: >> PyBench2.0 shows the total running time dropping from 5653ms to 4571ms. > > That's very cool -- a significant improvement. Is this the kind of change > that could go into 2.7.6 binaries? > > As a Windows user, it makes me wonder if compiling with the latest version > of the Microsoft compiler would improve things similarly? (Though updating > project files to that is almost certainly a bigger project than the gcc > update.) I think I have a 3.3 build on VS2012 somewhere - maybe I'll refresh it for default/3.4 and run the same benchmarks on it. The changes couldn't go into 2.7 as far as I'm aware, at least when it comes to changing Visual Studio versions. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building a Faster Python
>From: Ben Hoyt >> PyBench2.0 shows the total running time dropping from 5653ms to 4571ms. > > That's very cool -- a significant improvement. Is this the kind of change > that could go into 2.7.6 binaries? > > As a Windows user, it makes me wonder if compiling with the latest version of > the Microsoft compiler > would improve things similarly? I'd expect to see some improvement, based solely on the bugs fixed recently by the optimizer team. No idea how much, but I know that Martin builds with PGO, and that's also been improved recently. > (Though updating project files to that is almost certainly a bigger project > than the gcc update.) No idea what the gcc update involved, but this is only accurate if it took less than two minutes :-) I've upgraded the CPython projects before and everything worked fine. Steve ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building a Faster Python
In article <[email protected]>, Raymond Hettinger wrote: > Our current Mac OS X builds use GCC-4.2. > > On Python2.7, I ran a comparison of gcc-4.2.1 builds > versus gcc-4.8.1 and found that the latter makes a much > faster Python. PyBench2.0 shows the total running time > dropping from 5653ms to 4571ms. The code is uniformly > better in just about every category. Interesting. A note about compilers: it looks like the benchmark used the Apple gcc4.2-frontend / LLVM-backend hybrid compiler that is shipped with Xcode 4. We don't use that compiler for building any OS X binary installers, in fact, we blacklist it for Python 3.3+ because we couldn't get it to produce a working 3.3 interpreter: http://bugs.python.org/issue13241 Apple has deprecated use of that compiler (it hasn't been patched in ages) and has announced that it will no longer be shipped starting with the next major release of Xcode, which is expected with the upcoming release of OS X 10.9 (Mavericks). What would be interesting is to run the benchmark with Apple's currently supported compiler for OS X, clang, which is the default "cc" in the most recent versions of Xcode 4 (4.6.3) for OS X 10.7 and 10.8. $ cc --version Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Clang is expected to be the only compiler available via Xcode for 10.9. Note that the most recent Python binary installers default to using clang to build user extension modules with Xcode 4 on 10.7 and 10.8. Currently, for the Intel-only (64-bit/32-bit) installers we instead use the final Apple-supplied gcc-4.2 (gcc front- and backend, no LLVM) shipped with Xcode 3.2.6 on OS X 10.6: [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin] This makes it easier to provide one Python that can be installed and works on multiple OS X versions, for the Intel-only variant: 10.6 through 10.8. As of Xcode 4, Apple no longer ships this compiler. Because of the post-4.2 switch to GPL-3 licensing for gcc, it seems that Apple has no plans to look at, much less ship, anything newer than 4.2 from the gcc code base. At some point, we will probably switch to using clang for the Python in the installer but, at the moment, there appear to still be a large number of systems out there running OS X 10.6. (Also, we and most third-party open-source package managers, like MacPorts and Homebrew, stick to using Apple-supplied compilers for most things rather than vanilla Gnu gcc 4.x because, among other things, Apple includes additional support within their compiler build chain for features like universal binaries and SDK support.) -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building a Faster Python
On Jul 21, 2013, at 5:32 PM, Ned Deily wrote: > In article <[email protected]>, > Raymond Hettinger wrote: >> Our current Mac OS X builds use GCC-4.2. >> >> On Python2.7, I ran a comparison of gcc-4.2.1 builds >> versus gcc-4.8.1 and found that the latter makes a much >> faster Python. PyBench2.0 shows the total running time >> dropping from 5653ms to 4571ms. The code is uniformly >> better in just about every category. > > Interesting. A note about compilers: it looks like the benchmark used > the Apple gcc4.2-frontend / LLVM-backend hybrid compiler that is shipped > with Xcode 4. We don't use that compiler for building any OS X binary > installers, in fact, we blacklist it for Python 3.3+ because we couldn't > get it to produce a working 3.3 interpreter: The results aren't much different using the build published on python.org. Using a fresh OS X install from our website, PyBench clocks in at 5376ms Raymond --- --- PYBENCH 2.0 --- * using CPython 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] * disabled garbage collection * system check interval set to maximum: 2147483647 * using timer: time.time Calibrating tests. Please wait... done. Running 10 round(s) of the suite at warp factor 10: * Round 1 done in 5.459 seconds. * Round 2 done in 5.510 seconds. * Round 3 done in 5.476 seconds. * Round 4 done in 5.473 seconds. * Round 5 done in 5.497 seconds. * Round 6 done in 5.533 seconds. * Round 7 done in 5.520 seconds. * Round 8 done in 5.518 seconds. * Round 9 done in 5.515 seconds. * Round 10 done in 5.515 seconds. --- Benchmark: 2013-07-21 17:54:13 --- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID:Darwin-12.4.0-x86_64-i386-64bit Processor: i386 Python: Implementation: CPython Executable: /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python Version:2.7.5 Compiler: GCC 4.2.1 (Apple Inc. build 5666) (dot 3) Bits: 64bit Build: May 13 2013 13:18:45 (#v2.7.5:ab05e7dd2788) Unicode:UCS2 Test minimum average operation overhead --- BuiltinFunctionCalls:108ms109ms0.21us0.166ms BuiltinMethodLookup: 74ms 77ms0.07us0.193ms CompareFloats: 73ms 73ms0.06us0.229ms CompareFloatsIntegers: 71ms 71ms0.08us0.167ms CompareIntegers: 78ms 78ms0.04us0.334ms CompareInternedStrings: 76ms 77ms0.05us0.842ms CompareLongs: 69ms 70ms0.07us0.196ms CompareStrings: 61ms 61ms0.06us0.566ms CompareUnicode: 66ms 68ms0.09us0.431ms ComplexPythonFunctionCalls: 98ms101ms0.51us0.280ms ConcatStrings:166ms179ms0.36us0.324ms ConcatUnicode: 79ms 81ms0.27us0.220ms CreateInstances:105ms107ms0.96us0.232ms CreateNewInstances: 84ms 88ms1.04us0.233ms CreateStringsWithConcat: 95ms 96ms0.10us0.552ms CreateUnicodeWithConcat: 70ms 72ms0.18us0.222ms DictCreation: 79ms 80ms0.20us0.221ms DictWithFloatKeys: 83ms 84ms0.09us0.414ms DictWithIntegerKeys: 87ms 88ms0.07us0.552ms DictWithStringKeys: 65ms 66ms0.06us0.552ms ForLoops: 58ms 58ms2.34us0.039ms IfThenElse: 65ms 66ms0.05us0.414ms ListSlicing: 72ms 89ms6.38us0.055ms NestedForLoops: 79ms 82ms0.05us0.014ms NestedListComprehensions: 94ms 96ms7.98us0.056ms NormalClassAttribute: 81ms 81ms0.07us0.280ms NormalInstanceAttribute: 73ms 75ms0.06us0.274ms PythonFunctionCalls: 85ms 86ms0.26us0.166ms PythonMethodCalls:100ms103ms0.46us0.086ms Recursion:110ms113ms2.25us0.276ms SecondImport:104ms105ms1.05us0.112ms SecondPackageImport:111ms111ms1.11us0.110ms SecondSubmodu
Re: [Python-Dev] Building a Faster Python
On 07/21/2013 04:36 PM, Raymond Hettinger wrote: Our current Mac OS X builds use GCC-4.2. On Python2.7, I ran a comparison of gcc-4.2.1 builds versus gcc-4.8.1 and found that the latter makes a much faster Python. PyBench2.0 shows the total running time dropping from 5653ms to 4571ms. The code is uniformly better in just about every category. I know that newer Microsoft compilers tend to drop support for older operating systems, and often that means the binaries simply won't work on those operating systems. (Yes, technically it's the libraries that break the older code.) Are Apple's compilers the same? Or do they tend to support all the old versions of OS X? //arry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #18441: Make test.support.requires('gui') skip when it should.
On Mon, 22 Jul 2013 02:13:47 +0200, terry.reedy
wrote:
> +# If buildbot improperly sets gui resource (#18365, #18441), remove it
> +# so requires('gui') tests are skipped while non-gui tests still run.
> +if use_resources and 'gui' in use_resources:
Note that the buildbot cannot "improperly" set the GUI resource.
Setting a resource on the regrtest command line says "please try to run
these tests". If they can't be run, they should then be skipped for
whatever reason they can't run.
--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Issue #18441: Make test.support.requires('gui') skip when it should.
In article <[email protected]>, Terry Reedy wrote: > On 7/21/2013 10:11 PM, R. David Murray wrote: > > On Mon, 22 Jul 2013 02:13:47 +0200, terry.reedy > > wrote: > >> +# If buildbot improperly sets gui resource (#18365, #18441), remove it > >> +# so requires('gui') tests are skipped while non-gui tests still run. > >> +if use_resources and 'gui' in use_resources: > > > > Note that the buildbot cannot "improperly" set the GUI resource. > > I disagree. I do understand though, that what I call improper setting on > the command line cannot be prevented. So I think regrtest (and unittest > if and when it supports resources) should intercept 'gui', test once and > for all whether it was set 'properly' (or 'appropriately', if you > prefer), which is to say, test whether there is a usable GUI, and ignore > 'gui' if not. > > > Setting a resource on the regrtest command line says "please try to run > > these tests". Right. > When doing so causes a failure at best and a crash at worst, and those > consequences and the means of avoiding them are not documented, that is > not a very considerate request. It has cost me over a day of my life. Unfortunately, that's the way regrtest resources work. > The printed out -h help says > "gui - Run tests that require a running GUI." > Not 'try', but 'run'. That implies to me that there *is* 'a running GUI' > and that is it all right to run tests that *require* such. That was also > what I understood from the discussion on > http://bugs.python.org/issue18103 Create a GUI test framework for Idle This is exactly what Issue8716 was about. The buildbot has no way of knowing ahead of time whether a test will cause a crash or not. Yes, Tk should not crash but it does in some cases. Speaking of #8716, that reminds me that there is an open issue with it (documented in Issue17496). There is the start of a patch there to use a more general approach to testing for a working Tk that might be applicable on all platforms. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building a Faster Python
On 22 Jul, 2013, at 3:01, Larry Hastings wrote: > On 07/21/2013 04:36 PM, Raymond Hettinger wrote: >> Our current Mac OS X builds use GCC-4.2. >> >> On Python2.7, I ran a comparison of gcc-4.2.1 builds >> versus gcc-4.8.1 and found that the latter makes a much >> faster Python. PyBench2.0 shows the total running time >> dropping from 5653ms to 4571ms. The code is uniformly >> better in just about every category. >> > > I know that newer Microsoft compilers tend to drop support for older > operating systems, and often that means the binaries simply won't work on > those operating systems. (Yes, technically it's the libraries that break the > older code.) > > Are Apple's compilers the same? Or do they tend to support all the old > versions of OS X? The compiler's included with Xcode 4 cannot generate code for PowerPC machines, other than that it should be possible to generate code for older machines with the latest Xcode version. I have a Python installation on my machine that I use to generate app distributions for a 10.5 machine, and AFAIK this would also work for deploying to 10.4. The hard part is usually convincing autotools-using projects to not use APIs that are available on the build machine but not on the deployment machine. Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building a Faster Python
On 22 Jul, 2013, at 1:36, Raymond Hettinger wrote: > Our current Mac OS X builds use GCC-4.2. > > On Python2.7, I ran a comparison of gcc-4.2.1 builds > versus gcc-4.8.1 and found that the latter makes a much > faster Python. PyBench2.0 shows the total running time > dropping from 5653ms to 4571ms. The code is uniformly > better in just about every category. Have you tried using clang from the latest devtools as well? The OSX binary installers are build using the developer tools from Apple, that happen to use gcc 4.2 on the machine used to build at least the 32-bit binary installer (as that's the latest Xcode that includes PPC support). FWIW I'd like to test with "clang -O4" as well (this performs link-time optimization), I've seen some speedup with other projects and this might help with CPython's speed as well. Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building a Faster Python
On 22 Jul, 2013, at 1:46, Ben Hoyt wrote: > > PyBench2.0 shows the total running time dropping from 5653ms to 4571ms. > > That's very cool -- a significant improvement. Is this the kind of change > that could go into 2.7.6 binaries? I'd prefer not to do that (but don't build the installers anymore). The installers for OSX are build using the system compiler, using a different compiler makes it harder to build the installer. I don't even know if upstream GCC could easily be used for the binary installers, does GCC 4.8 support building FAT binaries in its compiler driver? Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Issue #18441: Make test.support.requires('gui') skip when it should.
On 22 Jul, 2013, at 7:35, Ned Deily wrote: > In article <[email protected]>, Terry Reedy > wrote: >> > > This is exactly what Issue8716 was about. The buildbot has no way of > knowing ahead of time whether a test will cause a crash or not. Yes, Tk > should not crash but it does in some cases. Speaking of #8716, that > reminds me that there is an open issue with it (documented in > Issue17496). There is the start of a patch there to use a more general > approach to testing for a working Tk that might be applicable on all > platforms. Issue17496 contains a patch that might fix the crashing problem for OSX (and possibly other Unix-y platforms). I haven't been able to test this in an environment that's simular enough to the buildbots (that is, a system where the user running the test does not have GUI access). That patch starts wish (the TCL shell) in a subprocess, and skips tests when that doesn't work (on OSX that would be because Tk crashed). Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building a Faster Python
On Sun, 21 Jul 2013 16:36:35 -0700 Raymond Hettinger wrote: > Our current Mac OS X builds use GCC-4.2. > > On Python2.7, I ran a comparison of gcc-4.2.1 builds > versus gcc-4.8.1 and found that the latter makes a much > faster Python. PyBench2.0 shows the total running time > dropping from 5653ms to 4571ms. The code is uniformly > better in just about every category. You could try running the benchmarks suite to see what that gives: http://hg.python.org/benchmarks/ Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
