You missed the point

Posted Mar 27, 2008 4:59 UTC (Thu) by artem (subscriber, #51262)
In reply to: You missed the point by sylware
Parent article: Striking gold in binutils

Well then you should really stay away from the programming for some time already.

Guess what the language is used for the tools used in designing computer chips?

(for reference, see http://www.research.att.com/~bs/applications.html, scroll down to the
bullet labeled 'Intel')

You missed the point

Posted Mar 27, 2008 5:50 UTC (Thu) by lysse (guest, #3190) [Link]

colorForth? ;)

You missed the point

Posted Mar 27, 2008 7:37 UTC (Thu) by pr1268 (guest, #24648) [Link] (2 responses)

Google has written a memory allocator library (to compete with the Glibc 2.3 equivalent, ptmalloc2), in C++.

Now, my understanding of the memory allocator is that this is a library whose run-time efficiency should be unquestioned. This is code that interfaces with the kernel nearly continuously. Accordingly, C++ would not have been my first choice of programming language in which to implement this (I would have chosen C, but don't mind me--I've never written a memory allocator before!).

But, Google's allocator library appears to have improved performance over the incumbent Glibc ptmalloc2 in certain scenarios, according to the graphs near the bottom of that page. And to think this was accomplished with C++ (I'm assuming that the Glibc ptmalloc2 is written in C, but I do ask someone to correct me if I'm wrong).

You missed the point

Posted Mar 27, 2008 11:05 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Actually the memory allocator largely interfaces with itself and its userspace callers. Its
interface with the kernel is restricted to the occasional sbrk() and mmap() calls.

You missed the point

Posted Mar 28, 2008 3:45 UTC (Fri) by pflugstad (subscriber, #224) [Link]

Also, TCMalloc doesn't return memory to the kernel at all, while GNU libc's does.