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.
Rakudo's 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.
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.
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.
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.
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.
Someone needs to send that guy one of these.
I proudly own one myself. If anybody else wants some Rakudo and Perl 6 gear, they can visit any of the following URLs:
http://zazzle.com/rakudo
http://cafepress.com/rakudo
http://rakudo.spreadshirt.com
And about the comparisons, it seems to me that this may be just like Java all over again, except in this case all the years of planning and development have been out in the open for all to see instead of a secret skunkworks inside a corporation. Never mind that there is no giant marketing machine with millions of $$ out in full-force, nor will there be as far as I can tell!
Fifteen years ago, Java was criticized for being slow, buggy, and for missing features. Many critics pointed at its prevalent use for "applets" and declared it a toy. Five years later it had far fewer bugs, was much faster, and had gained many new features. Five years after that it had become the go-to language for teaching in many colleges, and it is now relied upon in businesses the world over who need complex, stable, fast applications. (I won't argue that Java is actually more suitable for business applications, since it's simply not true, but it seems to be the perception and for PHBs that's as good as reality.)
So, in five years, perhaps we will see the Perl 6 equivalent of Java 2.0... and in ten... who knows? :-D
I always work to the principle of:
- Write a program
- Make it work
- Make it work correctly
- Make it work correctly and fast
I think it's quite reasonable for a "first release" to be an order of magnitude slower and larger in memory than similar solutions that have had a decade or so of optimisation.Another maxim of mine is that
While for enterprise software this comparison might be relevant I just had to write a small throw-away script that would manipulate hundreds of files. It ran under a second in Perl 5.
I think that type of small script and the small sys-admin scripts are a huge part of what perl is used for today. I hope Rakudo will be able to provide similar speed for such small scripts as well.
Without that a huge part of the Perl user base won't be able to switch.
That's definitely a goal of Rakudo as well, Gabor.
And now to "incredible" size of the rakudo-star package.
I just finished packaging rakudo-star, which is parrot, rakudo and the additional rakudo-star modules, blizkost and some docs.
See http://rurban.xarch.at/cygr/parrot/
parrot 1.1M
rakudo 1.6M
rakudo-star 378K
Compare this to the typical perl5 package with
some basic modules as shipped with cygwin:
perl5 12M
And now compare this to a typical java package.
parrot-devel 597K
parrot-docs 391K
vs.
sun-java6-jdk 20.2 MB