[Python-Dev] Python 3 optimizations...

Reid Kleckner reid.kleckner at gmail.com
Fri Jul 23 20:57:55 CEST 2010


On Fri, Jul 23, 2010 at 11:26 AM, stefan brunthaler
<stefan at brunthaler.net> wrote:
>> I'm guessing from your comments below about cross-module inlining that
>> you generate a separate .c file with the specialized opcode bodies and
>> then call through to them via a table of function pointers indexed by
>> opcode, but I could be totally wrong.  :)
>>
> No, dead on ;)
> Probably a small example from the top of my head illustrates what is going on:
>
> TARGET(FLOAT_ADD):
>  w= POP();
>  v= TOP();
>  x= PyFloat_Type.tp_as_number->nb_add(v, w);
>  SET_TOP(x);
>  if (x != NULL) FAST_DISPATCH();
>  break;
>
> And I extend the standard indirect threaded code dispatch table to
> support the FLOAT_ADD operation.

I think I was wrong, but now I understand.  The inlining you want is
to get the nb_add body, not the opcode body.

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.

>> This would be interesting.  We have (obviously) have similar
>> instrumentation in unladen swallow to gather type feedback.  We talked
>> with Craig Citro about finding a way to feed that back to Cython for
>> exactly this reason, but we haven't really pursued it.
>>
> Ok; I think it would actually be fairly easy to use the type
> information gathered at runtime by the quickening approach. Several
> auxiliary functions for dealing with these types could be generated by
> my code generator as well. It is probably worth looking into this,
> though my current top-priority is my PhD research, so I cannot promise
> to being able to allocate vast amounts of time for such endeavours.

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.

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.

Reid


More information about the Python-Dev mailing list