Wordcode v2, moved from -dev
Continuing discussion from https://mail.python.org/pipermail/python-dev/2016-February/143357.html I'm currently waiting for abarnert to accept my PR: https://github.com/abarnert/cpython/pull/1 which fixes tests. The only really failing test (ie which doesn't also fail on my stock python) is test_importlib since it seems I don't know how to update frozen modules or something Antoine wanted to know what I benchmarked. Fact is that I haven't been rigorous; I'm comparing Archlinux's stock python to my ./configure && make. That said pybench is 20s on stock python compared to 17s on wordcode On the matter of bytecode projects having to be updated, I've updated my Befunge Python JIT. I post some analysis in my PR on why this particular benchmark should go in the old one's favor @ https://github.com/abarnert/cpython/pull/1#issuecomment-186679849 Current funge.py: https://github.com/serprex/Befunge/blob/master/funge.py Wordcode wfunge.py: https://github.com/serprex/Befunge/blob/master/wfunge.py Stock python runs Mandelbrot in 30s vs 28s on wfunge, & 3.3s vs 2.9 for beer6.bf (Mandel is a benchmark of generated code, whereas beer6 is mostly a benchmark of the JIT recompiling This also serves to demonstrate that current projects can be updated quite straightforwardly, worst case they change to always emitting EXTENDED_ARG for opcodes >= STORE_FAST In the pull request I've removed HAVE_ARGUMENT. I believe this'll help in porting things to fail-fast since HAVE_ARGUMENT's usage in code essentially must change, but perhaps one could add \x90 back as a constant named DOES_NOT_IGNORE_ARGUMENT I'd like to ask someone who isn't involved in development of this branch to verify my benchmark results Befunge-93 programs I mentioned: http://quadium.net/funge/downloads/bef93src/beer6.bf http://quadium.net/funge/downloads/bef93src/mandel.bf Still to do is at least investigate halving opargs for jump instructions
I haven't been able to build and test this, because I can't build Python on Mac at all anymore. I believe this is because #25136 is much more serious now (Xcode 7 is the released version, and the 10.11 CLT corresponds to it so that workaround no longer works). So I just accepted the PR so anyone else who wants to play with and/or test the code can do so on my fork (https://github.com/abarnert/cpython branch wpy). Sent from my iPhone
I think that it might be a good idea to add something like this back in on the Python side, but not the C equivalent. There are really two different reasons to use HAVE_ARGUMENT: to read 1 bytes instead of 3, and to skip any figuring-out-what-the-arg-means code. The former is no longer valid with wordcode, but the latter still is. Or, alternatively, maybe just add "hasarg = range(90, 256)" to dis, as a sequence of bytecodes that have any meaningful argument (to go with dis.hasjrel, etc.).
I haven't been able to build and test this, because I can't build Python on Mac at all anymore. I believe this is because #25136 is much more serious now (Xcode 7 is the released version, and the 10.11 CLT corresponds to it so that workaround no longer works). So I just accepted the PR so anyone else who wants to play with and/or test the code can do so on my fork (https://github.com/abarnert/cpython branch wpy). Sent from my iPhone
I think that it might be a good idea to add something like this back in on the Python side, but not the C equivalent. There are really two different reasons to use HAVE_ARGUMENT: to read 1 bytes instead of 3, and to skip any figuring-out-what-the-arg-means code. The former is no longer valid with wordcode, but the latter still is. Or, alternatively, maybe just add "hasarg = range(90, 256)" to dis, as a sequence of bytecodes that have any meaningful argument (to go with dis.hasjrel, etc.).
participants (3)
-
Andrew Barnert -
Brett Cannon -
Demur Rumed