The first Rakudo Star release
Rakudo Star is aimed at 'early adopters' of Perl 6. We know that it still has some bugs, it is far slower than it ought to be, and there are some advanced pieces of the Perl 6 language specification that aren't implemented yet. But Rakudo Perl 6 in its current form is also proving to be viable (and fun) for developing applications and exploring a great new language. These 'Star' releases are intended to make Perl 6 more widely available to programmers, grow the Perl 6 codebase, and gain additional end-user feedback about the Perl 6 language and Rakudo's implementation of it." It's built on the Rakudo Perl 6 compiler, the Parrot virtual machine, and an initial set of library modules.
Posted Jul 29, 2010 15:33 UTC (Thu)
by diederich (subscriber, #26007)
[Link]
Posted Jul 29, 2010 15:38 UTC (Thu)
by ggoebel (guest, #4487)
[Link] (1 responses)
Posted Jul 29, 2010 16:42 UTC (Thu)
by chromatic (guest, #26207)
[Link]
Posted Jul 29, 2010 16:41 UTC (Thu)
by b7j0c (guest, #27559)
[Link] (1 responses)
Posted Jul 29, 2010 19:35 UTC (Thu)
by jonabbey (guest, #2736)
[Link]
Posted Jul 29, 2010 19:27 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (36 responses)
Here are some interesting statistics. Running ./perl6 and then doing nothing creates a process with a VSIZE of 93MB. Doing the same with perl5 creates a process with a VSIZE of 3.4MB.
Second wow:
What is perl6 doing on startup that uses 2 seconds of user CPU time?
Posted Jul 29, 2010 20:13 UTC (Thu)
by b7j0c (guest, #27559)
[Link] (13 responses)
rakudo is about getting people using perl6...playing with the features, porting modules...
in that regard this is a huge success. its safe to say 99% of perl5 users probably don't know 1% of the cool features in the core perl6 language...its important that these people know that perl6 is no longer just a internet meme about vaporware...
Posted Jul 30, 2010 0:09 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (12 responses)
All your points are taken, and yet... I have never heard of a piece of software whose memory consumption dropped by 96% and startup time by 98% from the first alpha release to the first production release. That's what it would take to match the perl5 binary.
I certainly hope the Perl 6 developers are smart enough to pull off such a feat.
Posted Jul 30, 2010 7:22 UTC (Fri)
by niner (subscriber, #26151)
[Link] (11 responses)
Posted Jul 30, 2010 10:02 UTC (Fri)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Jul 30, 2010 21:06 UTC (Fri)
by ariveira (guest, #57833)
[Link]
"The most amazing achievement of the computer software industry is its
Posted Jul 30, 2010 12:01 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (8 responses)
Well the perl5 binary did have 17 (!!) years of time for optimization.
But in those 17 years, the perl5 binary has grown, not gotten smaller. (I'm not sure about speed. I suspect important parts such as the regex engine have been made faster over time.)
Posted Jul 30, 2010 12:13 UTC (Fri)
by niner (subscriber, #26151)
[Link] (7 responses)
Seriously: what exactly is the point of your statistics showing the surprising results that an early adopters pre-release is not as optimized as the predecessor that has been in used production for over 15 years? Another surprise: it also has more bugs! Who'd have thought?
Posted Jul 30, 2010 14:49 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (6 responses)
Seriously: what exactly is the point of your statistics showing the surprising results that an early adopters pre-release is not as optimized as the predecessor that has been in used production for over 15 years?
Come on! Eliminating 95% of memory usage and reducing startup time by a factor of 500 is merely a matter of optimization?
I recently completely rewrote a C program we were using in-house to use less memory. I reduced the memory to 1/3rd of the original, and that was with a large amount of effort and creative hacks. There is simply no way to "optimize away" the amount of bloat needed to make Perl 6 competitive with Perl 5.
After ten years of development, if the best that can be achieved is a feature-incomplete, buggy, bloated alpha... that's a sign that the project has gone off the rails.
Posted Jul 30, 2010 15:06 UTC (Fri)
by niner (subscriber, #26151)
[Link] (4 responses)
That's what you get by reducing the comparison of complex things like programming languages to one single metric.
Posted Jul 30, 2010 15:34 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (3 responses)
Competitive on what grounds?
Performance and memory consumption.
On saving a couple of megabytes of memory?
Umm... a "couple of megabytes"? I'm talking about 93MB. Our commercial product uses many (sometimes hundreds) of concurrent Perl processes. Even though it's not embedded, 93MB extra overhead per process would kill us. (In perl 5, even though we fork after loading all our modules, it seems that the reference-counting GC method makes copy-on-write inefficient; most memory pages end up getting touched and we see poor memory sharing among processes.)
Me and many others just couldn't care less.
Yes, and that is obvious by the state of Perl 6: Buggy, feature-incomplete and bloated after a decade of development.
The notion that programmer time is far more valuable than performance or memory consumption is usually true, but it is not true when it comes to programming languages. The designers of programming languages must try to make them efficient, because the time they spend doing that is multiplied thousands or millions of times when people use the language. Something that makes Perl a bit faster or smaller has enormous dividends, far more than one particular developer making his or her particular Perl project smaller or faster.
So if your feelings about speed and memory ("couldn't care less") is indicative of the general attitude among Perl 6 developers, then I say it again: This is a doomed project. It may be unpopular to say that in the Perl community, but I bet most objective outsiders would agree with my assessment.
So one could easily turn that argument around: by requiring the use of countless fragile models to still not reach the same level of maintainability and robustness features that Perl 6 has, Perl 5 is just not competitive.
Except that's all in theory. A robust implementation of Perl 6 doesn't exist yet, and we have no idea whether or not the average Perl 6 project will be any more maintainable than the average Perl 5 project.
Posted Jul 30, 2010 16:29 UTC (Fri)
by chromatic (guest, #26207)
[Link] (2 responses)
Patrick and I know where time and memory go in Rakudo Star, and as such, we're confident that we can find major optimizations. For example, with some effort we can halve the amount of memory used for objects, which both reduces the memory footprint and the amount of time spent in the garbage collector. Other such optimizations exist; don't assume that we care nothing for them.
(Oh, and Rakudo's been in development since November 2007--to correct your "decade" number.)
Posted Jul 30, 2010 17:38 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (1 responses)
You are correct in assuming I haven't looked deeply at the code for Rakudo Star. I just downloaded it to "kick the tires".
I wish you luck in your optimization efforts, though I remain doubtful you'll succeed.
Rakudo's been in development since November 2007--to correct your "decade" number.
My "decade" reference refers to Perl 6 itself; the first design notes for Perl 6 came out in 2000, I believe. (Another sign of a project in trouble, IMO, is abandonment of a major line of development [PUGS] in favor of a completely different line.)
Posted Aug 18, 2010 5:21 UTC (Wed)
by lindahl (guest, #15266)
[Link]
Posted Aug 5, 2010 15:42 UTC (Thu)
by nix (subscriber, #2304)
[Link]
An example: I sped up the userspace daemon used by the entropy key hardware by more than 1/3rd (minimal figure) or more than 95% (maximal figure) last night. It took about an hour. This is not because the ekeyd authors were fools or lazy: it's because they had other things to do than optimization, so the first person to optimize it could get major speed improvements with very little effort and a few algorithmic changes to a couple of hotspots. (If the structure of the code is such that such changes are unnecessarily hard, that *is* an indictment of the original developers. This certainly wasn't true of the ekeyd and I doubt it's true of Rakudo.)
I would *expect* developer prereleases of software to be just like this more often than not.
Posted Jul 29, 2010 20:59 UTC (Thu)
by pmichaud (guest, #60150)
[Link] (20 responses)
This is the primary reason for Rakudo's slow startup; and like most things in Rakudo and Parrot, the development teams are actively working on fixes for it.
Pm
Posted Jul 30, 2010 0:16 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (19 responses)
OK, how about this:
(I included libparrot.so because it's not a standard system library.) So perl5 is about 1.2MB of program text, whereas perl6 weighs in at 15MB and still needs to dynamically create things that couldn't be put directly in the binary?
I repeat the title. Wow.
Posted Jul 30, 2010 0:27 UTC (Fri)
by chromatic (guest, #26207)
[Link] (2 responses)
Posted Jul 30, 2010 0:43 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (1 responses)
Let's assume that the final Perl 6 release is N times larger than Perl 5, starts up M times as slowly, and uses P times as much memory after initialization. What's your best guess as to the values of N, M and P in the first production release? Huge bonus if they're less than 1.0 :)
Posted Jul 30, 2010 1:17 UTC (Fri)
by chromatic (guest, #26207)
[Link]
Posted Jul 30, 2010 3:20 UTC (Fri)
by pmichaud (guest, #60150)
[Link] (15 responses)
To really have a fair comparison, one needs to compare the memory footprint and startup time of Rakudo versus Perl 5 *with* all of Moose, Devel::Declare, Regexp::Grammars, Contextual::Return, Data::Dumper, etc. loaded and available. Otherwise you're not really comparing equivalent capabilities.
I suspect Rakudo may still come out slower and fatter than an "equivalent Perl 5", but likely much less so than these naive comparisons seem to suggest. And we're still very early in the "optimization" aspects of the development process for Rakudo.
Pm
Posted Jul 30, 2010 3:45 UTC (Fri)
by mikov (guest, #33179)
[Link] (1 responses)
It is starting to look like Java in terms of startup speed and footprint, and that is saying something...
Unless the situation changes drastically, no way you can use Perl 6 for lightweight system scripting, etc.
Posted Jul 30, 2010 6:00 UTC (Fri)
by chromatic (guest, #26207)
[Link]
Posted Jul 30, 2010 3:45 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (12 responses)
To really have a fair comparison, one needs to compare the memory footprint and startup time of Rakudo versus Perl 5 *with* all of Moose, Devel::Declare, Regexp::Grammars, Contextual::Return, Data::Dumper, etc. loaded and available. Otherwise you're not really comparing equivalent capabilities.
You've nailed it. In Perl 5, the bloat is optional. In Perl 6, it appears to be built-in.
I've used Perl since 1996, and have been developing both free and commercial software with it intensively since 2002, and I'm utterly dismayed by the direction it is taking. IMO, Perl 6 is a textbook example of Second System Syndrome.
Even Perl 5 is suffering; CPAN is balkanizing into groups of modules with irreconcilable dependencies (eg. anything that wants Moose vs. Rose::DB that will never use Moose) that simply multiply the bloat.
Well, I'm hedging my bets and looking at other languages.
Posted Jul 30, 2010 6:42 UTC (Fri)
by pmichaud (guest, #60150)
[Link] (11 responses)
...except that most of Rakudo's existing runtime startup and extra dynamic memory costs for these additional features can be eliminated altogether, whereas that will be much more difficult to do in Perl 5. Just because these features are bloated today doesn't at all mean that it must always be so. Pm
Posted Jul 30, 2010 12:00 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (10 responses)
Just because these features are bloated today doesn't at all mean that it must always be so.
This is true in theory. Now please name one major software project that has become significantly smaller and faster over time. For bonus points, name one that did so while adding features (which is what Rakudo Star needs to do before it can go into production.)
I believe the improvements in speed and memory required to make Perl 6 competitive with Perl 5 are unprecedented in the history of computer science. I know the Perl 6 authors mean well and have been working hard, but I fear they've developed another Chandler.
Posted Jul 30, 2010 12:23 UTC (Fri)
by niner (subscriber, #26151)
[Link] (9 responses)
Posted Jul 30, 2010 14:45 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (8 responses)
Moderately faster, I can believe, but certainly not a smaller memory footprint. My experience is that Perl's memory footprint has grown at a small rate with each new major release.
And Perl certainly hasn't shrunk by over 95% nor speeded up by a factor of 25, which is the kind of improvement needed for Perl 6 to be competitive.
Posted Jul 30, 2010 21:35 UTC (Fri)
by chromatic (guest, #26207)
[Link] (7 responses)
Posted Jul 30, 2010 23:30 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (6 responses)
I don't understand that last remark. Are you saying Rakudo Star is implemented in Perl 6? And that it's "just" a matter of rewriting it in something else to make it small and fast?
Posted Jul 31, 2010 0:30 UTC (Sat)
by chromatic (guest, #26207)
[Link] (5 responses)
Your comparison of the size of an optimized binary produced by an optimizing C compiler to an unoptimized barely-a-binary-at-all produced by an unoptimizing Perl 6 comparison is silly. Ditto your comparison of the memory use. Likewise your comparison of the feature set. Compare the optimized Perl 5 to the unoptimized Rakudo Star on feature set for a more accurate depiction of the situation.
Posted Jul 31, 2010 14:16 UTC (Sat)
by dskoll (subscriber, #1630)
[Link] (4 responses)
Even your "accurate comparison" shows that Perl 5 is significantly smaller and faster than Rakudo Star.
But here's the thing: You had to add a lot of modules to Perl 5 to get it to be in the same order of magnitude of slowness and bloat as Rakudo Star. But Perl 5 without all those modules is still a very useful tool. It seems that with Perl 6, we have no choice: We get all the features whether or not we'll use them.
In 14+ years of Perl development, I haven't written a single project that uses even one of those Perl 5 modules you loaded for comparison purposes (though I suspect eventually I'll be forced to drag in Moose as more and more CPAN modules require it.) So I think it's you who is gaming the comparison. I'm pretty sure I could find a way to make Perl 5 10x slower and bigger than Rakudo Star, but that doesn't reflect the way people actually use Perl 5.
Posted Jul 31, 2010 16:39 UTC (Sat)
by khc (guest, #45209)
[Link] (3 responses)
Posted Jul 31, 2010 18:33 UTC (Sat)
by chromatic (guest, #26207)
[Link] (1 responses)
Even so, anyone who's happy with the features of Perl 5 is more than welcome to continue to use Perl 5. It's not going anyway any time soon.
For people who want use Perl 5 as if it were Perl 6, Rakudo Star is becoming a more and more useful and usable option, and it'll continue to do so.
Posted Aug 1, 2010 3:21 UTC (Sun)
by efexis (guest, #26355)
[Link]
Posted Aug 1, 2010 6:49 UTC (Sun)
by rjbond3rd (guest, #53168)
[Link]
Over the years, my ideas about Perl became rigid and limited. But after reading the design docs (Synopses), it's easy to see the Perl 6 goals, the challenges, the trade-offs, the design decisions.
These docs really flesh out the rationale. The concepts from functional programming are fascinating.
It's not hard at all to imagine a lean and mean Rakudo down the road. Every major leap in computing has been accompanied by complaints about speed and memory :)
Posted Jul 30, 2010 7:37 UTC (Fri)
by exadon (guest, #5324)
[Link] (1 responses)
Posted Aug 1, 2010 3:23 UTC (Sun)
by efexis (guest, #26355)
[Link]
Posted Aug 1, 2010 3:40 UTC (Sun)
by wruppert (subscriber, #3041)
[Link] (1 responses)
Posted Aug 1, 2010 20:35 UTC (Sun)
by bronson (subscriber, #4806)
[Link]
The first Rakudo Star release
say 'Xmas in July'
say 'Xmas in July'
The first Rakudo Star release
The first Rakudo Star release
Wow.
$ time ./perl6 < /dev/null
real 0m2.509s
user 0m2.000s
sys 0m0.212s
$ time perl < /dev/null
real 0m0.004s
user 0m0.000s
sys 0m0.004s
Wow.
Wow.
Wow.
Wow.
Wow.
continuing cancellation of the steady and staggering gains made by the
computer hardware industry."
Henry Petroski
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
$ size ./perl6 ./install/lib/libparrot.so.2.6.0
text data bss dec hex filename
14219892 400 8 1422030 d8fc0c ./perl6
1535297 196868 796 1732961 1a7161 .../libparrot.so.2.6.0
$ size /usr/bin/perl
text data bss dec hex filename
1245399 6744 344 1252487 131c87 /usr/bin/perl
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
You've nailed it. In Perl 5, the bloat is optional. In Perl 6, it appears to be built-in.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
Wow.
I want the multi-threadedness that p6 offers (I am correct in assuming this is correct helpful multi-threadedness, rather than what p5 has?) and many other language enhancements of p6, BUT with the agreeable sigils of p5 that makes it a more natural language, eg, in p5, A $sigil on it's own or A $sigil[10] in A [group] IS agreeable. In p6, ARE A @sigil[10] agreeable? No, in p6, A @sigil[10] AREN'T agreeable. I'm assuming that if you can speak perl and especially if you've ever tried to learn another language where agreement is more obvious than it is in English that you can understand what I'm saying. And yes I am aware that it can be changed with grammars, but still... yacky! I love all the naturalnesses of the p5 language, it's what makes me love using it over any other language so much, I love expressive speech, it's sad to see much of that gone in p6 :'-( I do understand it makes it easier for the machine to parse tho.
Wow.
I do >>love>> all that stuff tho. Not keen on tying ~ strings ~ together ~ with ~ this ~ though, that's a really awkward key to press, much slower than . or + which I would probably just have to overload if I can ever get over how un-agreeable all the @sigils is now... see, it just doesn't sound right! But then I don't like the term 'overload' either, it should be 'override', 'overloading' an operator sounds like a way of testing it to find out at what level it will fail, or have a scottish person show up and say "the operators captain, they cannae take it!" so maybe I'm just way too picky *lol* but no I can forgive that, I understand it means "to load over" not actually "overload", so that are one issue that I is happy to forgive... SEE! You need agreement in language! *lol*
I'll shut up now :-)
Wow.
"Early Adaptors": R.I.P.
"Early Adaptors": R.I.P.
Congratulations
Congratulations