
On Mon, Feb 15, 2016 at 4:05 AM, Guido van Rossum <guido@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@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/c095a32f2a68ac708466b9c64906cc4d0f5...
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