An Accurate Comparison of Perl 5 and Rakudo Star

Rakudo Star is a useful and usable subset of Perl 6 you can use right now. It does not implement the complete Perl 6.0 specification, and it's by no means the final release: it contains bugs and misfeatures, and it's had very little optimization work for speed or memory.

Subsequent releases will bring improvements on completeness, correctness, and competitiveness.

Even so, how unfortunate to see a thoroughly misleading comparison of Rakudo Star to Perl 5.

Rakudo's perl6 binary is a couple of hundreds of lines of C code (if that much) linking to libparrot and mostly unoptimized Parrot bytecode. By unoptimized, I mean "There is no optimization of Parrot bytecode in Rakudo Star." — not constant folding, not size optimization, not inlining. None.

The perl5 binary is of course all compiled C code generated (hopefully) by an optimized compiler. Does that make for a valid comparison? I think not.

Of course, the worst flaw by far is in comparing the feature set of the Perl 5 binary to that of Rakudo Star. Perl 5 contains no advanced object system, no runtime manipulation of the parse tree, no grammars, no continuations or coroutines, no junctions, and no interoperability with other languages. Oh, and it does not contain hyperoperators, function and method signatures, multidispatch, laziness, or built-in language redefinition, no strictness by default, no autothreading, no REPL, and no automatic binding to shared libraries.

It's easier to add the loading of the appropriate CPAN modules to the Perl 5 process than to remove them from Rakudo Star, so for an accurate comparison, you must add:

I ordered the list in terms of dependencies to show cumulative costs. I also left out a few CPAN distributions you need to add to Perl 5 to add features enabled by default in Perl 6: for example, I couldn't get Data::Alias to build.

My perl5 binary is Perl 5.12.1, built fresh today as a 32-bit binary without threading. (A 64-bit binary uses more memory and a binary with threading is some 10-15% slower, reportedly.) It's 1,239,686 bytes in size.

My perl6 binary (built from today's checkout, not Rakudo Star) is 14,280,276 bytes in size. At the REPL, it uses 99,944 KB of virtual memory and 81,132 KB of resident memory. To run the program -e 1, it requires 1.035s. By my calculations, Rakudo Star starts up 1.5% more slowly than Perl 5 with all of the other modules loaded and uses 2.45 times as much virtual memory and 4.39 as much resident memory.

By way of comparison, Perl 5 running -Mperl5i::2 -E 1 runs in 0.149s. It requires 12,080 KB of virtual memory and 6,952 KB of resident memory. Rakudo Star starts 6.72 times slower than Perl 5 with perl5i. Rakudo Star uses 8.27 times more virtual memory and 11.67 times more resident memory.

I believe it's very possible to improve Rakudo's startup time by an order of magnitude, such that it starts faster than Perl 5 with perl5i, much faster than Perl 5 with all of the feature parity modules loaded, and modestly slower than Perl 5 without feature parity. I also believe that it's possible to improve Rakudo's memory requirements—perhaps not an order of magnitude, but at least by cutting them in half and then perhaps in half again.

Better yet, new features planned for Parrot offer the opportunity to deploy applications with only those features actually used, so if you avoid the object system or grammar manipulation altogether, you won't pay the memory or startup costs for them. That's a plan for sometime in the future, however.

Rakudo Star has a long way to go. We'll improve its performance and cut its memory requirements. There are many places we know need improvement, and we're working on them. That's why we keep releasing new versions.

... but don't fool yourself: comparing bare Perl 5 to Rakudo Star without understanding the context of the comparison does no one any good.