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

Re: OP_SIGNATURE

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
March 4, 2015 16:01
Subject:
Re: OP_SIGNATURE
Message ID:
20150304160038.GY28599@iabyn.com
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.

Which leads to the observation of "why not both"? It's perfectly possible
that people can think of new generic ops that will make generic perl code
go faster, and so should be added to core, *while* OP_SIGNATURE is still
much faster than using a combination of those new ops, and so should also
be added to the core.

-- 
Standards (n). Battle insignia or tribal totems.

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