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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
