garbage-collecting VMs
Posted Feb 28, 2007 7:53 UTC (Wed) by
ldo (subscriber, #40946)
In reply to:
garbage-collecting VMs by flewellyn
Parent article:
Ruby Performance (Linux Journal)
Actually, people have been saying "Eww, GC = slow" for decades, despite huge amounts of research and development into making GCs faster and more robust.
The problem is, even while the software continues to improve the locality of reference of garbage collectors, the hardware continues to increase the cost of violating locality of reference. CPU speeds continue to increase much faster than RAM speeds. Which is why you have L1 and L2 caches (and sometimes even L3 ones) to bridge the gap. As the gap widens, so does the cost of crossing it.
It's been about half a century since the concepts of machine-independent languages and garbage collection were invented; the first one is pretty much universally taken for granted these days, the second one is not. This even though processor speeds have improved by something like five orders of magnitude over that time; everybody now accepts that you should write your code in machine-independent languages (even for something as machine-dependent as the Linux kernel!), but garbage collection is still too expensive for many uses, and will probably remain that way forever.
(
Log in to post comments)