|
|
|
| P is for Practical | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
Greetings Monks,
After ongoing and extensive discussion with Nick Clark, y'all, and many others, a vague project outline is emerging. Its edges are a bit hazy and not clearly defined against the background of existing Perl development, but the lack of clarity will be resolved as we move forward with more focused research and planning. As pointed out independently by Nick Clark and BrowserUK, I think it is helpful and logical to see our job as 3 phases: parse code written in Perl 5 to produce optrees or equivalent, convert optrees to some new intermediate form, and efficiently execute the new intermediate form. I am currently seeing 2 simultaneous development paths: one project focused on rewriting existing Perl internals to produce backend code for LLVM or the equivalent (basically PONIE redux); and another project focused on working outside the existing Perl internals. I will refer to these as the "guts" and "non-guts" approaches, respectively. I believe these 2 parallel projects are primarily defined by their adherence (or not) to the "Perl defines Perl" maxim for phase 1 of the 3-phase approach: the Perl 5 parser. If we use the existing Perl 5 parser, then we are keeping to "Perl defines Perl" and thus our development is focused on rewriting Perl to run on a new internal engine. If we are using a new Perl 5 (subset) parser, like Flavio's Perlito or Ingy's C'Dent/Perl5i, then we are basically free of the existing Perl 5 internals and can translate the parsed application code into another high-level language or LLVM or whatever. "The #1 rule of gov't spending: why build one when you can build two at twice the price?" (Hadden, Contact)I'm not necessarily trying to build 2 separate compilers, I'm just hedging my bets because we aren't yet sure if either approach will actually work. The Guts Project Considering the extensive LLVM-related discussion of my previous thread, it seems fairly obvious that LLVM should probably be the first new backend we target for the guts approach. In fact, a few people have already tentatively committed to working on a Perl5-on-LLVM project, so although this is not set in stone, it is certainly set in mud at least. If LLVM doesn't work out, other potentially viable backends may be the Java VM, Mono/CLR *shudder*, or maybe even ye olde Parrot. But I think LLVM is definitely the best place to start. The Non-Guts Project The two best options I see for the non-guts approach are Ingy's C'Dent/Perl5i and Flavio Glock's Perlito. Since Flavio seems to be busy at Booking.com and Ingy is actively working with me, then it will likely be Ingy FTW. I just booked a flight for Ingy to come to Austin on September 18-19, and I will probably set up a video chatroom for anyone who wants to join in our discussions. Likely backend code generation for the non-guts approach may be LLVM, Javascript, RPython, or even good ol' XS. This has yet to be determined. Synthesis I find it likely one or both of the initial approaches may not achieve 100% of the stated goal of making Perl perform within an order of magnitude of optimized C. However, I also find it quite likely that one of them may well succeed, and at the very least show us what we are doing wrong and point us in the right direction for further development. If LLVM doesn't work out for the guts approach, we try a different backend; the same principle applies for the non-guts approach. In the end, we may find our two approaches merged back together again somehow, and hopefully integrated into the official Perl distribution for everyone's benefit. Help Wanted Besides working out detailed development plans, our biggest issue at this point is personnel: who is qualified and available to work on this? If you may fit the bill, I've got some basic questions for you... 1. What is your personal interest in a Perl 5 optimizing compiler? 2. What part of the project do you feel qualified to work on? 3. What XS code have you written? 4. What is your level of familiarity with Perl internals? 5. Are you more interested in being sponsored to work hard on this project, or just volunteering some of your spare time? 6. Are you in a position to provide some initial pro bono coding effort? Many thanks to everyone who has contributed to the discussion and efforts thus far. Exciting times! Thanks, ~ Will
|
|