Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!stanford.edu!agate!sprite.Berkeley.EDU!elm
From: elm@sprite.Berkeley.EDU (ethan miller)
Newsgroups: comp.arch
Subject: Re: Memory hierarchies
Message-ID: <1991May8.005626.2312@agate.berkeley.edu>
Date: 8 May 91 00:56:26 GMT
References: <1991May2.162909.9165@news.arc.nasa.gov> <819@cadlab.sublink.ORG> <1991May7.061500.7485@marlin.jcu.edu.au> <1991May7.152224.3146@rice.edu>
Sender: root@agate.berkeley.edu (Charlie Root)
Organization: utter chaos
Lines: 42

In article <1991May7.152224.3146@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes:
%The reality of big systems is that they are implemented with a
%memory hierarchy.  Typically
%
%	registers
%	cache
%	tlb
%	ram
%	disk

Actually, *really* big systems look something like this:

registers
(cache)
ram
solid-state disk
fast disk
(slower disk)
tape

The slower disk might be there just as a speed-matching buffer for the
tape.  Cache may or may not exist.  Instruction caches (or instruction
buffers) are everywhere.  For scientific computing, though, a data cache
often isn't much good.  Most Cray sites look like the above list,
without cache or "slower disk."

%but the hierarchy still exists.  A fair amount of the money spent
%on a super is dedicated toward flattening the hierarchy.

Most of the money spent on a super goes towards making a memory system
that can sustain gigabyte/second transfer rates.  We know how to compute
at gigaflop speed.  Just throw together 100 of your favorite math
coprocessor which can do 10 MFLOPS.  This should cost you at most $200K.
The rest of the cost is building a memory system which can support
the high data rates these 100 processors can sustain.

ethan
-- 
=====================================
ethan miller--cs grad student   elm@cs.berkeley.edu
#include <std/disclaimer.h>     {...}!ucbvax!cs.berkeley.edu!elm
This signature will self-destruct in 5 seconds....