[Python-Dev] Opcode cache in ceval loop (original) (raw)
Yury Selivanov yselivanov.ml at gmail.com
Mon Feb 1 15:16:55 EST 2016
- Previous message (by thread): [Python-Dev] Opcode cache in ceval loop
- Next message (by thread): [Python-Dev] Opcode cache in ceval loop
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] Opcode cache in ceval loop
- Next message (by thread): [Python-Dev] Opcode cache in ceval loop
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]