On Mon, Feb 15, 2016 at 4:05 AM, Guido van Rossum <gu...@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 <gunkm...@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@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com _______________________________________________ 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
