After reading Cesare Di Mauro's email, I realized that I was thinking to WPython in fact... Victor Le 25 mai 2017 8:11 PM, "Mark Shannon" <mark@hotpy.org> a écrit :
On 25/05/17 03:47, Victor Stinner wrote:
Hi Ben,
I am not convinced that combining operations will have a significant impact in term of performance. Mark Shanon implemented that in his HotPy project.
I don't think that I did ;) HotPy implemented a trace-based optimising interpreter, that preformed type specialisation and deferred evaluation of objects, with a "dumb" compiler that applied standard optimisations to the resulting traces. It was technologically similar to PyPy (at the time), but designed for ease of engineering,
I proposed a RETURN_NONE opcode to combine LOAD_CONST with RETURN_VALUE. The issue was rejected because I failed to show any speedup.
https://bugs.python.org/issue28800
I would be interested to restart/finish my registervm project to use register-based bytecode. It allows to implement more optmisations and reduce the number of instructions. In my experience, less instructions = faster code.
http://faster-cpython.readthedocs.io/registervm.html
Mark's bytecode uses registers but also a stack.
The "registers" were used to hold values across calls and the like when optimising traces, but I wouldn't use that design if I were to do it again.
Victor
Le 24 mai 2017 8:09 PM, "Ben Hoyt" <benhoyt@gmail.com <mailto:benhoyt@gmail.com>> a écrit :
Hi folks,
I was looking at some `dis` output today, and I was wondering if anyone has investigated optimizing Python (slightly) by adding special-case bytecodes for common expressions or statements involving constants?
For example, I (and, based on a quick grep of the stdlib, many others) write "x is None" and "x is not None" very often. Or "return True" or "return None" or "return 1" and things like that. These all expand into two bytecodes, which seems pretty non-optimal (LOAD_CONST + COMPARE_OP or LOAD_CONST + RETURN_VALUE). It seems we could get an easy speedup for these common cases by adding a peephole optimization and some new opcodes (maybe COMPARE_IS_SMALL_CONST and RETURN_SMALL_CONST for these cases).
I'm not proposing to do this yet, as I'd need to benchmark to see how much of a gain (if any) it would amount to, but I'm just wondering if there's any previous work on this kind of thing. Or, if not, any other thoughts before I try it?
Thanks, Ben
_______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev> Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor. stinner%40gmail.com <https://mail.python.org/mailman/options/python-dev/victor. stinner%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/mark% 40hotpy.org
_______________________________________________ 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/victor. stinner%40gmail.com