develooper Front page | perl.perl5.porters | Postings from March 2015

Re: OP_SIGNATURE

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
March 6, 2015 13:14
Subject:
Re: OP_SIGNATURE
Message ID:
20150306131422.GF28599@iabyn.com
On Fri, Mar 06, 2015 at 06:15:40AM +0000, Zefram wrote:
> Jan Dubois wrote:
> >On Thu, Mar 5, 2015 at 10:57 AM, Paul "LeoNerd" Evans
> ><leonerd@leonerd.org.uk> wrote:
> >> I honestly believe we can build something that makes even *THIS* code
> >> faster:
> >>
> >>   sub foo
> >>   {
> >>      my $x = shift or die "Forgot to pass x";
> >>      my $y = shift // 1;
> >>      my $z = shift // $x++;
> >>   }
> >
> >That's nice, but I doubt that anyone will actually spend the time to
> >implement this in time for 5.22, so it won't be available today
> >either.
> 
> How's Devel::GoFaster for a start?
> 
> https://metacpan.org/release/ZEFRAM/Devel-GoFaster-0.000
> 
> It doesn't do anything with the $z line, but reduces that sub from 22
> runnable ops to 16.

Thanks, you saved me the effort of having to write some demo code to
prove my point.

Consider these three cases:

A: perl-5.21.9 running:

    sub f
    {
       # the "or die" elided, since Devel::GoFaster doesn't handle it
       my $x = shift;
       my $y = shift // 1;
       my $z = shift // $x++;
       1;
    }

B: as A, but with this added:

    use Devel::GoFaster "global";

C: my OP_SIG branch running:

    use feature 'signatures';
    no warnings 'experimental';
    sub f($x, $y=1, $z=$x++) { 1; }


Using Porting/bench.pl and displaying raw number of instruction reads etc
per call to f() (cache misses elided because they were all zero, which isn't
surprising for a trivial benchmark like this):

running f(1):

                   A        B        C
            -------- -------- --------
        Ir    1842.0   1644.0   1302.0
        Dr     635.0    569.0    428.0
        Dw     315.0    269.0    207.0
      COND     253.0    226.0    189.0
       IND      39.0     38.0     29.0
                                       
    COND_m       3.0      5.1      0.8
     IND_m      28.0     22.0     22.0


running f(1,2):

                  A        B        C
           -------- -------- --------
        Ir   1878.0   1719.0   1342.0
        Dr    646.0    598.0    441.0
        Dw    317.0    280.0    212.0
      COND    264.0    236.0    196.0
       IND     39.0     40.0     29.0
                                     
    COND_m      3.0      3.1      0.8
     IND_m     27.0     22.0     22.0
          
running f(1,2,3):

                  A       B        C
           ---------------- --------
        Ir   1768.0  1609.0   1066.0
        Dr    608.0   560.0    340.0
        Dw    299.0   262.0    163.0
      COND    251.0   223.0    155.0
       IND     36.0    37.0     21.0
                            
    COND_m      1.0     3.1      0.9
     IND_m     25.0    20.0     17.0
                        
Note that the f(1) and f(1,2) cases are both intended to put OP_SIGNATURE
in a bad light since the $x++ can't be handled internally by the op;
which is is why I included it in the original example.

Even for those, those data/instruction read/write figures are in the
region of 25-35% faster than the 'discrete' optimisations, For the
f(1,2,3), which can be handled completely internally by OP_SIGNATURE,
they're in the region of 50-65% faster than the discrete Devel::GoFaster
optimisations.

This isn't to conclude that Devel::GoFaster-style optimisations aren't
worthwhile elsewhere, but it *is* to conclude that they're not a "good
enough" substitute for OP_SIGNATURE.




-- 
Red sky at night - gerroff my land!
Red sky at morning - gerroff my land!
    -- old farmers' sayings #14

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About