[Python-Dev] Python 3 optimizations...

[Cesare Di Mauro]

2010/7/23 Stefan Behnel <stefan_ml at behnel.de>

> stefan brunthaler, 23.07.2010 08:48:
>
> If we take for instance the BINARY_ADD instruction, the interpreter
>> evaluates the actual operand types and chooses the matching operation
>> implementation at runtime, i.e., operands that are unicode strings
>> will be concatenated via unicode_concatenate, for float operands on
>> the other hand, the interpreter would end up invoking float_add via
>> binary_op1. Now, a very efficient way to achieve purely interpretative
>> inline caching is to quicken the type-generic BINARY_ADD instruction
>> to a type-dependent FLOAT_ADD instruction (this technique, i.e.,
>> inline caching via quickening, is the primary contribution of my ECOOP
>> paper). Hence, I have a very simple code generator, that generates
>> type-dependent interpreter instructions in a pre-compile step of the
>> interpreter, and uses runtime type information to quicken/rewrite
>> instructions.
>> Aside of the operators, I have implemented this quickening technique
>> for FOR_ITER, COMPARE_OP and CALL_FUNCTION instructions.
>>
>> This sounds like wpython (a CPython derivative with a wider set of byte
> code commands) could benefit from it.
>

WPython 1.1 does it at compile time, if you enable the new "experimental
integer opcodes" flag.

Similar optimizations were introduced with new opcodes for specialized
string interpolation and joins, which are common operations in Python.

It also added a new opcode GET_GENERATOR which internally uses a faster
function call, which is used also by (the modified) BUILD_CLASS for the same
reason (cut some unnecessary checks and code).

Cesare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100723/bd84c93c/attachment.html>