Version 1.7 of the Perl 5 to C/C++ optimizing compiler, codenamed Tycho was released earlier this month. The issue RPerl tries to address is Perl's slow performance, sufficient for most cases, but prohibitive for the real time domain.

Perl trades speed for flexibility as it takes care of many things so the programmer won't have to, such as tying hashes (a term that refers to an intricate internal functionality) reference counting, automatic type conversions, closures, autoloading and much more.

Another issue that does not allow Perl to speed up is its inherent compiling process is that it does not emit bytecode but something called an Op-tree instead. That Op-tree is similar to an AST but not quite, with each Op-tree node overburdened with a complicated set of instructions

Emitting bytcode instead would enable the interpretation of Perl code by a modern VM like RPython or LLVM, something that would lead to significant performance improvements

That is a daunting task, however, as it would require a complete, or at least heavy, rewrite of Perl's internals, something too complex and too time consuming to undertake.

This is the way Perl 6 took, however, choosing to start with a clean  code base and break backwards compatibility by emitting bytecode for MoarVM or JVM. It is "Perl 5 done right" according to Larry Wall, suggesting that Perl 6 is an attempt to correct all mistakes in Perl 5's design

The alternative is to work with a trimmed down version or subset of Perl, that can be actually compiled to C or even translated into bytecode.

That's what's already happening with the Perlito compiler, which translates Perl to Javascript for the V8 backend, or Perl to Python for the RPthyon backend.

There were inherent attempts to convert Perl's op-tree to bytecode format, namely with the B::Bytecode modules, but that bytecode was never intended for use in a VM but just for freezing the op-tree to disk so that it could be later loaded and interpreted again, thus giving Perl a certain amount of platform independence.

The closest to native code translation ever reached was the perlcc, the perl-to-c-compiler, but it was plagued with serious reliability problems and was finally deprecated in Perl version 5.10. 

The purpose of RPerl is similar to that of perlcc - compiling Perl to C code, but for the subset that can be statically compiled, hence the R for Restricted Perl. 

This way the rewrite of Perl's internals is avoided, and instead a compromise is striken between removing the high magic parts that cannot be statically compiled,thus trading flexibility for performance and to deal only with the low magic parts that can be statically compiled

"high magic" refers to the  most complex and flexible parts of Perl , while "low magic" are the parts of Perl which can be made to run fast

Leaving high magic out means that Perl code writen for  RPerl cannot use the language's rich features such as auto-vivification, tied variables, typeglobs, code references, weak references, magic lvalues etc.The can and can't do are documented in "The Low-Magic Perl Commandments".

 Add to this complexity Perl's habit of invoking the runtime during its compilation phase,hence running code whose results are subsequently used in further compilation,and vice versa, and you can see where the 'only Perl can parse Perl' quote is coming from

Although leaving high magic out removes functionality off the language, the notion is that the domain specific applications (scientific,maths,games) that need RPerl's  performance boost do not make use of those features anyway

The benchmarks display impressive gains in performance. In a case,timing an implementation of the Bubble Sort algortihm took Perl 15 secs to complete, compared to just 0.04 secs with RPerl!

 (click to enlarge)

Performance boost aside, these improvements could also boost Perl's popularity amongst businesses, who might currently be reluctant to adopt it due to its speed limits

The future holds thoughts to somehow combine the parts that can be statically compiled, with a JIT for the  dynamic parts that can be interpreted, as well as increasing the coverage of high magic parts

Will Braswell, RPerl's lead, is also involved in the closely related project P11,which embraces the idea of Perl 5's and Perl 6's re-unification,

For a recent presentation on the matter, see the April 11 Google hangouts video presentation on RPerl and Perl11.

In the latest edition of FLOSS Weekly, Randal Schwartz and Aaron Newcomb present an hour-long video interview with Will Braswell about RPerl.  

More Information

RPerl official site

Learning RPerl

RPerl on Kickstarter

RPerl on GitHub

Related Articles

Perlito - An Interview With Flávio Glock

Perl 6 First Official Release

With the Rise of DevOps, Perl Shows Its Muscle

To be informed about new articles on I Programmer, sign up for our weekly newsletter,subscribe to the RSS feed and follow us on, Twitter, Facebook, Google+ or Linkedin. 

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info