From: Brent Roman Date: 2010-01-13T10:54:25+09:00 Subject: [ruby-core:27576] Re: better GC? The main point of this particular GC algorithm was to reduce the maximum latency it imposed. It seems to manage this very well in a way that's compatible with the existing MRI structure. But, the cost is that long-term average throughput may be reduced by 10% or so. Most incremental algorithms are not as fast as those that don't allow for interruption. So, as you point out, if you've got all your cores and hyperthreads fully utilized, this GC will hurt average throughput. However, I'd submit that: 1) most systems running Ruby today have multiple cores and/or hyperthreading 2) Desktop systems rarely keep all their cores busy, 3) the more cores you have, the more likely it is that one or more is not being fully utilized at any given instant. It's really hard to keep an 8-core server CPU bound for extended periods, especially when it's serving the web pages. So, most Ruby installations would see a net increase in throughput with this GC. But, again, that's not its main design goal. Reducing latency is. 10ms max latency would eliminate the GC induces freezes that distract users and allow Ruby to be used more in financial, robotics, audio and video processing. - brent Kirk Haines wrote: > > On Tue, Jan 12, 2010 at 1:11 PM, Kurt Stephens > wrote: > >> ��If that's the case, then no one would use multi-core processors at all. >> ��How the threads are mapped to a processor (i.e. another core or not) is >> an >> OS issue. > > Maybe you miss my point? See below. > >> ��The issue here is that the majority of the work can be done in a >> separate >> thread which allows the mutator (in this case Ruby) to continue >> ��while the GC's thread is doing its job. > > If I have one core, under that particular GC scheme, my stuff runs 10% > slower. > > If I have two cores, my stuff runs X% faster, because a bunch of the > GC work is offloaded to that second core. > > So, if I have my code already running on two cores, there aren't any > more idle cores available to actually offload GC work to. So my code > on both cores is now running 10% slower. > > i.e. overall, we're doing more work to get a certain execution time or > throughput on our code using the Boehm conservative GC mentioned, but > that GC can spread the work out among more cores, so if the machine > isn't already running at max CPU capacity, that one job can appear to > run faster, but that breaks down if all of the cores are being > utilized for work. For example, let's say that I have a 4 core > machine. I'm running some code on it that, when pushed to its limits, > utilizes all four cores at 100%. > > ... > > Kirk Haines > > > -- View this message in context: http://old.nabble.com/-ruby-core%3A27135--better-GC--tp26735247p27138333.html Sent from the ruby-core mailing list archive at Nabble.com.