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

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]

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