Re: Current vs future Perl 6 binary size
On 04/22/2011 01:33 AM, gvim wrote: Do I take it that the Perl 6 binary is, by design, much larger than the current Perl 5.12 (1.6Mb) No, we didn't design either the language or the compiler with the goal of having a large executable. And I seem to recall we already had a similar discussion on #perl6, regarding executing speed. Cheers, Moritz
Re: Current vs future Perl 6 binary size
On Fri, Apr 22, 2011 at 12:33:45AM +0100, gvim wrote: The Perl 6 binary within the January release of Rakudo Star is 10Mb on my Snow Leopard system. Do I take it that the Perl 6 binary is [...] much larger than the current Perl 5.12 (1.6Mb) or is it simply that the Perl 6 binary is likely to lose more weight during the refinement process? In other words, is there a ballpark for how big the Perl 6 binary will be when development settles down? Comparing any Perl 6 binary against the Perl 5 binary is very much an apples-to-oranges comparison. For one, Perl 6 has far more features than Perl 5 -- for a fairer comparison, compare Perl 6 to (Perl 5 + Moose + Regexp::Grammars + ...). Also, the Rakudo Perl 6 binary is not really a binary in the normal machine code compiled from C sense. Most of what the binary contains is Parrot objects and bytecode. We can actually make the perl6 executable file itself as small as 50K, but the first thing it then does is load a several-megabyte Parrot bytecode library. But overall answer to your question -- yes, we expect that improvements in Parrot (better serialization, better bytecode formats, better object system) will enable us to significantly reduce the current size of the perl6 executable. I don't know by how much, but a 50% reduction in size doesn't seem unrealistic. Pm
Re: Current vs future Perl 6 binary size
On Fri, 2011-22-04 at 09:09 -0500, Patrick R. Michaud wrote: We can actually make the perl6 executable file itself as small as 50K, but the first thing it then does is load a several-megabyte Parrot bytecode library. But overall answer to your question -- yes, we expect that improvements in Parrot (better serialization, better bytecode formats, better object system) will enable us to significantly reduce the current size of the perl6 executable. I don't know by how much, but a 50% reduction in size doesn't seem unrealistic. Does this 50% reduction in size apply to the library above (perl6 50kB, parrot lib sMB) ? Could one make further optimizations to the Parrot bytcode library via native libraries ? -- --gh
Re: Current vs future Perl 6 binary size
On Fri, Apr 22, 2011 at 10:27:47AM -0400, Guy Hulbert wrote: On Fri, 2011-22-04 at 09:09 -0500, Patrick R. Michaud wrote: We can actually make the perl6 executable file itself as small as 50K, but the first thing it then does is load a several-megabyte Parrot bytecode library. But overall answer to your question -- yes, we expect that improvements in Parrot (better serialization, better bytecode formats, better object system) will enable us to significantly reduce the current size of the perl6 executable. I don't know by how much, but a 50% reduction in size doesn't seem unrealistic. Does this 50% reduction in size apply to the library above (perl6 50kB, parrot lib sMB) ? Yes -- the reductions primarily come from reductions in the bytecode (which will be the same in both cases). Could one make further optimizations to the Parrot bytcode library via native libraries ? Probably not -- at least not until there are some significant changes to Parrot bytecode itself. By Parrot bytecode library above what I really mean is Parrot bytecode that implements the Rakudo Perl 6 compiler and Perl 6 libraries. Pm
Re: Current vs future Perl 6 binary size
On Fri, Apr 22, 2011 at 05:15:30PM +0200, Moritz Lenz wrote: After some futher analysis I found that perl6.pbc and the perl6 binary both are about 11MB in size - and 1.3MB when compressed with gzip. So if anybody actually wants to do something about the size, teach parrot's pbc_to_exe compress the pbc, and uncompress into memory upon loading. ...this comes at the cost of not being able to mmap the bytecode, though. In other words, we save 10MB of disk space, but cause each invocation of Rakudo to eat up 11MB of data memory instead of being able to (potentially) mmap a shared copy. In the long run it might also be possible to come up with a more compact PBC format, but I guess that's much more work than compressing and decompressing. Perhaps Lorito will be able to help here. But ultimately the real savings (both memory and startup time) will come when we can truly serialize Rakudo's subroutines and constant data structures. Pm
Re: Current vs future Perl 6 binary size
On Thu, Apr 21, 2011 at 6:33 PM, gvim gvi...@gmail.com wrote: This is not a criticism of anything. I am not a core developer but need to be aware of what to expect when Perl 6 settles down into a production-ready state. The Perl 6 binary within the January release of Rakudo Star is 10Mb on my Snow Leopard system. Do I take it that the Perl 6 binary is, by design, much larger than the current Perl 5.12 (1.6Mb) or is it simply that the Perl 6 binary is likely to lose more weight during the refinement process? In other words, is there a ballpark for how big the Perl 6 binary will be when development settles down? I doubt anyone can tell you how big the binary will be with any degree of certainty. WRT the size of your Perl 5 binary ... how big is your libperl? A good chunk of the work also lives there. For instance, on my system, /usr/bin/perl is about 1.2 mb and /usr/lib/libperl.so.5.10.1 is about 1.4 mb. (and Rakudo Perl 6 is about 5.6 mb). I don't know about any of the other Perl 6 implementations, but Rakudo Perl 6 currently doesn't have a separate libperl6, nor is it highly optimized for size or speed. Once that effort starts, it's anybody's guess as to what the binary will look like. I guess you could say it's that way by design because most of the effort has been focused on the grand whirlpool of implementing the spec then adjusting the spec once we have some experience with the implementation, then implementing that new spec and so on. hope this helps, -Scott
