Re: Languages don't matter. A mathematical refutation

[Paul Rubin <no.email@nospam.invalid>]

"Randy Brukardt" <randy@rrsoftware.com> writes:
>> GC doesn't use that much of the runtime of typical programs
> Given that there is no such thing as a "typical program" when it comes to 
> memory management, that's a meaningless statement.

Take all the actively used programs out there and sort by decreasing
percentage of their runtime used by GC.  Throw away the top and bottom
10% as outliers and call the other 80% typical.  That seems meaningful
to me.

>> in GC'd languages, and the cpu overhead can be made quite small 
> And this isn't remotely the major expense,

So what is the major expense, and how often should anyone care about it?

>> There is no allocation overhead (just bump a pointer)
> And this is bogus. Either items are collected in place, which means that you 
> have to allocate from fragmented memory (a lot of more expensive than 
> "bumping a pointer" - that was the cause of the issues we had with our 
> compiler back in the day), or they're compacted somehow.

Yes, the idea is to use a copying collector, which compacts, so
allocation is just bumping a pointer.  I don't claim that the
copying/compaction phase has no overhead.  But, it is not too bad in
practice, for most applications in which GC is usable at all.

> And compaction is very expensive,

Maybe your info is out of date.  Modern gc's use generational copying,
so during most collections, only recently created data gets copied,
which isn't very much data.  There are also larger collections when
everything gets copied and that takes longer, but it's less frequent.
The aggregate overhead isn't too much.  There's tons of heavily used
code out there using GC these days, e.g. Gmail is written in Java unless
I'm mistaken.  They wouldn't have done that if GC was unaffordable.

> simply because copying things around for no reason is expensive. (Ada
> 2012 has to add access-in-place operations to the Ada Containers
> specifically to eliminate that overhead.)

That sounds like you're talking about copying in the application and not
in the GC.  The access frequency could be far higher in the app,
increasing the copying costs.

> Our compiler uses a lot of pointers; most of them act as handles and
> aren't actually dereferenced in the majority of the code, but they do
> get passed around a lot. That means a lot of copies of pointers, so
> lots of data structures to trace.

You trace from each pointer just once, either by setting a mark bit in
the object in the case of a mark-sweep collector, or by overwriting the
pointed-to object with a forwarding pointer in the case of a copying
collector.  So the number of objects matters much more than the number
of pointers.

Anyway, look at it like this.  If your compiler was written 30 years ago
and ran at tolerable speed then, it's 1000x faster now because of
advances in hardware.  Even if using GC would have slowed it down by 2x,
it's still 500x faster than before.