Home Original page

[Python-Dev] Opcode cache in ceval loop

Yury Selivanov yselivanov.ml at gmail.com
Mon Feb 1 15:16:55 EST 2016 
Brett,

On 2016-02-01 3:08 PM, Brett Cannon wrote:
>
>
> On Mon, 1 Feb 2016 at 11:51 Yury Selivanov <yselivanov.ml at gmail.com 
> <mailto:yselivanov.ml at gmail.com>> wrote:
>
>     Hi Brett,
>
[..]
>
>
>     The first two fields are used to make sure that we have objects of the
>     same type.  If it changes, we deoptimize the opcode immediately.  Then
>     we try the offset.  If it's successful - we have a cache hit.  If not,
>     that's fine, we'll try another few times before deoptimizing the
>     opcode.
>
>
> So this is a third "next step" that has its own issue?

It's all in issue http://bugs.python.org/issue26219 right now.

My current plan is to implement LOAD_METHOD/CALL_METHOD (just opcodes, 
no cache) in 26110.

Then implement caching for LOAD_METHOD, LOAD_GLOBAL, and LOAD_ATTR in 
26219.  I'm flexible to break down 26219 in three separate issues if 
that helps the review process (but that would take more of my time):

- implement support for opcode caching (general infrastructure) + 
LOAD_GLOBAL optimization
- LOAD_METHOD optimization
- LOAD_ATTR optimization

Yury
More information about the Python-Dev mailing list