A third attempt at super().meth() optimization via combined instructions

[Fidget-Spinner]

Currently super().meth() creates the following bytecode:

>>> dis.dis("super().meth()")
              0 RESUME                   0

  1           2 LOAD_NAME                0 (super)
              4 CALL_NO_KW               0
              6 LOAD_METHOD              1 (meth)
              8 PRECALL_METHOD           0
             10 CALL_NO_KW               0
             12 RETURN_VALUE

Past Optimization Attempts

1. The Cinder?(or Pyston?) team opened a PR against CPython to optimize this at the compiler level and emit super-specific bytecode. This was met with some opposition due to the compiler complexity introduced (it also special-cased super in the compiler, treating it almost like a keyword).

2. I attempted a LOAD_METHOD_SUPER specialization, but it barely produced speedups (and also segfaults generously). The bulk of CPU time still went to the creation of a custom super object.

Proposal (Attempt 3)

I propose we fuse the CALL_NO_KW + LOAD_METHOD instruction using the runtime specializer. This combined instruction will then look like this:

CALL_NO_KW__LOAD_METHOD():
    if (oparg == 0 and type(TOS) == super):
        # Get all the usual information that a super() object would have but inline.
        # Lookup the method using that information (no inline cache here sadly :()
    # Normal non-super combined instruction route...

Benefits:

• Doesn't touch the compiler, so we avoid the complaints in attempt 1.
• Completely avoids creation of a super() object, which should be a huge speedup.
• We should be able to make super().meth() lookup work with our pre-existing type method cache (MCACHE) in CPython. Currently every super() object is newly allocated, so CPython's type method cache stores no information about method lookups on any super() call.

Cons:

• Our current infrastructure doesn't support inline caching for combined instructions, so we won't have inline cached method calls vs attempt 2. Nonetheless, we still have the type method cache, which will still be a significant improvement over our status quo of no cache at all.

I plan to implement this when I have the time to soon, unless there are major objections to this approach. Hopefully, this means that super().meth() calls will be near zero-cost (or at least as cheap as a normal self.meth() lookup can be currently :).

[gvanrossum]

Note that there are no calls to super() in the benchmark code (at least not directly, there may be some in some packages installed in some benchmark's venv). To prove the superiority of your solution you'd have to come up with a micro-benchmark that shows the effect, and we'd have to look for a real-world application that actually uses this frequently enough for it to matter.

[Fidget-Spinner]

Wow I didn't notice that our benchmarks have no super calls. Thanks for pointing that out! I agree that I'll need lots of research to prove any sort of optimization is worth it here.

[gvanrossum]

There are some super calls in deltablue, but they all pass the class and instance.

[brandtbucher]

Our current infrastructure doesn't support inline caching for combined instructions

You can get around this by creating an adaptive form for the first instruction (already done!), then specializing into a superinstruction.

[Fidget-Spinner]

I didn't realize I could do this. Thanks to your suggestion, I've managed to simplify a lot of the runtime!

[markshannon]

The problem with the static approach proposed in python/cpython#24936 is that it is bulky because it must handle both the slow and fast path. A specialized form only need include the happy path, so should be more compact at least.

I note that super doesn't support vectorcall, that might be a good first step to speed up super(...).