Which leads us to why we need pluggable GC: There simply isn't one GC
that fits all uses.

// Magnus Holm



On Tue, Jan 12, 2010 at 22:09, Kirk Haines <wyhaines / gmail.com> wrote:
> On Tue, Jan 12, 2010 at 1:11 PM, Kurt Stephens <ks / kurtstephens.com> wrote:
>
>> If that's the case, then no one would use multi-core processors atall.
>> 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%.
>
> If I'm running my code under the Boehm conservative GC, then so long
> as only two or three cores are being pushed to their limits, or so
> long as none of the four cores are being pushed too bar, there is
> excess CPU capacity to handle the GC tasks, thus making my code run
> with greater throughput. However, as soon as all of the cores get
> busy enough, the situation on the multicore machine is no different
> than the situation would be on a single core machine -- my code has
> execution times that are 10% longer. So, when looking at the machine
> as a whole, it's overall processing capacity, at least for CPU bound
> tasks, gets reduced versus a GC that doesn't exact this tax. It is
> only a benefit when the cores are not being used to capacity.
>
>
> Kirk Haines
>
>