[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Register-based VM [Was: Possible performance regression]

Hum, I read again my old REGISTERVM.txt that I wrote a few years ago.

A little bit more context. In my "registervm" fork I also tried to
implement further optimizations like moving invariants out of the
loop. Some optimizations could change the Python semantics, like
remove "duplicated" LOAD_GLOBAL whereas the global might be modified
in the middle. I wanted to experiment such optimizations. Maybe it was
a bad idea to convert stack-based bytecode to register-based bytecode
and experiment these optimizations at the same time.


Le mar. 26 f?vr. 2019 ? 22:42, Victor Stinner <vstinner at redhat.com> a ?crit :
> No, I wasn't aware of this project. My starting point was:
> http://static.usenix.org/events/vee05/full_papers/p153-yunhe.pdf
> Yunhe Shi, David Gregg, Andrew Beatty, M. Anton Ertl, 2005
> See also my email to python-dev that I sent in 2012:
> https://mail.python.org/pipermail/python-dev/2012-November/122777.html
> Ah, my main issue was my implementation is that I started without
> taking care of clearing registers when the stack-based bytecode
> implicitly cleared a reference (decref), like "POP_TOP" operation.
> I added "CLEAR_REG" late in the development and it caused me troubles,
> and the "correct" register-based bytecode was less efficient than
> bytecode without CLEAR_REG. But my optimizer was very limited, too
> limited.
> Another implementation issue that I had was to understand some
> "implicit usage" of the stack like try/except which do black magic,
> whereas I wanted to make everything explicit for registers. I'm
> talking about things like "POP_BLOCK" and "SETUP_EXCEPT". In my
> implementation, I kept support for stack-based bytecode, and so I had
> some inefficient code and some corner cases.
> My approach was to convert stack-based bytecode to register-based
> bytecode on the fly. Having both in the same code allowed to me run
> some benchmarks. Maybe it wasn't the best approach, but I didn't feel
> able to write a real compiler (AST => bytecode).
> Victor
> Le mar. 26 f?vr. 2019 ? 21:58, Neil Schemenauer <nas-python at python.ca> a ?crit :
> >
> > On 2019-02-26, Victor Stinner wrote:
> > > I made an attempt once and it was faster:
> > > https://faster-cpython.readthedocs.io/registervm.html
> >
> > Interesting.  I don't think I have seen that before.  Were you aware
> > of "Rattlesnake" before you started on that?  It seems your approach
> > is similar.  Probably not because I don't think it is easy to find.
> > I uploaded a tarfile I had on my PC to my web site:
> >
> >     http://python.ca/nas/python/rattlesnake20010813/
> >
> > It seems his name doesn't appear in the readme or source but I think
> > Rattlesnake was Skip Montanaro's project.  I suppose my idea of
> > unifying the local variables and the registers could have came from
> > Rattlesnake.  Very little new in the world. ;-P
> >
> > Cheers,
> >
> >   Neil
> --
> Night gathers, and now my watch begins. It shall not end until my death.

Night gathers, and now my watch begins. It shall not end until my death.