Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ames.arc.nasa.gov!lamaster From: lamaster@ames.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: How Caches Work Message-ID: <31814@ames.arc.nasa.gov> Date: 13 Sep 89 16:28:22 GMT References: <21936@cup.portal.com> <1082@cernvax.UUCP> <16306@watdragon.waterloo.edu> <8399@boring.cwi.nl> <3989@phri.UUCP> Sender: usenet@ames.arc.nasa.gov Organization: NASA - Ames Research Center Lines: 30 In article mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) writes: >Along a similar line, the Convex machines cache accesses going to the >scalar unit only. The load/store unit for the vector unit operates >directly from main memory to the vector registers. This is pretty >close to what Roy describes, but it is not controlled by any tags, >merely by which functional unit executes the load instruction. This is one of the advantages of having a vector instruction set, because this is *exactly* what is needed for programs of this type. This point is not always appreciated by systems people who are used to dealing with kernel code and utilities, so it is worth noting. You do *not* want to flush the cache by routing vector reads and writes through it. A typical code on getting 10-20 average MFLOPS on a machine with ~100 MBytes of real memory may easily chop though 25 MBytes on each time step, much bigger than *any* current cache. If you flush the cache, you slow down the intermixed scalar parts of the code. Instead, the vector read/writes can go directly to memory, with a bus watcher on the cache to update anything which happens to be in the cache. It may seem like a kludge to have the instruction used determine whether something is put in the cache or not, but there is actually a lot of information in the fact that the data is being accessed with a vector instruction. Unfortunately, it won't save you from flushing the cache occasionally when you have to do certain operations which won't vectorize. There is a considerable art to optimizing the CPU/memory interaction, just as there is to optimizing branch strategies, etc. 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