[Python-Dev] Wordcode v2 (original) (raw)

Maciej Fijalkowski fijall at gmail.com
Mon Feb 15 02:13:06 EST 2016

On Mon, Feb 15, 2016 at 4:05 AM, Guido van Rossum <guido at python.org> wrote:

I think it's probably too soon to discuss on python-dev, but I do think that something like this could be attempted in 3.6 or (more likely) 3.7, if it really is faster.

An unfortunate issue however is that many projects seem to make a hobby of hacking bytecode. All those projects would have to be totally rewritten in order to support the new wordcode format (as opposed to just having to be slightly adjusted to support the occasional new bytecode opcode). Those projects of course don't work with Pypy or Jython either, but they do work for mainstream CPython, and it's unacceptable to just leave them all behind.

They mostly work with PyPy (which has 2 or 3 additional bytecodes, but nothing too dramatic)

As an example, AFAIK coverage.py interprets bytecode. This is an important piece of infrastructure that we wouldn't want to leave behind. I think py.test's assert-rewrite code also generates or looks at bytecode. Also important. All of which means that it's more likely to make it into 3.7. See you on python-ideas! --Guido On Sun, Feb 14, 2016 at 4:20 PM, Demur Rumed <gunkmute at gmail.com> wrote: Saw recent discussion: https://mail.python.org/pipermail/python-dev/2016-February/143013.html

I remember trying WPython; it was fast. Unfortunately it feels it came at the wrong time when development was invested in getting py3k out the door. It also had a lot of other ideas like *INT instructions which allowed having oparg to be a constant int rather than needing to LOADCONST one. Anyways I'll stop reminiscing abarnert has started an experiment with wordcode: https://github.com/abarnert/cpython/blob/c095a32f2a68ac708466b9c64906cc4d0f5de1ee/Python/wordcode.md I've personally benchmarked this fork with positive results. This experiment seeks to be conservative-- it doesn't seek to introduce new opcodes or combine BINARYOP's all into a single op where the currently unused-in-wordcode arg then states the kind of binary op (à la COMPAREOP). I've submitted a pull request which is working on fixing tests & updating peephole.c Bringing this up on the list to figure out if there's interest in a basic wordcode change. It feels like there's no downsides: faster code, smaller bytecode, simpler interpretation of bytecode (The Nth instruction starts at the 2Nth byte if you count EXTENDEDARG as an instruction). The only downside is the transitional cost What'd be necessary for this to be pulled upstream?

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/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

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/fijall%40gmail.com

More information about the Python-Dev mailing list