Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdahl!nsc!stevew
From: stevew@nsc.nsc.com (Steve Wilson)
Newsgroups: comp.arch
Subject: Re: Memory latency / cacheing / scientific programs
Message-ID: <5206@nsc.nsc.com>
Date: 1 Jul 88 16:52:46 GMT
References: <243@granite.dec.com> <779@garth.UUCP> <2033@pt.cs.cmu.edu> <11023@ames.arc.nasa.gov> <8429@pur-ee.UUCP>
Reply-To: stevew@nsc.UUCP (Steve Wilson)
Organization: National Semiconductor, Sunnyvale
Lines: 24

In article <8429@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes:
>
>Registers are not a valid substitute for cache:  they are fundamentally more
>restricted in function (although they are efficiently managed at
>compile-time).  For example, both a[i] and a[j] can be kept in cache ad
>infinitum, however, if we (the compiler) don't know if i==j, we can't put
>either one in a register without having to flush both from registers every
>time either one is stored into.  It's the classic ambiguous alias problem.
>
I was always under the impression that a data cache wasn't a wonderful
idea for scientific applications.  Typical explanation being that if
the data set is larger than the cache, the data set will never reside
in the cache entirely, i.e. thrashing.  Previous discussions about
VM and scientific applications centered on this same type of problem
but from a different angle( the hardware structures are the same, just the 
names have been changed to protect the software ;-)

Given the alias problem and cache behaviour as well, is there a happy
medium?

Steve Wilson
National Semiconductor

[The above opinions are mine, so don't blame my employer.]