Front page | perl.perl5.porters |
Postings from March 2015
From: Aristotle Pagaltzis
March 5, 2015 17:21
Message ID: 20150305172058.GA36763@plasmasturm.org
* Dave Mitchell <email@example.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.
Aristotle Pagaltzis // <http://plasmasturm.org/>