[Python-Dev] Python 3 optimizations... (original) (raw)

Cesare Di Mauro cesare.di.mauro at gmail.com
Fri Jul 23 10:59:18 CEST 2010

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

stefan brunthaler, 23.07.2010 08:48:

If we take for instance the BINARYADD 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 unicodeconcatenate, for float operands on the other hand, the interpreter would end up invoking floatadd via binaryop1. Now, a very efficient way to achieve purely interpretative inline caching is to quicken the type-generic BINARYADD instruction to a type-dependent FLOATADD 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 FORITER, COMPAREOP and CALLFUNCTION 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>

More information about the Python-Dev mailing list