4 ms·

Did someone try to implement a processor that runs Python VM bytecode natively, as it was attempted for Java[1]? I wonder how fast Python would run by replacing

by Qem 2y ago

Did someone try to implement a processor that runs Python VM bytecode natively, as it was attempted for Java[1]? I wonder how fast Python would run by replacing a virtual machine with a physical Python machine. [1] https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor

btown 2y ago
A decade ago, https://pycpu.wordpress.com/ https://pycpu.wordpress.com/ was a prototype that turned a small subset of Python bytecode, as well as the specifications for a system to run it, into VHDL/Verilog (via myhdl.org) to run on an FPGA. In theory, I imagine it would be possible to take this approach and transpile something like https://doc.pypy.org/en/latest/interpreter.html https://doc.pypy.org/en/latest/interpreter.html to an HDL. But a more reasonable thing to do would be to look down the road that JIT's and other similar technologies are coming to mainline CPython, see e.g. https://tonybaloney.github.io/posts/python-gets-a-jit.html https://tonybaloney.github.io/posts/python-gets-a-jit.html - and thus it might make sense to have some of the unique semantics of Python opcodes be adopted by specifications like ARM, similar to how ARM created the FJCVTZS opcode to exactly match Javascript's ToInt32 specification: https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... -> https://tc39.es/ecma262/#sec-toint32 https://tc39.es/ecma262/#sec-toint32
sitkack 2y ago
The problem is that the bytecodes aren't where the work is done, so speeding up the bytecode portion of the VM would get you negligible speedups. The interpreter is a glorified dynamic dispatch mechanism to code that then has to figure out the type of the arguments and then call the relevant routine. Unless the bytecode VM is doing type tracing, the speedup from just a hardware inner loop will get you probably single digit percentage speedup. But I could see a hardware VM that was a combination of a regular CPU and some of the hot code paths in interpreter as well as operations on primitives of arrays being sped up. The Java processors had the advantage of static types.

by Qem 2y ago

btown 2y ago

A decade ago, https://pycpu.wordpress.com/ https://pycpu.wordpress.com/ was a prototype that turned a small subset of Python bytecode, as well as the specifications for a system to run it, into VHDL/Verilog (via myhdl.org) to run on an FPGA. In theory, I imagine it would be possible to take this approach and transpile something like https://doc.pypy.org/en/latest/interpreter.html https://doc.pypy.org/en/latest/interpreter.html to an HDL. But a more reasonable thing to do would be to look down the road that JIT's and other similar technologies are coming to mainline CPython, see e.g. https://tonybaloney.github.io/posts/python-gets-a-jit.html https://tonybaloney.github.io/posts/python-gets-a-jit.html - and thus it might make sense to have some of the unique semantics of Python opcodes be adopted by specifications like ARM, similar to how ARM created the FJCVTZS opcode to exactly match Javascript's ToInt32 specification: https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... -> https://tc39.es/ecma262/#sec-toint32 https://tc39.es/ecma262/#sec-toint32

sitkack 2y ago

The problem is that the bytecodes aren't where the work is done, so speeding up the bytecode portion of the VM would get you negligible speedups. The interpreter is a glorified dynamic dispatch mechanism to code that then has to figure out the type of the arguments and then call the relevant routine. Unless the bytecode VM is doing type tracing, the speedup from just a hardware inner loop will get you probably single digit percentage speedup. But I could see a hardware VM that was a combination of a regular CPU and some of the hot code paths in interpreter as well as operations on primitives of arrays being sped up. The Java processors had the advantage of static types.