[Python-Dev] Opcode frequency
Georg Brandl
g.brandl at gmx.net
Wed Jun 18 21:45:07 CEST 2008
Antoine Pitrou schrieb:
> Hi,
>
>> Maciej Fijalkowski did an opcode analysis for PyPy,
>> it also shows the relative frequency of opcodes following a
>> specifc one:
>>
>> http://codespeak.net/svn/user/fijal/opcodes.txt
>
> Nice, but we have to be careful here: what is the tested workload?
> For example, I find it hard to believe that CALL_FUNCTION_VAR_KW would
> always (99%) be followed by STORE_FAST.
I'm sorry, I should have given a reference to the original message:
http://codespeak.net/pipermail/pypy-dev/2008q2/004666.html
> I'm not even sure we're talking about the same VM/compiler. What are
> CALL_LIKELY_BUILTIN and LOOKUP_METHOD? :-)
He used the PyPy compiler, of course.
>> Might it make sense to add more PREDICT()ions based
>> on this, e.g. for BUILD_SLICE -> BINARY_SUBSCR?
>
> This particular one sounds fine, yes.
>
> Another approach is to create opcodes which better reflect actual usage.
> For example part of the following patch (*) was to create opcodes fusing
> JUMP_IF_{TRUE,FALSE} and POP_TOP. This is because in most cases, you want
> to pop the comparison result regardless of its value (true or false), which
> nowadays produces the following kind of code:
>
> JUMP_IF_FALSE <branch_for_false>
> POP_TOP
> [... do stuff and then ...]
> JUMP_FORWARD <branch_for_false_after_pop_top>
> branch_for_false:
> POP_TOP
> branch_for_false_after_pop_top:
> [etc.]
>
> With a JUMP_IF_FALSE which also pops the pop of the stack, this gives:
>
> JUMP_IF_FALSE <branch_for_false>
> [... do stuff and then ...]
> branch_for_false:
> [etc.]
>
> Prediction doesn't help you in this case.
Agreed; is there a way for a JUMP to end up without popping the top
after jumping? It would have to do a DUP first then.
Georg
More information about the Python-Dev
mailing list