Author gvanrossum
Recipients BTaskaya, Mark.Shannon, eric.snow, gvanrossum, pablogsal, rhettinger, serhiy.storchaka, terry.reedy, tim.peters
Date 2021-04-05.21:33:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1617658385.31.0.306259103246.issue43684@roundup.psfhosted.org>
In-reply-to
Content
So dynamically, I see about 0.5% of all opcodes are ADD_INT, so higher than statically (which was 0.1%) but still small enough that I'm abandoning work on ADD_INT.

I've got a branch where I'm adding POP_JUMP_IF_NONE and POP_JUMP_IF_NOT_NONE (which capture if x is None, if x is not None) but the static count there is still pretty low, around 0.2% statically. These numbers are remarkably stable -- I get 0.2% exactly for mypy, 0.18% for the stdlib. (A bit more in the azure-cli source code: 0.35%.)

I expect that the dynamic count here would be a bit higher too: without running it, I'd expect around 1%, if we take it that the average loop does about 5 iterations -- my results for ADD_INT would lead to that conclusion, and this was independently verified by an Instagram blog post from 2017. (https://instagram-engineering.com/profiling-cpython-at-instagram-89d4cbeeb898, search for "loopyness")

Is that enough to persevere? I really don't know.

I have a few other potential opcode combinations, RETURN_CONST and RETURN_NONE, but since those (by definition) don't occur in a loop, I'm even less optimistic about the value of those.

We really should optimize things like LOAD_FAST + LOAD_FAST, which occurs much more frequently. However the way to encode that combination is pretty gross, and I'd rather do that another time.
History
Date User Action Args
2021-04-05 21:33:05gvanrossumsetrecipients: + gvanrossum, tim.peters, rhettinger, terry.reedy, Mark.Shannon, eric.snow, serhiy.storchaka, pablogsal, BTaskaya
2021-04-05 21:33:05gvanrossumsetmessageid: <1617658385.31.0.306259103246.issue43684@roundup.psfhosted.org>
2021-04-05 21:33:05gvanrossumlinkissue43684 messages
2021-04-05 21:33:04gvanrossumcreate