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

Re: OP_SIGNATURE

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
March 5, 2015 17:21
Subject:
Re: OP_SIGNATURE
Message ID:
20150305172058.GA36763@plasmasturm.org
* Dave Mitchell <davem@iabyn.com> [2015-03-04 17:05]:
> On Wed, Mar 04, 2015 at 02:51:51PM +0000, Paul "LeoNerd" Evans wrote:
> > E.g. a random thought: I notice that the OP_SIGNATURE has a generic
> > way to say the default value of an arg is some IV stored in the
> > optree, and also two specific cases for the (presumably common)
> > cases of zero and one, possibly to cut down on the extra pointer
> > reference overhead in fetching the IV. All well and good.
> >
> > But maybe instead we want an OP_ZERO operator, that sets its TARG to
> > be a zero IV? That could be used in its place in whatever new optree
> > shape we make the signature-parsing code; but *also* the peephole
> > optimiser can now use that where-ever it finds an
> > OP_SASSIGN(OP_CONST zero) combination. Now any occurance of
> >
> >   $foo = 0
> >
> > becomes more optimised, not just those ones appearing in signatures.
> >
> > This is one example of the kind of thing I'm thinking here - this
> > OP_SIGNATURE has far too much special-casing of things like this,
> > that could help in other places that currently it can't reach.
>
> Three things.
>
> First, OP_ZERO would actually be slower for the generic case. OP_CONST
> currently just pushes a const SV (that has the value 0) onto the
> stack, either the SV in o->op_sv (non-threaded), or in
> PL_curpad[o->op_targ] (threaded builds).  For OP_ZERO, it would
> actually have to retrieve the current targ SV PL_curpad[o->op_targ],
> modify it to be zero, then push it. That extra modify step makes it
> slower than OP_CONST.
>
> Second, even supposing OP_ZERO was (generically) a gain, it would
> still be unlikely to compete with OP_SIGNATURE. OP_ZERO is pushing an
> SV onto the stack, then returning o->op_next to the control loop,
> which calls the next pp_ function, which pulls that SV back off the
> stack, then tries to extract out the integer value from it (if any).
> OP_SIGNATURE executes what probably compiles to 2 CPU instructions:
> i=0; goto set_iv. There is an order of magnitude difference.

IIUC (both you and Paul) then you missed Paul’s point. AIUI, he meant
OP_ZERO as a special-purpose form of OP_SASSIGN, not a special-cased
form of OP_CONST.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

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