[ruby-core:27576] Re: better GC?

The main point of this particular GC algorithm was to reduce the maximum=20
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=
=20
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 thi=
s
GC.
But, again, that's not its main design goal.  Reducing latency is. =20
10ms max latency would eliminate the GC induces freezes that distract users
and=20
allow Ruby to be used more in financial, robotics, audio and video
processing.

- brent



Kirk Haines wrote:
>=20
> On Tue, Jan 12, 2010 at 1:11 PM, Kurt Stephens <[e-mail]>
> wrote:
>=20
>> =C2=A0If that's the case, then no one would use multi-core processors at=
 all.
>> =C2=A0How the threads are mapped to a processor (i.e. another core or no=
t) is
>> an
>> OS issue.
>=20
> Maybe you miss my point?  See below.
>=20
>> =C2=A0The 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
>> =C2=A0while the GC's thread is doing its job.
>=20
> If I have one core, under that particular GC scheme, my stuff runs 10%
> slower.
>=20
> If I have two cores, my stuff runs X% faster, because a bunch of the
> GC work is offloaded to that second core.
>=20
> 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.
>=20
> 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%.
>=20
> ...
>=20
> Kirk Haines
>=20
>=20
>=20

--=20
View this message in context: http://old.nabble.com/-ruby-core%3A27135--bet=
ter-GC--tp26735247p27138333.html
Sent from the ruby-core mailing list archive at Nabble.com.