[Python-Dev] Opcode cache in ceval loop (original) (raw)

Brett Cannon brett at python.org
Mon Feb 1 15:21:06 EST 2016

On Mon, 1 Feb 2016 at 12:16 Yury Selivanov <yselivanov.ml at gmail.com> wrote:

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 LOADMETHOD/CALLMETHOD (just opcodes, no cache) in 26110. Then implement caching for LOADMETHOD, LOADGLOBAL, and LOADATTR 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) + LOADGLOBAL optimization - LOADMETHOD optimization - LOADATTR optimization

I personally don't care how you break it down, just trying to keep all the moving pieces in my head. :)

Anyway, it sounds like PEP 509 is blocking part of it, but the LOAD_METHOD stuff can go in as-is. So are you truly blocked only on getting the latest version of that patch up to http://bugs.python.org/issue26110 and getting a code review? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160201/04caf59b/attachment.html>

More information about the Python-Dev mailing list