[Python-Dev] Speeding up CPython 5-10% (original) (raw)

Peter Ludemann pludemann at google.com
Tue Feb 2 12:33:52 EST 2016

Also, modern compiler technology tends to use "infinite register" machines for the intermediate representation, then uses register coloring to assign the actual registers (and generate spill code if needed). I've seen work on inter-function optimization for avoiding some register loads and stores (combined with tail-call optimization, it can turn recursive calls into loops in the register machine).

On 2 February 2016 at 09:16, Sven R. Kunze <srkunze at mail.de> wrote:

On 02.02.2016 00:27, Greg Ewing wrote:

Sven R. Kunze wrote:

Are there some resources on why register machines are considered faster than stack machines?

If a register VM is faster, it's probably because each register instruction does the work of about 2-3 stack instructions, meaning less trips around the eval loop, so less unpredictable branches and less pipeline flushes. That's was I found so far as well. This assumes that bytecode dispatching is a substantial fraction of the time taken to execute each instruction. For something like cpython, where the operations carried out by the bytecodes involve a substantial amount of work, this may not be true. Interesting point indeed. It makes sense that register machines only saves us the bytecode dispatching. How much that is compared to the work each instruction requires, I cannot say. Maybe, Yury has a better understanding here. It also assumes the VM is executing the bytecodes directly. If there is a JIT involved, it all gets translated into something else anyway, and then it's more a matter of whether you find it easier to design the JIT to deal with stack or register code. It seems like Yury thinks so. He didn't tell use so far. Best, Sven

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/pludemann%40google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160202/f7b26f2b/attachment.html>

More information about the Python-Dev mailing list