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

stefan brunthaler stefan at brunthaler.net
Fri Jul 23 21:19:15 CEST 2010

I think I was wrong, but now I understand.  The inlining you want is to get the nbadd body, not the opcode body. Exactly. This would increase performace by quite a bit -- I will start experimentation with that stuff a.s.a.p.

The example you've given brings up a correctness issue.  It seems you'd want to add checks that verify that the operands w and v are both floats, and jump to BINARYADD if the guard fails.  It would require reshuffling the stack operations to defer the pop until after the check, but it shouldn't be a problem. That's usually the problem when you're doing something from the top of your head, especially when its already 9pm :) You're right, a simple way around this is either:

TARGET(FLOAT_ADD): if (!(TOP()->ob_type == SECOND()->ob_type && TOP()->ob_type == &PyFloat_Type)) goto TARGET_BINARY_ADD_SKIP_DECODE; ...remains the same...

Note: the skip_decode is necessary because otherwise it would advance the instruction pointer. Another, simple approach is to add another set of labels to denote inline cache misses, e.g.:

TARGET(BINARY_ADD): w= POP(); v= TOP(); BINARY_ADD_CACHE_MISS: x= PyNumber_Add(v, w); ...

TARGET(FLOAT_ADD): w= POP(); v= TOP(); if (v->ob_type != w->ob_type || v->ob_type != &PyFloat_Type) goto BINARY_ADD_CACHE_MISS; ...

You could also call the PyNumber_Add function yourself instead of the goto, but I did not implement it this way...

I think you also record (via gdb) exactly the information that we record.  I now see three consumers of type feedback from the CPython interpreter: you or any quickening approach, Cython, and Unladen Swallow.  It might be worth converging on a standard way to record this information and serialize it so that it can be analyzed offline. Indeed. Probably a bigger set of types of frequently used C extension modules would be useful as well. I am doing the simplest possible thing here: since the gdb pretty print already is pretty close to a Python data type definition, I just copied this and did a few search and replace commands to convert it to a valid Python data type.

Our feedback recording mechanism currently uses LLVM data structures, but the point of quickening is to avoid that kind of dependency, so we'd need to rewrite it before it would really be useful to you. Ok.

--stefan

More information about the Python-Dev mailing list