| |||||||||||||
|
| |||||||||||||
Wow.Wow.Posted Jul 30, 2010 0:16 UTC (Fri) by dskoll (subscriber, #1630)In reply to: Wow. by pmichaud Parent article: The first Rakudo Star release
OK, how about this: $ 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 (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.
(Log in to post comments)
Wow. Posted Jul 30, 2010 0:27 UTC (Fri) by chromatic (guest, #26207) [Link]
That Perl 6 executable is a thin C wrapper around uncompressed (and unoptimized) Parrot bytecode. It doesn't compare directly to the Perl 5 binary at all.
Wow. Posted Jul 30, 2010 0:43 UTC (Fri) by dskoll (subscriber, #1630) [Link] 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 :)
Wow. Posted Jul 30, 2010 1:17 UTC (Fri) by chromatic (guest, #26207) [Link]
Those are difficult estimates. I could see worthwhile targets being 2.0 for each of them, though I'd like to get startup time to 1.0 or less. It's possible to get memory consumption below 1.0, but that'll require more work in Parrot.
Wow. Posted Jul 30, 2010 3:20 UTC (Fri) by pmichaud (guest, #60150) [Link]
All of chromatic's responses apply, but the comparisons above are flawed at even a more basic level.
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
Wow. Posted Jul 30, 2010 3:45 UTC (Fri) by mikov (subscriber, #33179) [Link]
Yes, but what if you don't need all those capabilities? No more cheap quick & dirty scripts that we all love so much.
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.
Wow. Posted Jul 30, 2010 6:00 UTC (Fri) by chromatic (guest, #26207) [Link]
We're working on ways to avoid loading and initializing features you don't use. I have strong confidence that we can achieve that for deployable applications. I have some ideas on how to accomplish that for one-off applications.
Wow. Posted Jul 30, 2010 3:45 UTC (Fri) by dskoll (subscriber, #1630) [Link] 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.
Wow. Posted Jul 30, 2010 6:42 UTC (Fri) by pmichaud (guest, #60150) [Link] You've nailed it. In Perl 5, the bloat is optional. In Perl 6, it appears to be built-in....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
Wow. Posted Jul 30, 2010 12:00 UTC (Fri) by dskoll (subscriber, #1630) [Link] 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.
Wow. Posted Jul 30, 2010 12:23 UTC (Fri) by niner (subscriber, #26151) [Link]
Easy: Perl 5 has gotten faster over time and reduced memory footprint in many cases.
Wow. Posted Jul 30, 2010 14:45 UTC (Fri) by dskoll (subscriber, #1630) [Link] 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.
Wow. Posted Jul 30, 2010 21:35 UTC (Fri) by chromatic (guest, #26207) [Link]
Perl 5 isn't written primarily in Perl 5.
Wow. Posted Jul 30, 2010 23:30 UTC (Fri) by dskoll (subscriber, #1630) [Link] 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?
Wow. Posted Jul 31, 2010 0:30 UTC (Sat) by chromatic (guest, #26207) [Link] 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.
Wow. Posted Jul 31, 2010 14:16 UTC (Sat) by dskoll (subscriber, #1630) [Link] 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.
Wow. Posted Jul 31, 2010 16:39 UTC (Sat) by khc (subscriber, #45209) [Link]
I guess another way to look at it is, if they find a way to load those new features in perl6 on demand, then perl6 can be substantially smaller and faster (to start up).
Wow. Posted Jul 31, 2010 18:33 UTC (Sat) by chromatic (guest, #26207) [Link]
Exactly. Both Patrick and I believe that this is possible and desirable.
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.
Wow. Posted Aug 1, 2010 3:21 UTC (Sun) by efexis (guest, #26355) [Link] 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.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 :-)
|
|
||||||||||||