this article was been updated since its original posting
Rakudo Star was supposed to be a useful and usable subset of Perl 6. It was promised as something "you can use right now". Years after its release, it still does not implement the complete Perl 6.0 specification. It's still by no means the final release. It's still buggy, memory hungry, and slow. While its developers will tell you it's improving, years of work still haven't brought it anywhere close to parity with Perl 5, let alone the vision of what Perl 6 might eventually be.
At the original writing of this article, I believed that "subsequent releases will bring improvements on completeness, correctness, and competitiveness." While that's technically true—it is more complete, more correct with regard to the changing specifications, and has slightly better performance—its progress has been disappointing. I was wrong about its schedule.
This article remains online only for historical interest. It's out of date and misleading. Rakudo's all-but-abandonment of the Parrot virtual machine (and the subsequent diaspora of Parrot developers) have made Parrot a poor choice for the long term plans of Rakudo. (Someone inclined to conspiracies might suggest that this was a goal of the Rakudo developers.) The current state of Rakudo and startup time and benchmarks must thus use the JVM backend, as no other implementation is sufficiently advanced to participate in this benchmark.
I have no connection with Perl 6 and no desire to produce this benchmark. I suspect it would fare badly for Rakudo, but that is supposition not based on evidence.
In late 2010, David Skoll posted a comparison of Rakudo Star to Perl 5.
perl6 binary for the Parrot backend 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.
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.
You cannot easily compare the feature set of the Perl 5 binary to that of Rakudo Star. Perl 5 contains no advanced object system, no grammars, no continuations or coroutines, no junctions, and no interoperability with other languages. It also lacks contain hyperoperators, function and method signatures, multidispatch, laziness, built-in language redefinition, strictness by default, autothreading, REPL, and automatic binding to shared libraries. Somehow Perl 5 programmers manage, mostly by the CPAN:
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:
|Feature||Module||Virtual/Resident Memory in KB (cumulative)||Startup Cost (cumulative)|
|Parser manipulation||Devel::Declare (obsoleted by recent Perl 5 releases)||7356 / 2508||0.024s|
|Advanced object system||Moose and MooseX::Declare||18184 / 13064||0.705s|
|autoboxing||autobox, autobox::Core, and Moose::Autobox||19884 / 14732||0.777s|
|Coroutines||Coro||20276 / 15020||0.783s|
|Parse tree manipulation||B::Generate||20328 / 15080||0.799s|
|REPL||Devel::REPL||21132 / 15860||0.827s|
|Multidispatch||MooseX::MultiMethods||22076 / 16832||0.987s|
|Function signatures||signatures||22144 / 16920||0.992s|
|Shared library bindings||FFI||22188 / 16976||0.995s|
|Perl 5.12 features||feature||22216 / 16976||0.997s|
|Grammars||Regexp::Grammars||22780 / 17576||1.017s|
|Parrot language interoperability||Parrot::Embed (obsolete with the deprecation of Parot)||40812 / 18476||1.020s|
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.
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.
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
Remember; those were numbers in mid-2010. Compare Perl 5.18.2 (which has had feature enhancements and optimizations) to a recent Rakudo Star release on the JVM and you will see different numbers.
Of course, if you're comparing the ability of either language to let you get things done... well, Perl 5 still comes out ahead.