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


Thread Previous | Thread Next
Jan Dubois
March 5, 2015 20:11
Message ID:
On Thu, Mar 5, 2015 at 10:57 AM, Paul "LeoNerd" Evans
<> wrote:
> On Thu, 5 Mar 2015 10:51:20 -0800
> Jan Dubois <> wrote:
>> Why would you give up a 20% speed improvement for some conceived
>> "purity" in the op code system? It is way too late to turn op codes
>> into a RISC-style design.
> I don't want a RISC-style design.
> However, nor do I want massively special-cased ops that as of right
> now, statistically-zero percent of CPAN can use, when instead we could
> have some ops that get peepholed inplace in EXISTING 5.18-and-earlier
> CPAN modules, making *everyone* faster; not just those brave few souls
> who start their code
>   use experimental 'signatures';

This is only temporary.  Once it becomes non-experimental, all code
will benefit.

> I honestly believe we can build something that makes even *THIS* code
> faster:
>   sub foo
>   {
>      my $x = shift or die "Forgot to pass x";
>      my $y = shift // 1;
>      my $z = shift // $x++;
>   }

That's nice, but I doubt that anyone will actually spend the time to
implement this in time for 5.22, so it won't be available today

> Do that and far more people will be happy, than doing something that
> statistically-nobody can use today.

*I* would be happy to see OP_SIGNATURE be used for "my(...) = @_" code
even without enabling experimental signatures. This would speed up
virtually all code on CPAN right away.

And given that there seems to be agreement that any alternative
implementation will be slower, I don't see why we need to worry too
much about committing to it. At least to me it is obvious that we
wouldn't want to replace it by more generic ops for a 20% slowdown.

I still don't get the either/or mentality. Why can't we listen to both
types of music? :)


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