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" <m...@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" <benh...@gmail.com >> <mailto:benh...@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 >
_______________________________________________ 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
