Re: PSC #049 2022-01-07

Front page | perl.perl5.porters | Postings from January 2022

Thread Previous | Thread Next

From:

Alexander Hartmaier

Date:

January 12, 2022 21:07

Subject:

Re: PSC #049 2022-01-07

Message ID:

CAB49QrbqnVxqMSWvZKqyd86-96WnkF8LFdbme8EHqfzwr=Z9JA@mail.gmail.com

On Wed, Jan 12, 2022 at 5:06 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> On Wed, Jan 12, 2022, at 9:20 AM, Paul LeoNerd Evans wrote:
>
> On Mon, Jan 10, 2022 at 02:46:36PM -0800, Darren Duncan wrote:
> > If it were possible to do in a performant way, my actual preference is
> for
> > the behavior of signatures to fundamentally be a pretty syntactic
> shorthand
> > for unpacking "@_" elements into lexicals, and @_ continues to also be
> > available.
>
> Good news - that's exactly how it already works :)
>
>
> â¦and let's talk about "performant."  That just means "effective" or, often
> in programming, "fast enough to be acceptable."  Are subroutine signatures
> unacceptably slow?  No.  The idea that they aren't seems bizarre to me,
> since they're often *faster than equivalent non-signatured code already.*
>
> Consider this program:
>
> use v5.34.0;
> use warnings;
>
> use experimental 'signatures';
>
> use Time::HiRes qw(time);
>
> sub sigs ($x) {                                           return $x * $x }
> sub bare      {                             my ($x) = @_; return $x * $x }
> sub full      { die "arity" unless @_ == 1; my ($x) = @_; return $x * $x }
>
> sub million {
>   my ($name, $code) = @_;
>   my $before = time;
>   for (1 .. 1e7) { $code->(1) };
>   my $after  = time;
>   printf "%s: %0.4fs\n", $name, $after - $before
> }
>
> million(sigs => \&sigs);
> million(bare => \&bare);
> million(full => \&full);
>
>
> This calls each subroutine 10,000,000 times (despite the name "million").
> One has a signature and a tiny body.  One copies the argument out of @_.
> One does that but also checks arity.  The more features of signatures you
> use, the more code you need to compare it to for a fair comparison.  But
> let's start with this statement:
>
> *"sigs" is doing more work and providing more value than "bare", and isn't
> merely more compact.*
>
> So what's the timing?  On my recent Intel MacBook, I routinely get results
> roughly like this:
>
> sigs: 0.8656s
> bare: 1.1357s
> full: 1.2632s
>
>
> The signatures are already faster.  Could they be *faster-er* by
> eliminating @_ setup (and adjusting to some resulting confusion over
> time)?  Yes, I have reason to believe that.  But in that scenario we're
> talking about accelerating our accelerator, not compensating for drag.
>
> --
> rjbs
>

Wow, that's amazing! I wasn't aware that sub sigs are faster and also by
that much!

Here are the times from my PC (Ryzen 3800X):
sigs: 0.7614s
bare: 0.8764s
full: 1.0507s

The multiplication affects the difference even more, when replaced with
just 'return $x' these are the results:
sigs: 0.6784s
bare: 0.8124s
full: 0.9844s

I've tried to convert your script to use Benchmark cmpthese but failed.
The docs don't say what COUNT should be but for this function, for timethis
it seems to be either really a count, the number of iterations the code is
executed, or negative to signal how long it should run.
With 1e7 and even 1e9 it still (indented and in brackets?!?!) outputs:
    (warning: too few iterations for a reliable count)
With -3 it just hangs at 100% cpu usage forever.

Thread Previous | Thread Next