[Python-Dev] Micro-optimizations by adding special-case bytecodes?

[Victor Stinner]

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 at 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 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
>>
>> _______________________________________________
> 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/victor.
> stinner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170526/6c6eebbb/attachment.html>