Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ames!ames.arc.nasa.gov!lamaster From: lamaster@ames.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: How Caches Work Message-ID: <31880@ames.arc.nasa.gov> Date: 14 Sep 89 19:57:10 GMT References: <21936@cup.portal.com> <1082@cernvax.UUCP> <16306@watdragon.waterloo.edu> <8399@boring.cwi.nl> <3989@phri.UUCP> <31814@ames.arc.nasa.gov> <1029@m3.mfci.UUCP> Sender: usenet@ames.arc.nasa.gov Organization: NASA - Ames Research Center Lines: 22 In article <1029@m3.mfci.UUCP> rodman@mfci.UUCP (Paul Rodman) writes: >In article <31814@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >>a vector instruction set, because this is *exactly* what is needed for >What you should have said is: "This is one of the advantages of having >control over whether or not to bypass the cache". A vector instruction >set gives a pretty coarse method of making the choice. You are right. I should have noticed that the terms of the debate have changed during the last year from: "Nobody runs applications like that" to "What is the optimal way to support calculations involving large arrays of floating point variables?" Needless to say I am pleased. I am now hoping that fast multiport memory subsystems will become the next thing which we didn't need, but which we now can't live without. Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117