More Snail Skipping - more questions

TL;DR - performance improvement likely possible. But should we do this
  now? How does it impact 'experimental' status.


I've had another go at skipping the snail-array setup for signatured
subs, and measuring some more benchmarks. Two changes since last time:

  * I'm benchmarking a variety of scenarios of different argument
    counts. Zero, one, two (including a shift, as common in methods),
    and many (again including a shift).

  * I have a much simpler set of code changes against bleadperl.

New benchmarking script is attached.


Again as before I haven't actually implemented the @_-less signatures,
so right now every signatured parameter just appears as undef / empty
list, and there are no arity checks. This makes the current numbers
something of an over-estimate of the potential gains as any real
implementation would have to perform more work than this.

First off for comparison, a current bleadperl[1]:

  ## ZERO ARGS
  full0: 1.2142s
  bare0: 0.7422s (speedup x1.64)
  sigs0: 0.8382s (speedup x1.45)

  ## ONE ARG
  full1: 1.9603s
  bare1: 1.4695s (speedup x1.33)
  sigs1: 1.3754s (speedup x1.43)

  ## TWO ARG (method)
  fullM: 2.6338s
  bareM: 2.1455s (speedup x1.23)
  sigsM: 2.0900s (speedup x1.26)

  ## TEN ARG (method)
  fullN: 2.5038s
  bareN: 1.9723s (speedup x1.27)
  sigsN: 2.9242s (speedup x0.86)

And now with the-attached tiny patch, which simply applies the same
"no-hasargs" behaviour to CvSIGNATURE'ed subs as perl4-style &SUB calls
have, and stubs out the pp_argcheck and pp_argelem functions into
no-ops:

  ## ZERO ARGS
  full0: 1.2501s
  bare0: 0.7560s (speedup x1.65)
  sigs0: 0.9096s (speedup x1.37)

  ## ONE ARG
  full1: 2.1648s
  bare1: 1.4403s (speedup x1.50)
  sigs1: 1.6795s (speedup x1.29)

  ## TWO ARG (method)
  fullM: 2.9373s
  bareM: 2.4037s (speedup x1.22)
  sigsM: 2.0959s (speedup x1.40)

  ## TEN ARG (method)
  fullN: 2.7339s
  bareN: 2.0558s (speedup x1.33)
  sigsN: 1.4249s (speedup x1.92)

These numbers are looking somewhat more promising than the last time I
tried. In particular, it seems to make quite a significant improvement
once we start to look at larger argument counts - the TEN ARG case is
almost twice as fast. I expect that distinction to only grow the more
arguments are actually passed. Even just a two-argument case appears a
little better (40% speedup on this patch vs. 25% on blead).

It therefore appears that there may indeed be merit in looking into a
performance optimisation on the theme of avoiding the @_/PAD_SV(0)
setup overhead for signatured subs.

On the basis of these numbers, I think it would be good to continue
investigating a real implementation that actually permits OP_ARGCHECK
and OP_ARGELEM to continue working. Dave Mitchell and myself discussed
various options on how that might be implemented - I'll have a quick
hack at something to see how easily that can be done.

With the potential idea that OP_ENTERSUB could be made order-of twice
as fast on calls with lots of arguments being passed, the question
remains:

  Is this a potential change we would want to include in 5.36, if it
  can be implemented in time for the 20th Feb code-freeze?

The implications of doing this currently are:

  * A significant behaviour change to signatured subs since 5.34.
    Sufficiently significant that if we do this, I do not think we
    should remove the 'experimental' tag at the same time.

  * If we skip @_ setup in signatured subs, then a significant number
    of current behaviours become impossible there, as compared to 5.34.
    No longer would any of these be permitted:

          sub mutator($self, $new = undef) {
            $self->{field} = $new if @_ > 1;
          }

          sub wrapper($x, @) {
            say "Calling otherfunc on x=$x";
            otherfunc(@_);
          }

          sub inplace_uc($s) {
            $_[0] = uc $s;
          }

          sub tailcall($code, @args) {
            @_ = @args;
            goto &$code;
          }

    There are suggested extensions to signatures syntax that would
    implement most of these (the first two by query parameters, the
    third by an aliasing argument), and likely the fourth could be
    tackled by adding a `builtin::tailcall` or othersuch. But those
    remain aspirational at present and not something we can rely on
    right now.

---

[1] git commit hash e1c60a5de8 built with -O3 non-DEBUGGING

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

• More Snail Skipping - more questions by Paul "LeoNerd" Evans
• Re: More Snail Skipping - more questions by hv