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