Re: Memory allocator performance in C/C++ compilers

"John S. Green" <johnsgreen@worldnet.att.net>
27 Jan 1999 12:18:20 -0500

          From comp.compilers

Related articles
Memory allocator performance in C/C++ compilers eem12@cornell.edu (ed mckenzie) (1999-01-22)
Re: Memory allocator performance in C/C++ compilers eodell@pobox.com (1999-01-25)
Re: Memory allocator performance in C/C++ compilers chase@world.std.com (David Chase) (1999-01-25)
Re: Memory allocator performance in C/C++ compilers vmakarov@cygnus.com (Vladimir Makarov) (1999-01-25)
Re: Memory allocator performance in C/C++ compilers eem12@cornell.edu (ed mckenzie) (1999-01-27)
Re: Memory allocator performance in C/C++ compilers johnsgreen@worldnet.att.net (John S. Green) (1999-01-27)
Re: Memory allocator performance in C/C++ compilers rosinowski@gmx.de (1999-01-27)
| List of all articles for this month |
From: "John S. Green" <johnsgreen@worldnet.att.net>
Newsgroups: comp.compilers
Date: 27 Jan 1999 12:18:20 -0500
Organization: EBSDCHT
References: 99-01-081 99-01-094
Keywords: performance

David is SPOT-ON. Microsoft's memory allocation algrithm is
nutoriously slow, but for good reason.


When the hardware matures at a rate of one generation every 18 months,
you can afford more overhead in things like memory allocation
algorithms.


Pentium III, on it's initial production run, will clock at 1/2
Gigahertz with potential to exceed multi-Gigahertz clock rates in
2001.


Consider this in light of the fact that Pipeline Burst Cache is
skin-tight against the processor running at CPU speed (not BUS speed).
Then back the whole schebang with over a GigaByte of RAM ($2,795) and
you have a screaming system that out performs yesteryear's RISC and
mainframe systems in spite of the inefficient memory allocation
algorithm in place at the Operating System (CRT not).


Now couple the aforementioned performance boosters with the massive
parallelism provided by the new generation of hardware and compiler
for NT/UNIX and you can effectively process information through the
transputer speed range at significantly less cost and with one, two,
four, or eight CPUs instead of several hundred transputer circuits.


Again, David is SPOT-ON.


Ciao'
John Green
http://home.att.net/~johnsgreen
johnsgreen@worldnet.att.net
http://home.att.net/~enterprisesystems


==


David Chase wrote in message 99-01-094...


> [ A 1977 article explained in detail how to write fast memory allocators ]


[This attitude is absurd. As David pointed out, we've known for over
two decades how to write fast memory allocators, and there's no excuse
for botching an essential routine used in nearly every C program. Do
keep in mind that the original question was why a program was so slow.
-John]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.