Front page | perl.perl5.porters |
Postings from February 2017
Re: more process_optree
Thread Previous
|
Thread Next
From:
Jim Cromie
Date:
February 15, 2017 18:18
Subject:
Re: more process_optree
Message ID:
CAJfuBxwUPGCGDQehOKmdOkhm+jXiqxFm+1V5NqNOzJVFzHbGsw@mail.gmail.com
On Wed, Feb 15, 2017 at 9:58 AM, Dave Mitchell <davem@iabyn.com> wrote:
> On Wed, Feb 15, 2017 at 09:19:30AM -0700, Jim Cromie wrote:
>> OK. Begging your forbearance, heres what Im trying to do:
>>
>> usage of op-sibling and op-ppaddr are almost mutually exclusive,
>> and they can be unionized.
>> opsibling is set early, and used heavily in optimization,
>> but rarely afterwards.
>> ppaddr is set early too, but can be deferred until after optimization,
>
> But some CPAN modules hook into the peephole optimiser or possibly earlier
> to set the op_ppaddr address to a non-standard value. So I don't think
> that scheme would work.
>
yes, I encountered that with arybase.
I handled it by setting a new op_finalized bit,
and checking it in finalize_ppaddr() before overwriting it.
This is probably not enough to handle such customizations generally,
but maybe something will become apparent...
There are lots of CPAN modules (~95) with bare field refs of both
o->op_ppaddr and o->op_sibling. ISTM the latter group might fall over
with PERL_OP_PARENT, but that should have happened already if it were
going to. OpSIBLING and friends macros perhaps provide enough
abstraction, if theyre in ppport.h, but those modules would have to
use them.
(maybe grep.cpan.me was showing me older modules?)
>> At finalization, opsibling can be saved to an HV,
>> so its available at runtime for the occasional need.
>
> But that would use far more storage than having a separate op_sibling
> field. The HV for every CV would also have to be duplicated for each new
> thread created (whereas optrees are shared).
yes, its bigger, but its out-of-band, and the resulting optree is ~20% smaller,
reducing OP fetching costs. whether that is offset by opsibling fetch costs
is tbd, and I daresay hard to measure. Cache pressure is more of a thing
in webservers than in microbenchmarks.
Speaking heretically, it might be possible to drop the entire HV if -w
isnt on the cmdline and no modules which need it are used. Perhaps use
less "siblings",
and/or less::drop_siblings() might make this practical case by case,
and without too much cleverness.
its also be possible that many op-sibling values are knowable
by other means (ie same as op-next, as marked by a flag) and dont need
to be stored, or perhaps not needed to support uninitialized-var reporting.
FWIW, Ive used 1 global HV to perlvars (as PL_siblings).
this extra (dVARS) indirection will further increase fetch costs of OpSIBLING(),
but only after the op has been finalized.
A per-CV approach (or perhaps per-stash) would be faster, and would
allow more flexibility; I could imagine that many CPAN modules are
mature enough
that all package and local vars are known to never be uninitialized,
such that the %siblings can be deleted for that package.
>
>> Ive got the above mostly fleshed out,
>> but the sticking point so far has been the subtrees
>> produced by fold-constants and gen-const-list;
>> theyre not getting visited by finalize_op,
>> (despite being attached to the larger tree?)
>
> I just tried single-stepping through Perl_finalize_optree for
> perl -e'exit 1+2'
> which has the following constant-folded optree:
>
> 5 <@> leave[1 ref] vKP/REFC ->(end)
> 1 <0> enter ->2
> 2 <;> nextstate(main 1 -e:1) v:{ ->3
> 4 <1> exit vK/1 ->5
> 3 <$> const[IV 3] s/FOLD ->4
>
> and S_finalize_op() was called with that const[IV 3] op as its arg.
> So I'm not sure why it isn't for you.
thats where I'll look next. thx for the focus.
>
>> If this is all crazytalk, I'll delete the branch and shut up.
>
> It would seem to be heading in that direction I'm afraid.
>
> --
> A problem shared is a problem doubled.
that one feels hand-picked, or was it just coincidence ?
Thread Previous
|
Thread Next