Rakudo needs from Parrot in 2011

[Patrick R. Michaud]

On Mon, Jan 31, 2011 at 08:05:29PM +0100, Nick Wellnhofer wrote:
> (Side note: A single iteration of the loop above seems to allocate
> about 3MB of memory. I also get:
> 
> $ time ./perl6 -e -1
> real    0m0.752s
> $ time ./perl6 -e 'for 1..100 { time }'
> real    0m0.758s
> $ time ./perl6 -e 'for 1..100 { now }'
> real    0m4.512s
> 
> There must be something wrong with "now". End side note)

The fact that C<now> takes longer than C<time> is not
entirely unexpected.  

The C<now> term constructs an C<Instance> object using the 
Instance.from-posix method, which represents an opaque
representation of fractional atomic seconds (TAI) in an
epoch-agnostic form.  Since Parrot doesn't provide this
value natively (most systems do not), Rakudo has to construct
the Instance object from the POSIX time value, adjusting it
for leap-seconds and other variations as provided by a table
of leap-seconds.

The C<time> term simply returns the POSIX time value
reported by Parrot's time_n opcode (and doesn't even
have to box it into a PMC), so it's obviously a lot faster.

So there's nothing wrong with C<now>, other than it currently
takes a lot more work to construct than C<time> and we should
probably see about optimizing it.  But the expense of C<now>
serves very much to further the point of the demonstration:
Even in loops where there's a non-trivial amount of work taking
place in the body of the loop, Parrot's GC has the impact of making
some iterations take 10x longer than the rest.

> You also have to keep in mind that latency and throughput are
> competing goals. For example, a Rakudo build will always be slower
> with an incremental garbage collector compared to a "stop-the-world"
> collector.

Most of Rakudo's users are less concerned with the time needed 
to build Rakudo (which they do rarely) than with the time needed 
to compile and run small application programs, which they do 
frequently.  This is especially true for people who download
precompiled Rakudo packages and never experience the build time.
I fully grant that your comment can apply also to the time
needed to compile an application program... but as yet most
application programs are far smaller than Rakudo itself, and runtime
speed is often the dominant component there.

> I hope this clarifies why there hasn't been much progress in this
> area and why you shouldn't expect too much in 2011.

I totally understand the reasons why Parrot has not made progress
on GC, and why it's not likely to happen in 2011.  I was asked to 
provide a list of current Rakudo needs from Parrot, and GC
performance is one that has been on the list for quite some time.
I'm not seeking for explanations or justficiations of why things are 
the way they are, I'm informing the Parrot team of Rakudo's current 
needs (as I was requested to do by the participants of this 
weekend's PDS).

And I again acknowledge that 2010 saw some significant improvements in
Parrot GC.

But I think I should also offer some thoughts from an HLL camp:
"better GC and memory management" is one of the frequently-cited 
"likely advantages" people mention in regards to the idea of
migrating Rakudo to platforms other than Parrot.  Whether running 
on other platforms will result in an _actual_ advantage in this 
area remains to be seen of course, but I think the ongoing 
perception of "slow Parrot GC" is definitely having a very negative 
impact on opinions of Parrot in the "HLL marketplace".  

Not only this, but Parrot GC has been cited as a core problem at
meetings and Parrot Developer's Summits for many years now -- even 
well before the first PDS in 2008.  As a potential user (and indeed
as a Rakudo developer), I think it damages Parrot's image greatly
that it seems continually unable to resolve what is arguably one 
of *the* most fundamental and historically important components 
of any dynamic language environment.

Pm