Path: utzoo!attcan!uunet!mcsun!cernvax!hjm
From: hjm@cernvax.UUCP (Hubert Matthews)
Newsgroups: comp.arch
Subject: Re: SRAM vs. DRAM, 33MHz 386 UNIX-PC
Message-ID: <1083@cernvax.UUCP>
Date: 10 Sep 89 18:21:10 GMT
References: <21936@cup.portal.com> <1082@cernvax.UUCP> <3934@hplabsz.HPL.HP.COM>
Reply-To: hjm@cernvax.UUCP (Hubert Matthews)
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland
Lines: 31

In article <3934@hplabsz.HPL.HP.COM> kleinman@hplabs.hp.com (Bruce Kleinman) writes:
>[...I said that data caches aren't any good for long loops...]
>Unless your d-cache line size is wider than a word, and performs
>burst refills from main memory.

But I can always find some access pattern that makes a data cache
ineffective.  For instance, if the line size of the cache is N bytes,
then fetching data separated by >= N bytes renders the cache useless.
And unless you have a processor capable of streaming from the cache
(executing the instruction which started the data fetch whilst the
following bytes of the cache line are arriving), the cache prefetch
will slow things down in this case.  On top of this, there is the
problem of stomping all over the cache so the effects of the loops are
felt for some time after it has ended.

Caches are effective for certain, albeit common, access patterns.  But
if the software you run doesn't conform to these patterns, then you
are stuck.  All you can do is get faster memory or wait for the
program to finish.

>Bruce "and why would anyone be running FORTRAN code on a PC :-)" Kleinman

If the "FORTRAN code" has long arrays in it like the above examples
(not untypical of scientific code), then you need a machine with
faster main memory to get any decent performance out of your '386,
which is, I believe, where this whole thread of discussion started.

-- 
Hubert Matthews      ...helping make the world a quote-free zone...

hjm@cernvax.cern.ch   hjm@vxomeg.decnet.cern.ch    ...!mcvax!cernvax!hjm