Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.arch
Subject: Re: Cache Size
Summary: sometimes big, sometimes small
Keywords: garbage collection, locality of reference, cache size
Message-ID: <8189@pt.cs.cmu.edu>
Date: 27 Feb 90 12:09:18 GMT
References: <7393@pdn.paradyne.com> <76700146@p.cs.uiuc.edu> <1990Feb26.022057.28461@Neon.Stanford.EDU>
Organization: Carnegie-Mellon University, CS/RI
Lines: 29

In article <1990Feb26.022057.28461@Neon.Stanford.EDU>, wilson@carcoar.Stanford.EDU (Paul Wilson) writes:
> Garbage collected languages have similar characteristics.  If you
> use a generational garbage collector, you may be able to fit the
> youngest generation entirely in the cache.  But for it to be 
> worthwhile, you want a fairly big cache.
> ...

My thesis work showed that functional programming languages that
use combinator graph reduction have many unexpected characteristics
when using cache.  They all seem to make excellent use of even very
small caches of a few Kbytes.

On the other hand, scientific/engineering number-crunching is
notorious for breaking caches.  Any time the numeric arrays
you are operating on get substantially bigger than the cache size,
you end up heading towards a 0% hit rate.  And, for any cache size
you can *always* find someone who wants to use an array bigger
than you can handle.  Yes, block-manipulation techniques can help,
but they are a hack to get around this basic problem -- and are
just about as effective with smaller, cheaper vector register files.
So, that's why most supercomputers seem to use vector register
files instead of caches for their vector units.

  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
Senior Scientist at Harris Semiconductor, adjunct professor at CMU.
I don't speak for them, and they don't speak for me.