Repository navigation
Remove superinstructions #105229
Description
Superinstructions offer a small speedup, but their existence complicates things; mainly instrumentation, and specialization.
The tier2 optimizer is likely to be simpler without superinstructions.
This experiment shows that combining the most common superinstructions into single instructions can outperform superinstructions, rendering superinstructions pointless.
We have already removed almost all superinstructions in specialization. We should remove them altogether.
Activity
markshannon commentedon Jun 2, 2023
faster-cpython/ideas#585
corona10 commentedon Jun 2, 2023
Question: One good thing of super instruction is that we can hide the optimization detail to end user.
But from this change, if we need to optmize opcodes with concatnation. Do we have to introduce the new opcode or still prefer to experiment it as the super instruction?
cc @carljm @Fidget-Spinner
markshannon commentedon Jun 2, 2023
What do you mean by the "end user"?
Python programmers really shouldn't be concerned about bytecode, except in a "I wonder how this works" kind of way.
LOAD_FAST_LOAD_FASTis lot easier to understand than instructions likeRETURN_GENERATORorCLEANUP_THROWcorona10 commentedon Jun 2, 2023
Ah I meant Python programmers. Thanks.
Okay, Looks like it was just my thought. I loved super instruction from the view of hidden optimization implementation detail. (we don't have to update magic number for the optimization)
So still questions left if we decide to remove the current super-instruction mechanism.
(I am not sure which case will be)
Thank you for answering for all :)
corona10 commentedon Jun 2, 2023
While I am reading the code, it looks like happening at the last moment of optimization. So it will not happen?
(Or can it be issued at Tier 2?)
markshannon commentedon Jun 2, 2023
Forming superinstructions should done after all other optimizations, so won't interfere those.
It could be done in the assembler.
markshannon commentedon Jun 2, 2023
For the reasons given above, I want to remove all superinstructions. The benefit will be negligible after merging #105230, and reasoning about instrumentation, etc. is simpler without them.
corona10 commentedon Jun 2, 2023
I am asking about the new single opcodes(in #105230, LOAD_FAST_LOAD_FAST / STORE_FAST_LOAD_FAST / STORE_FAST_LOAD_FAST ) that will alter the existing super instruction. :)
Sorry to make you confused!
I am asking about a situation when someone needs to add a new single opcode concatenated by multiple opcodes.
Because it doesn't require a runtime cost, so the execution of frequency is less important than before.
terryjreedy commentedon Jun 2, 2023
Link goes nowhere for me.
markshannon commentedon Jun 2, 2023
Fixed the link
GH-105229: Replace some superinstructions with single instruction equ…
GH-105229: Remove remaining two-codeunit superinstructions (GH-105326)
gvanrossum commentedon Jun 9, 2023
@markshannon Should I just remove the super-instruction support from the cases generator? That would simplify a lot of things! (There are a bunch of things that are factored somewhat awkwardly to share common code between super and macro while also honoring their differences.)
DECISION: Yes, remove it. Also remove support for legacy
instrsyntax (without stack/cache effect syntax).gh-105229: Remove syntactic support for super-instructions (#105703)
gvanrossum commentedon Jun 12, 2023
@carljm FYI. I forgot that Cinder now uses the generator to override some opcodes and add others. Hopefully you're not using super-instructions, or we'd have to roll back gh-105703.
carljm commentedon Jun 12, 2023
Nope, we don't need the super-instruction support. Thanks for thinking of us! I am generally watching changes in these areas and will pipe up if I see anything happening that would be a problem for us.