GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||||||||
GeezerVison is showing github.com — GH-125837: Split `LOAD_CONST` into three. by markshannon · Pull Request #125972 · python/cpython Conversation
|
I think the range is -5 -> 256 (included) right? (at least _PyLong_SMALL_INTS works that way, but maybe 256 should be excluded even though it's stored in the _PyLong_SMALL_INTS). |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
I want We can always add -5,-4,-3,-2 and -1 to |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Performance for tier 1 appears to be about 0.5% faster. Stats show the following fraction of constants loaded:
With a reduction in increfs of immortal objects of about 20%. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| for (int i = 0; i < b->b_iused; i++) { | ||
| if (OPCODE_HAS_CONST(b->b_instr[i].i_opcode)) { | ||
| int opcode = b->b_instr[i].i_opcode; | ||
| if (OPCODE_HAS_CONST(opcode) && opcode != LOAD_SMALL_INT) { |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
hasconst is defined in the dis docs as "Sequence of bytecodes that access a constant". I think it will make more sense if we clarify that it means "access a constant from co_consts" and then remove LOAD_SMALL_INT from hasconst and OPCODE_HAS_CONST.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. LOAD_COMMON_CONST is not in hasconst.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's worth testing whether creating integers within the range(256) will not affect co_consts?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I don't want to go overboard on testing internal details of the bytecode compiler.
LOAD_CONST with a small int is still correct, just a bit less efficient than LOAD_SMALL_INT.
We already have plenty of tests in test_dis that test this
Sorry, something went wrong.
There was an error while loading. Please reload this page.
…om code.co_consts
There was an error while loading. Please reload this page.
* Add LOAD_CONST_IMMORTAL opcode * Add LOAD_SMALL_INT opcode * Remove RETURN_CONST opcode
* Add LOAD_CONST_IMMORTAL opcode * Add LOAD_SMALL_INT opcode * Remove RETURN_CONST opcode
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.