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

Re: OP_SIGNATURE

Thread Previous | Thread Next
From:
Paul "LeoNerd" Evans
Date:
March 7, 2015 12:30
Subject:
Re: OP_SIGNATURE
Message ID:
20150307122950.0f5f1c4a@shy.leonerd.org.uk
+1 to all of that.

In addition I have another thought. My worry is that OP_SIGNATURE is
setting a precedent of large-scale refactorings of optrees being
coalessed by pattern-recognition into fewer, larger ops. That in itself
is no bad thing at all; is similar to what Zefram's Devel::GoFaster
does, and is something I'd verymuch like to see developed as CPAN
modules. Indeed I'm sure that asides OP_SIGNATURE, there could exist
dozens, if not hundreds, of interesting optree shapes that specific
programs or use-cases encounter all the time, that could be nicely
optimised out.

By being a CPAN module, each individual program can opt in or not to
receiving the optimisations those optree refactorings provide, along
with taking the risk of those API incompatibilities already mentioned.
It removes the danger that any arbitrary optree-munging module could
suddenly encounter an OP_SIGNATURE op of a form it didn't understand,
because at some level the program (or one of its modules) has to have
opted in to that "experiment", to reuse Zefram's wording.

I'd like to move on for a moment from specific whining about
OP_SIGNATURE to something a little more constructive, and that is
summarised by the question

  Can this entire OP_SIGNATURE feature be developed as a CPAN module?

Namely, would it be possible for every ounce of optimisation provided
by it to be applied to any program that simply started

  perl -MDevel::Op::Signature ...

If it can, then I vote that nobody would (or in fact could) stop DaveM
from re-implementing it in that manner, and gaining every bit of
runtime optimisation that he has repeatedly stated he wants,
automatically on any 5.22 or even 5.20 program that wanted to opt-in
simply by loading that module somewhere within it.

If it cannot, then I vote that is a shortcoming of the way perl
compiles and interprets the optrees, meaning that extension modules
cannot mutate them in such a generic way that the core can.

If this ability were to be available, we'd hopefully see more CPAN
modules coming about that provide other optree reshaping for
performance. For example; my oft-lately-mentioned idea of turning the
combination of OP_SASSIGN from an OP_CONST to an OP_PADSV, into a
single OP_PADASSIGNIV/PV op is something I would *far* more likely
implement as a CPAN module than as core code; there'd be nothing about
that optimisation that couldn't apply as far back as 5.14; if suitable
core API hooks were found to exist that could support it.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS

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