[Python-Dev] Building a Faster Python (original) (raw)
David Hutto dwightdhutto at gmail.com
Tue Jul 23 07:39:03 CEST 2013
- Previous message: [Python-Dev] Building a Faster Python
- Next message: [Python-Dev] [Python-checkins] cpython (2.7): Issue #18441: Make test.support.requires('gui') skip when it should.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Just a suggestion from working with an assembly language stepper from a while back with Intel x86...lost to an HD crash, but couldn't you disassemble the binary, run through the assembly, and look for specific instructions that you could refine into a simpler, smaller cycling time to improve upon with a stepper that counts cycles?
I've seen other assembly steppers after I started mine for electrical engineering of PCB's, but I don't know if they're counting cycles, and suggesting other actions in an editor typ/optimization mode that the compiler might miss.
On Mon, Jul 22, 2013 at 12:09 PM, Ronald Oussoren <ronaldoussoren at mac.com>wrote:
On 22 Jul, 2013, at 17:08, David Malcolm <dmalcolm at redhat.com> wrote: > On Mon, 2013-07-22 at 09:32 +0200, Maciej Fijalkowski wrote: >> On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski <fijall at gmail.com> wrote: >>> On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou <solipsis at pitrou.net> wrote: >>>> On Sun, 21 Jul 2013 16:36:35 -0700 >>>> Raymond Hettinger <raymond.hettinger at gmail.com> 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. >>> >>> or pypy benchmark suite which is more comprehensive for python 2.7 >>> (http://bitbucket.org/pypy/benchmarks) >> >> Besides, is there any reason not to use clang by default on OS X? > > How did this thread go from: > "for OS X, GCC 4.8.1 gives you significantly faster machine code > than the system GCC 4.2.1" > to > "let's just use clang" > ? Because we use the system compiler for building the official binary packages. I'm not looking forward to bootstrapping GCC multiple times[*] just to be able to build a slightly faster python. And more so because you have to be very careful when using a alternative compiler when building the installer, it is very easy to end up with a build that others cannot use to build extension because they don't have /Users/ronald/Tools/Compiler/gcc-4.8/bin/gcc. > > (I should declare that I've been hacking on GCC for the last few months, > so I have an interest in this) It would still be interesting to know which compiler would generate the fastest code for CPython. Apple tends to claim that clang generates better code than GCC, buit AFAIK they compare the latest clang with the latest version of GCC that they used to ship, which is ancient by now. Ronald [*] multiple times due to fat binaries.
Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/dwightdhutto%40gmail.com
-- Best Regards, David Hutto CEO: *http://www.hitwebdevelopment.com* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130723/765ab114/attachment.html>
- Previous message: [Python-Dev] Building a Faster Python
- Next message: [Python-Dev] [Python-checkins] cpython (2.7): Issue #18441: Make test.support.requires('gui') skip when it should.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]