Re: Languages don't matter. A mathematical refutation

["Randy Brukardt" <randy@rrsoftware.com>]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87oan0aote.fsf@jester.gateway.sonic.net...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> GC overhead (and the corresponding allocation overhead) would be a lot
>> more than the combination of free chaining and static allocation ...
>
> 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. The memory management 
patterns in a compiler, for instance, are wildly different than in a web 
server. (Having written both, I have some practical experience there. :-) 
The real-time systems that Ada customers build are very different from both.

> in GC'd languages, and the cpu overhead can be made quite small with
> generational gc's.

And this isn't remotely the major expense, so that's just a case of 
optimizing the wrong thing.

> 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. And compaction is 
very expensive, 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.)

> and no overhead of freeing garbage.  There is some overhead
> from tracing and copying the recently created live data (minor
> collections, the amount of data touched is usually small) and occasional
> more expensive major collections (they also trace older data).  This
> does have a cost in memory footprint but the cpu load isn't that big.

And this is what is complete fantasy. Being able to trace objects requires 
keeping a lot of extra information at runtime. Keeping enough information to 
allow runtime debugging slows down our code 5-10% (it makes calls to small 
subprograms much more expensive). You'd need that and more to be able to do 
any sort of trace. And I'm dubious about the supposed cost of those traces. 
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.

                                            Randy.