On Mon, 1 Feb 2016 at 09:08 Yury Selivanov <yselivanov...@gmail.com> wrote:
> > > On 2016-01-29 11:28 PM, Steven D'Aprano wrote: > > On Wed, Jan 27, 2016 at 01:25:27PM -0500, Yury Selivanov wrote: > >> Hi, > >> > >> > >> tl;dr The summary is that I have a patch that improves CPython > >> performance up to 5-10% on macro benchmarks. Benchmarks results on > >> Macbook Pro/Mac OS X, desktop CPU/Linux, server CPU/Linux are available > >> at [1]. There are no slowdowns that I could reproduce consistently. > > Have you looked at Cesare Di Mauro's wpython? As far as I know, it's now > > unmaintained, and the project repo on Google Code appears to be dead (I > > get a 404), but I understand that it was significantly faster than > > CPython back in the 2.6 days. > > > > > https://wpython.googlecode.com/files/Beyond%20Bytecode%20-%20A%20Wordcode-based%20Python.pdf > > > > > > Thanks for bringing this up! > > IIRC wpython was about using "fat" bytecodes, i.e. using 64bits per > bytecode instead of 8. That allows to minimize the number of bytecodes, > thus having some performance increase. TBH, I don't think it was > "significantly faster". > > If I were to do some big refactoring of the ceval loop, I'd probably > consider implementing a register VM. While register VMs are a bit > faster than stack VMs (up to 20-30%), they would also allow us to apply > more optimizations, and even bolt on a simple JIT compiler. > If you did tackle the register VM approach that would also settle a long-standing question of whether a certain optimization works for Python. As for bolting on a JIT, the whole point of Pyjion is to see if that's worth it for CPython, so that's already being taken care of (and is actually easier with a stack-based VM since the JIT engine we're using is stack-based itself).
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com