At 07:38 AM 3/9/04 -0600, Jeff Epler wrote:
>Recently it was proposed to make a new LIST_APPEND opcode, and several
>contributors pointed out that adding opcodes to Python is always a dicey
>business because it may hurt performance for obscure reasons, possibly
>related to the size of that 'switch' statement.
>
>To that end, I notice that there are several opcodes which could easily
>be converted into function calls. In my code, these are not typically
>performance-critical opcodes (with approximate ceval.c line count):
> BUILD_CLASS # 9 lines
> MAKE_FUNCTION # 20 lines
> MAKE_CLOSURE # 35 lines
>
> PRINT_EXPR # 21 lines
> PRINT_ITEM # 47 lines
> PRINT_ITEM_TO # 2 lines + fallthrough
> PRINT_NEWLINE # 12 lines
> PRINT_NEWLINE_TO # 2 lines + fallthrough
>
>Instead, each of these would be available in the code objects co_consts
>when necessary. For example, instead of
> LOAD_CONST 1 (<code object g at 0x40165ea0, file
> "<stdin>", line 2>)
> MAKE_FUNCTION 0
> STORE_FAST 0 (g)
>you'd have
> LOAD_CONST 1 (type 'function')
> LOAD_CONST 2 (<code object g>)
> LOAD_GLOBALS # new opcode, or call
> globals()
> LOAD_CONST 1 ("g")
> CALL_FUNCTION 3
>
>Performance for these specific operations will certainly benchmark worse,
>but maybe getting rid of something like 150 lines from ceval.c would
>help other things by magic. The new LOAD_GLOBALS opcode would be less
>than 10 lines.
>
>No, I don't have a patch. I assume each and every one of these opcodes
>has a staunch defender who will now come to its aid, and save me the
>trouble.
If the goal is to remove lines from the switch statement, just move the
code of lesser-used opcodes into a C function. There's no need to
eliminate the opcodes themselves.
I personally don't think it'll help much, if the goal is to reduce cache
misses. After all, the code is all still there. But, it should not do as
badly as the approach you're suggesting, because for your case you'll not
only have the C-level calls, but also more bytecodes being interpreted.
Hm. Makes me wonder, actually, if a hand-written eval loop in assembly
code might not kick some serious butt. Or maybe a bytecode-to-assembly
translator, writing loads in-line and using registers as the stack, calling
functions where necessary. Ah, if only I were a teenager again, with
little need to sleep, and unlimited time to hack... :)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4