http://www.perlmonks.org?node_id=987125


in reply to Perl 5 Optimizing Compiler

You are lucky, because I am free to work on this for cPanel for the next years :) At cPanel they compile perl for more than 10 years and most of their speedup is with optimizing the perl code, not so the compiler. The problem is that perl, the language, is too dynamic to be optimizable. Too much slowdown (magic, module imports, ...) and changes can happen at run-time. Also the language is not clear enough. The ops contain the needed optimizer info, not the data. So it's dealing with a lot of run-time and side-effects.

If you only need better startup time B::C is already stable and good enough. For optimized run-time more is needed.

I did some research and lobbying over the last years and came up with those approaches:

Did you see my inofficial (not yet announced) proposals on github? I'm working on const and a type system to enable future optimizations. Time-frame: 1-2 years.

perl design draft - types and const

https://github.com/rurban/perl/blob/42b0094646/pddtypes.pod

perl types pod

https://github.com/rurban/perl/blob/05514649c/pod/perltypes.pod

perldata.pod: add const and coretypes

https://github.com/rurban/perl/commit/7eb6c3584a1b

B::CC or another optimizing compiler can only profit from const and types.

After the YAPC we'll gather in Stavanger, Norway to discuss how to get the MOP proposals into perl.

http://act.yapc.eu/mtmh2012/

https://github.com/stevan/p5-mop/tree/master/extras/talks

Of course a MOP will slow down perl (other disagree), but as perl is currently hardly optimizable at all and more and more slowdown is getting introduced over the years, the MOP could be used to allow more compile-time optimizations and more efficient class, method and property handling.

Getting an optimizing compiler for YAPC::US sounds like a good plan to me, but is of course way too optimistic. B::CC already exists and passes most tests. Fixing the failures sounds like a good plan to me.

Function calls are also super-slow with perl. Getting faster functions calls by analyzing the code at compile-time and omit unnecessary exception handling, @_ handling, scope, and so on would also be a worthwile goal, up to inlining. Unfortunately it is not possible to discuss such thing on p5p. Not even the much simplier, possible XS call improvements.

The next idea will be Go-like concurrency in p5 with a changed runloop to saturate multiple native threads on multiple CPU's automatically. And some go-like language extensions for IPC communication. But I guess this vision is way too much for p5p. And even parrot is not there yet. In the current p5p process environment hardly anything could get done. It's management anti-patterns all over, as from the textbook.

Replies are listed 'Best First'.
Re^2: Perl 5 Optimizing Compiler
by dave_the_m (Monsignor) on Aug 13, 2012 at 14:22 UTC
    Function calls are also super-slow with perl. Getting faster functions calls by analyzing the code at compile-time and omit unnecessary exception handling, @_ handling, scope, and so on would also be a worthwile goal, up to inlining. Unfortunately it is not possible to discuss such thing on p5p.
    Why not?

    Dave.

[reply]
      Of course the topic can be discussed on p5p. I believe what Reini meant to write was, "I've cried wolf so many times that most of p5p no longer trusts my judgment."
[reply]
        Long p5p rant written and stored in ~/Documents/
[reply]
Re^2: Perl 5 Optimizing Compiler
by xiaoyafeng (Deacon) on Aug 13, 2012 at 17:17 UTC

    because I am free to work on this for cPanel for the next years

    Plz~, I can't wait 4 more months. ;)


    I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

[reply]

In Section Seekers of Perl Wisdom