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


Thread Previous | Thread Next
Kent Fredric
March 6, 2015 19:06
Message ID:
On 7 March 2015 at 05:08, demerphq <> wrote:

> >> I'm slightly surprised that you're not excited by the obvious
> >> possibility here: you can implement the signature op as a CPAN
> >> module.  It would involve writing the peep-time recognition code,
> >> which I know you won't enjoy, but look at the upside: full
> >> signature-op optimisation on 5.20! Think of the performance you can
> >> deliver straight to production by not tying it to the core.  By
> >> virtue of the peeper knowing definitively where the subroutine
> >> starts, you'd even get to make the all-pad-scalars-clear assumption
> >> without risk of nasty interactions.
> >
> > +1
> >
> > I would much rather see this as a CPAN module that can apply to 5.20
> > (or even earlier by pattern-matching of common optree shapes such as
> > the  my (...) = @_  idiom)
> So go ahead and implement it. While you are doing so the rest of us
> would much rather see this merged to core so we can use it now.

Indeed. I'm excited by the ability to make old perls run faster.

What I'm not excited by is people complaining that an optimisation that can
ship and make the next perl release faster is somehow going to be better by
making everyone use a dependency.

Core optimisations are things everyone wants the benefits of, and people
shouldn't have to install 3rd party CPAN modules to get them.

I don't fathom why this op is "bad", when your suggested complexed ops with
more flexibility can cohabit with it just nicely, and maybe down the line,
the many complex ops can be coalesced to OP_SIGNATURE for performance when
they are arranged correctly.

It sounds like people are complaining an icecream shop has chocolate
icecream when they prefer vanilla, but I don't see why the shop can't sell



Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About