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

[Mark Shannon]

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
>