[Gllug] C++ Templates, Opinions?

Nix nix at esperi.org.uk
Sat Dec 25 00:17:58 UTC 2004


On Mon, 20 Dec 2004, Richard Jones prattled cheerily:
> On Mon, Dec 20, 2004 at 12:10:42PM +0000, Ian Norton-Badrul wrote:
>> Richard Jones wrote:
>> | Perhaps one day, once they've finished strings, they'll be able to do,
>> | oh, I don't know, garbage collection, or regular expressions, or
>> | bounds checking, and actually make the language useful for something ...
>> 
>> A good programmer doesnt need automatic garbage collection :-)
>> sureley free() is enough ;-)
> 
>:-)
> 
> The real problem with malloc/free is that they're slooowwwww.  Yes,
> really, they're slower than automatic garbage collection[1].

Well, really, they're slower than intelligent compilers that
can eliminate much use of storage, combined with a type-accurate
garbage collector.

In the C/C++ worlds, not much of that is available.

Our experience of GC in the GCC world has not been good. It eliminated
heaps of bugs and vast ownership-tracking complexity, but its effect on
cache locality was so severe that, well, most of the drastic slowdown
between GCC 2.95 and later GCC releases is probably attributable to
that.

It's now being rolled back and replaced with explicit allocations
in carefully chosen places, to try to reverse that horrible slowdown.

> In OCaml, the common path for allocations is 6 machine instructions
> (sic!).

Wow. That's a *hell* of a lot faster than glibc malloc(), which is
quite fast as malloc()s go.

>         That's about a nanosecond on a modern processor.  Dealloc-
> ation takes place all at once (in the garbage collector) resulting in
> excellent temporal locality, which means good use of the cache.

Yes :) languages allowing type-accurate collection (without agony) have
a massive advantage here.

> I won't even get started on the programmer time saved by not having to
> track down memory-related bugs.

A hundred times agreed. No competent programmer makes allocation errors
in low-complexity programs, but in something like, well, a compiler, you
have massive complex long-term-persistent changing data structures,
owned by nothing obvious... and GC is an absolute godsend.

> [1] Two things have given GC a bad name: Java and Emacs.  They are not
> representative of good, modern garbage collectors.

Java's garbage collector is actually very good compared to Emacs's :/

-- 
`The sword we forged has turned upon us
 Only now, at the end of all things do we see
 The lamp-bearer dies; only the lamp burns on.'
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list