[Python-Dev] Python 3 optimizations...

[stefan brunthaler]

> I think I was wrong, but now I understand.  The inlining you want is
> to get the nb_add 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 BINARY_ADD 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