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


Thread Previous | Thread Next
March 6, 2015 14:16
Message ID:
Dave Mitchell wrote:
>Thanks, you saved me the effort of having to write some demo code to
>prove my point.
>This isn't to conclude that Devel::GoFaster-style optimisations aren't
>worthwhile elsewhere, but it *is* to conclude that they're not a "good
>enough" substitute for OP_SIGNATURE.

Bullshit.  D:GF is in no way claiming to represent the maximum that can
be achieved by any particular class of optimisation: it's a first step.
It is ridiculous to deride it for not delivering as much optimisation
as the signature op.

Nor is D:GF particularly in opposition to the signature op.  In the
respect that it merges multiple ops into single ops that do a larger
job (and avoid some stack use), it is very much in the same vein as
the signature op, the latter obviously being a more advanced example of
such merging than what D:GF currently does.  Both the signature op and
D:GF have the downside of causing problems for code walkers that examine
peepholed ops.

There are two really significant differences between D:GF and the
signature op.  The first is that D:GF operates in the peephole optimiser.
This means it doesn't complicate the optrees seen during primary
compilation.  So while it screws up the deparser, it plays nicely with
modules that mutate semantics through op checkers.  (Not Data::Alias,
unfortunately, because that unwisely also does its munging at peep time.)
In this respect it resembles your multideref op.

In the question of whether op types are part of the API, I think there's
room to decide that pre-peep op types generally are and post-peep op
types generally are not.  That would allow fairly free introduction and
changing of signature-like mega-op optimisations while still supporting
a CPAN ecosystem of semantic innovation.

The second significant difference is that D:GF is a plugin from CPAN.
It doesn't need to be in the core to work, though some later optimisations
are liable to get more difficult to deliver in this form.  D:GF delivers
optimisations to existing Perl versions (back to 5.8), and the brave can
easily put it into production straight away.  It can serve as a testbed
for peephole optimisations that it is proposed to add to the core.
This is the power of the CPAN ecosystem based on hooks provided by
the core.  (If we finesse that pre/post-peep split, we can enable a
genre of peep-time optimisation modules, with the core still having
great freedom to optimise.)

I'm slightly surprised that you're not excited by the obvious possibility
here: you can implement the signature op as a CPAN module.  It would
involve writing the peep-time recognition code, which I know you won't
enjoy, but look at the upside: full signature-op optimisation on 5.20!
Think of the performance you can deliver straight to production by not
tying it to the core.  By virtue of the peeper knowing definitively where
the subroutine starts, you'd even get to make the all-pad-scalars-clear
assumption without risk of nasty interactions.

So to back up my opening comment about bogus comparison: the class of
optimisation represented by D:GF *includes* the signature op.  So no,
this class is not inherently inferior to the signature op.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About