[Python-Dev] Python 3 optimizations continued...

[Gregory P. Smith]

On Mon, Aug 29, 2011 at 2:05 PM, stefan brunthaler <s.brunthaler at uci.edu>wrote:

> > The question really is whether this is an all-or-nothing deal. If you
> > could identify smaller parts that can be applied independently, interest
> > would be higher.
> >
> Well, it's not an all-or-nothing deal. In my current architecture, I
> can selectively enable most of the optimizations as I see fit. The
> only pre-requisite (in my implementation) is that I have two dispatch
> loops with a changed instruction format. It is, however, not a
> technical necessity, just the way I implemented it. Basically, you can
> choose whatever you like best, and I could extract that part. I am
> just offering to add all the things that I have done :)
>
>
+1 from me on going forward with your performance improvements.  The more
you can break them down into individual smaller patch sets the better as
they can be reviewed and applied as needed.  A prerequisites patch, a patch
for the wide opcodes, etc..

For benchmarks given this is python 3, just get as many useful ones running
as you can.

Some in this thread seemed to give the impression that CPython performance
is not something to care about. I disagree. I see CPython being the main
implementation of Python used in most places for a long time. Improving its
performance merely raises the bar to be met by other implementations if they
want to compete. That is a good thing!

-gps


> > Also, I'd be curious whether your techniques help or hinder a potential
> > integration of a JIT generator.
> >
> This is something I have previously frequently discussed with several
> JIT people. IMHO, having my optimizations in-place also helps a JIT
> compiler, since it can re-use the information I gathered to generate
> more aggressively optimized native machine code right away (the inline
> caches can be generated with the type information right away, some
> functions could be inlined with the guard statements subsumed, etc.)
> Another benefit could be that the JIT compiler can spend longer time
> on generating code, because the interpreter is already faster (so in
> some cases it would probably not make sense to include a
> non-optimizing fast and simple JIT compiler).
> There are others on the list, who probably can/want to comment on this,
> too.
>
> That aside, I think that while having a JIT is an important goal, I
> can very well imagine scenarios where the additional memory
> consumption (for the generated native machine code) of a JIT for each
> process (I assume that the native machine code caches are not shared)
> hinders scalability. I have in fact no data to back this up, but I
> think that would be an interesting trade off, say if I have 30% gain
> in performance without substantial additional memory requirements on
> my existing hardware, compared to higher achievable speedups that
> require more machines, though.
>
>
> Regards,
> --stefan
> _______________________________________________
> 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/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110829/1ec07d77/attachment.html>