On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> Antoine Pitrou wrote:
>> Or you could submit patches piecewise on http://bugs.python.org
>> I think the first step would be to switch to 16-bit bytecodes. It would be
>> uncontroversial (the increase in code size probably has no negative effect) 
>> and
>> would provide the foundation for all of your optimizations.
>
> I wouldn't consider changing from bytecode to wordcode uncontroversial -
> the potential to have an effect on cache hit ratios means it needs to be
> benchmarked (the U-S performance tests should be helpful there).
>
> It's the same basic problem where any changes to the ceval loop can have
> surprising performance effects due to the way they affect the compiled
> switch statements ability to fit into the cache and other low level
> processor weirdness.

Agreed. We originally switched Unladen Swallow to wordcode in our
2009Q1 release, and saw a performance improvement from this across the
board. We switched back to bytecode for the JIT compiler to make
upstream merger easier. The Unladen Swallow benchmark suite should
provided a thorough assessment of the impact of the wordcode ->
bytecode switch. This would be complementary to a JIT compiler, rather
than a replacement for it.

I would note that the switch will introduce incompatibilities with
libraries like Twisted. IIRC, Twisted has a traceback prettifier that
removes its trampoline functions from the traceback, parsing CPython's
bytecode in the process. If running under CPython, it assumes that the
bytecode is as it expects. We broke this in Unladen's wordcode switch.
I think parsing bytecode is a bad idea, but any switch to wordcode
should be advertised widely.

Collin Winter
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to