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 at gmail.com > <mailto:benhoyt at 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 at python.org <mailto:Python-Dev at 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 at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/mark%40hotpy.org >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4