Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Perl 5 Optimizing Compiler, Part 3: I Have A Dream

by Will_the_Chill (Pilgrim)
on Aug 23, 2012 at 08:35 UTC ( #989235=perlmeditation: print w/ replies, xml ) Need Help??

I have a dream. I have a dream where any programming language, no matter how dynamic (or not), can execute near the speed of optimized C. This is a lovely dream. This dream may never happen.

BUT! I have another, more specific dream. I have a dream where Perl 5 (not a subset of Perl 5, not Perl 6, not Perl 7) can execute at nearly the speed of optimized C. With the help of Nick Clark, Ingy, Reini, Austin Perl Mongers, and others, I am chasing down this dream.

If you look at Nick Clark's recent comments pasted below, you will see his (at least) 3 steps to achieve my dream. At this point, I'm considering Reini's B system or to-be-completed Perl5 parsers from Ingy's C'Dent/Perl5i or Flavio Glock's Perlito as candidates for part 1; the translation mechanisms of C'Dent/Perl5i or Perlito for part 2; and RPython, optimized XS, or Javascript for part 3.

My task now is to run some initial benchmarks on these software systems (and maybe a few others) to get an idea of which direction we may go from here. Of course, I will post back here on Perl Monks once I've got some timing statistics to share.

Thanks for the continued interest, all the comments (both pro and con) are most welcome and appreciated, especially those from chromatic! ;-)

Perling,
~ Will


On August 18th, Nick Clark wrote:

Well, what I was really meaning was that there are actually (at least) three steps to running Perl 5 on a different platform

1) parsing Perl 5 source code
2) outputting code for it to the platform
3) a runtime library for Perl 5 for that platform

If Perlito's documentation is right, and it has most of a Python 2.6 backend, then Perlito already has

1) the start of a Perl 5 parser
2) the start of code to output Python
3) a runtime library for what it supports (preferably written in Perl 5 itself)

which means that some work is already done. And that anything further that needs doing on (1) and (3) is shared work between various people and projects.

Ingy's B system (sic) might have the same benefits - anything you can share with anyone else working on similar problems is work you don't have to do yourself.

Comment on Perl 5 Optimizing Compiler, Part 3: I Have A Dream
Re: Perl 5 Optimizing Compiler, Part 3: I Have A Dream
by zentara (Archbishop) on Aug 23, 2012 at 10:21 UTC
    all the comments (both pro and con) are most welcome

    It sounds like you are chasing an elusive dream, but I wish you luck. :-)


    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh
Re: Perl 5 Optimizing Compiler, Part 3: I Have A Dream
by sedusedan (Monk) on Aug 23, 2012 at 10:39 UTC
    There is another approach to reach your dream: slowing down C :)

      Maybe we can have GCC output some random NOPs into the assembly?


      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

      If you can slow down C enough, we won't have to worry about Nukes anymore either! :)
Re: Perl 5 Optimizing Compiler, Part 3: I Have A Dream
by hardburn (Abbot) on Aug 23, 2012 at 14:47 UTC

    My Impossible Plan to implement this Impossible Dream would be to take a subset of Perl5 that can be parsed statically and implement that. Basically what PHP should have been if it was run by people who knew what they were doing.

    From there, you can integrate the new implementation into the CPAN testing system. Try to get the major module authors to commit to passing their releases under the new system.


    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

      We can't ever have a requirement of other people needing to re-write their existing Perl 5 code to run with our stuff, it would be political death within the coding community. We need to be 100% backwards-sideways-forwards compatible with all Perl 5 code.

      Exactly how to achieve that is what remains to be determined.
        Banning eval's visibility of lexicals is the number 1 way to optimize perl to C speed. You have to compile out the "english". Also banning magic would allow common subexpression elimination and convert SVs into more C like data/machine words. Reducing usage of the perl stack might be a worth idea to pursue. Considered taking a profiler to all the perl opcodes and see which are the slowest? I've modified NYTProf for myself to time per opcode times (part of NYTProf's CORE:: profiling system). There is a list in some header of NYTProf which says which opcodes to profile.

        A random idea I thought of today is, stop pp_sassign for target aware opcodes. sv_setsv does bail out almost instantly if source and dest SV*s are the same, but pp_sassign goes through alot of code until it calls sv_setsv.

        Sadly, your best bet is to write a Perl 5 to .NET CIL or Java bytecode compiler since pretty much all CPUs nowadays are tuned to running one of those 2 VMs.
Re: Perl 5 Optimizing Compiler, Part 3: I Have A Dream
by flexvault (Parson) on Aug 23, 2012 at 16:19 UTC

    Will_the_Chill,

      If Perlito's documentation is right, and it has most of a Python 2.6 backend, then Perlito already has

      1) the start of a Perl 5 parser
      2) the start of code to output Python
      3) a runtime library for what it supports (preferably written in Perl 5 itself)

    Just for clarification ( don't have a clue what Python is? ), if 1) and 2) are true above, why do you need 3)?

    If I read this correctly, after 2) you have a Perl5 script coverted to a Python 2.6 script, so does Python 2.6 have a backend compiler?

    I just don't get it yet...

    Interesting!

    UPDATE: Do you/we want to go this route?

      32. Python compiler package

      Deprecated since version 2.6: The compiler package has been removed in Python 3.

      The Python compiler package is a tool for analyzing Python source code and generating Python bytecode. The compiler contains libraries to generate an abstract syntax tree from Python source code and to generate Python bytecode from the tree. . . .

    "Well done is better than well said." - Benjamin Franklin

        Will_the_Chill,

        I read the article and it has some very interesting concepts and information. I think the use of 'RPython' name is unfortunate but I can understand why.

        Regards...Ed

        "Well done is better than well said." - Benjamin Franklin

Re: Perl 5 Optimizing Compiler, Part 3: I Have A Dream
by TGI (Vicar) on Aug 30, 2012 at 07:34 UTC

    You might want to check out perl on llvm.

    Check out this old post to p5p about running Perl on LLVM. It's pretty darn interesting.

    EDIT: -- I just found your extensive discussion of LLVM. Obviously, you know about it already. nothing to see here. Move along.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://989235]
Approved by Ratazong
Front-paged by Tanktalus
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (10)
As of 2014-10-01 17:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (31 votes), past polls