[Python-Dev] Building a Faster Python

[David Hutto]

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>