Rakudo needs from Parrot in 2011

[Nick Wellnhofer]

On 31/01/2011 21:48, Patrick R. Michaud wrote:
> 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.

That's a problem that every stop-the-world GC has. AFAIK the default GCs 
of the JVM and CLR are also non-incremental, but they're parallelized 
and generational, so the problem isn't that pronounced.

Another reason for the large pauses in your simple example is the overly 
large GC threshold that Parrot currently uses. We have upcoming fixes 
for that. But programs that really need a large amount of memory will 
still have noticably long pauses. Parrot's GC is much like early JVMs in 
the 90s in that respect.

> 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.

Small programs shouldn't exhibit those large delays once the dynamic 
threshold branch is merged and the GC parameters are tuned a little.

> 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).

I know. I simply wanted to describe our problems for other readers of 
the list.

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

Parrot's GC is now (almost) at a point where it should only consume a 
fixed percentage of program running time under any circumstances. I 
guess it's about 15-20% for mark and sweep. Another big chunk of running 
time is used for memory allocation itself. So except for latency the GC 
should never pose a fundamental performance problem.

> 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".

You're absolutely right. GC is a hard problem that's actively 
researched. A good GC is one of the most important selling points of a 
VM. Just look at the efforts companies like (Ex-)Sun, Microsoft and IBM 
have put into that.

Nick