[Python-Dev] Wordcode v2

[Guido van Rossum]

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.

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 LOAD_CONST 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 BINARY_OP's all into a single op where the currently
> unused-in-wordcode arg then states the kind of binary op (à la COMPARE_OP).
> 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 EXTENDED_ARG 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)