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

[Ben Hoyt]

Interesting -- thanks very much, Erik. Yeah, I wonder if the wordcode will
change things too. But interesting to know you got not much of a speedup!
Also, the "x is None" and "x is not None" were the opcodes I started out
thinking would be helpful, so I'm interested to try those.

I'm wondering if the simplest way to test would be to add the new opcodes
and handle them in ceval.c, but then do all the bytecode manipulation in a
pure Python peephole optimizer ("bytecode munger"). Then if it worked we
could put those optimizations in the compiler or peephole.c.

-Ben

On Wed, May 24, 2017 at 4:14 PM, Erik <python at lucidity.plus.com> wrote:

> Hi Ben,
>
> On 24/05/17 19:07, Ben Hoyt wrote:
>
>> 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?
>>
>
> This is exactly what I looked into just over a year ago. As Stephane
> suggests, I did this by adding new opcodes that the peephole optimizer
> generated and the interpreter loop understood (but the compiler itself did
> not need to know anything about these new opcodes, so that makes things
> much easier).
>
>
>
> Adding new opcodes like this at the time wasn't straightforward because of
> issues with the build process (see this thread:
> https://mail.python.org/pipermail/python-dev/2015-December/142600.html -
> it starts out as a question about the bytecode format but ended up with
> some very useful information on the build process).
>
> Note that since that thread, a couple of things have changed - the
> bytecode is now wordcode so some of my original questions aren't relevant,
> and some of the things I had a problem with in the build system are now
> auto-generated with a new 'make' target. So it _should_ be easier now than
> it was then.
>
>
>
> In terms of the results I got once I had things building and running, I
> didn't manage to find any particular magic bullets that gave me a
> significant enough speedup. Perhaps I just didn't pick the right opcode
> sequences or the right test cases (though what I was trying to do was quite
> successful in terms of doing things like replacing branches-to-RETURN into
> a single RETURN - so LOAD_CONST/RETURN_VALUE became RETURN_CONST and
> therefore if the target of an unconditional branch was to a RETURN_CONST
> op, the branch op could be replaced by the RETURN_CONST).
>
> I figured that one thing every function or method needs to do is return,
> so I tried to make that more efficient. I only had two weeks to spend on it
> though ...
>
> I was trying to do that by avoiding trips-around-the-interpreter-loop as
> that was historically something that would give speedups. However, with the
> new computed-goto version of the interpreter I came to the conclusion that
> it's not at important as it used to be. I was building with gcc though and
> what I *didn't* do was disable the computed-goto code (it's controlled by a
> #define) to see if my changes improved performance on platforms that can't
> use it.
>
>
> I have other opcode sequences that I identified that might be useful to
> look at further.
>
> I didn't (and still don't) have enough bandwidth to *drive* something like
> this through though, but if you want to do that I'd be more than happy to
> be kept in the loop on what you're doing and can possibly find time to
> write some code too.
>
> Regards, E.
>
> _______________________________________________
> 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/benhoyt%
> 40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170524/e8fa26aa/attachment.html>