|Syntactic Confectionery Delight|
Perl 5 Optimizing Compiler, Part 2by Will_the_Chill (Pilgrim)
|on Aug 17, 2012 at 22:24 UTC||Need Help??|
Will_the_Chill has asked for the
wisdom of the Perl Monks concerning the following question:
Okay Monks, I've done a few days of recon. Now I'm talking to Nick Clark and Ingy and Reini and others. Below is my latest e-mail to Nick about the whole thing, with some links interspersed for your convenience.
Now, on the count of 3, everybody tell me EXACTLY HOW I'M WRONG!
1 ... 2 ... 3!
<<< BEGIN E-MAIL >>>
I'm probably misunderstanding some technical aspect of the whole RPython vs Perlito vs everything, here's my take, please correct me:
RPython is a subset of the Python programming language, written in Python (I guess). RPython was created to create the PyPy Python JIT, which now runs faster than the original CPython interpreter VM. Any program written in RPython has the benefit of receiving an automatically-generated optimizing & tracing JIT compiler for free. Comparisons of the Converge language's VM written in C vs RPython show orders of magnitude speed increase by RPython's generated JIT. We would use the RPython language to implement a VM supporting (at least) a subset of Perl 5, which would give us the free Perl-specific JIT as a result, and again make a subset (or all) of Perl 5 run very fast.
I think Marc Lehmann's Faster module on CPAN is similar to Ingy's goal of compiling some portion of your Perl 5 into XS. Faster may or may not be using Ingy's old Inline::C modules, which can also be used for some incremental runtime performance increase.
Reini's work with the B compiler system seems to have made him enemies in the Pumpking and P5P camps, too bad. From what Reini tells me, he is mostly focused on making some fundamental changes to the Perl 5 language (unlikely to be adopted), and boosting startup speed by compiling to Perl Bytecode, etc. Reini is the only one working with ALL of Perl 5, not just a subset of Perl 5. I'm afraid that just-a-subset-of-Perl5 is a bad general route to take, because then you'll always be trying to catch up with the "real" Perl 5. So my thoughts are to try and have the full Perl B compiler system as the frontend so we are never just-a-subset, then we just need to decide which backend(s) to use to run the not-just-a-subset Perl 5 code in its native B form.
I think to somehow combine Perlito/Perl5i and RPython would amount to manually translating the Perlito/Perl5i subset-of-Perl parser from Perl (or whatever) to RPython; or manually translating RPython's JIT-creating system from Python to Perl. Both of these would work I think?
I think to somehow combine Reini's not-a-subset-of-Perl5 frontend with one or more of the Perlito/RPython/Perl5i backends would amount to some new Perl 5 code gluing them all together in the grand old Perl tradition of TMTOWTDI. We can run some performance tests on Perlito and Perl5i to see if we also need RPython. If we need RPython's awesome magical JIT (which I suspect we may), then we will have 3 new backends, and don't forget we still have the "real" Perl 5 interpreter VM to fall back on when we have code that isn't within any of the backends' subsets-of-Perl. So we create some Perl glue to make Reini's B system decide which of the 3 or 4 backends to run for each code segment based on some hard-coded rules derived from our performance tests on each backend's subset-of-Perl. The only thing the Perl users would know is that now when they run the /usr/bin/perl executable, it runs almost as fast as C.
Please do keep telling me exactly how wrong I am, you are clearly the most receptive and knowledgeable person I've got at this point. :)
<<< END E-MAIL >>>