Re:How Python bytecode is executed
by fulafel on Monday November 09, 2020 @03:16PM
(#25039351)
Would the loop be amenable to speedups from parallel execution? Some kind of parallel idempotent run ahead version of the loop might at least prime caches and resolve some dynamic dispatch stuff in advance. A bit like runahead execution in cpu design.
[ Parent
| on HN ]
If you squint, this is basically what a JIT compiler such as PyPy does. The compiled code has a fast hot path that assumes that every branch and dynamic dispatch will work the way you expect it to, and if it doesn't then it falls back into the interpreter.
Re:How Python bytecode is executed
by jashmatthews on Monday November 09, 2020 @09:03PM
(#25042146)
The fast bytecode VMs do pre-fetch the operands to maximize Instruction Level Parallelism: https://www.reddit.com/r/programming/comments/badl2/luajit_2...
They also use "inline caching" where the result of method lookup is cached in the bytecode itself. Most of the time there's no need to try to pre-execute it.
The ultimate version of this idea of executing everything you can before running the dynamic bit is probably Partial Evaluation which is how GraalPython works.
Yep, Psyco was also based on partial evaluation and Futamura projections IIRC, lots of potential there.
I guess the very ultimate version is a transformation that takes your program AND its inputs, and completely specializes everything to those inputs :)
An advantage of the runahead idea is that with luck the change could be small and simple, and might realistically be accepted as an incremental change into the CPython codebase. Iff the runahead could be made truly guaranteed idempotent and obviously correct.
Re:How Python bytecode is executed
by tachyonbeam on Monday November 09, 2020 @04:27PM
(#25040137)
Might also punt things you need out of the cache if it runs too far ahead?