Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!think!nike!aurora!jaw
From: jaw@aurora.UUCP (James A. Woods)
Newsgroups: net.arch
Subject: Re: Re: VERY LARGE main memories
Message-ID: <469@aurora.UUCP>
Date: Wed, 27-Aug-86 18:50:51 EDT
Article-I.D.: aurora.469
Posted: Wed Aug 27 18:50:51 1986
Date-Received: Fri, 29-Aug-86 01:19:59 EDT
References: <884@gilbbs.UUCP>
Organization: NASA Ames Research Center, Mt. View, Ca.
Lines: 29

# "what comes after silicon?  oh, gallium arsenide, i'd guess.
   and after that, there's a thing called indium phosphide." -- seymour cray
								circa 1980
tom keller wonders about the speed of gigabyte memories.

the cray 2 here has 1/2 gigabyte, with a worst-case cycle time of 57 clock
pulses (~234 nsec).  i doubt chip decoding delays take the bulk of this
time (logarithms don't grow fast); the sluggishness is more likely due to
the 2 using conservative (i.e. cheap) 256K dynamic mos technology.

things are a bit better with pseudo-banks (33 clocks/eight-byte word),
and strictly sequential access for vectors is designed to be fast 
(1.1 clocks/word).

but the memory speed for non-vectorized C code (e.g. any unix utility except
for 'cmp'), leaves a lot to be desired -- even with local variables in
fast registers ("local memory") [it would be nice to allow arrays here].

for "random stride" computation (unix kernel, compilers, utilities), 
the cray 2 is about the speed of a MIPS board.  indeed, d. ritchie
noted at the recent supercomputer conference held at nasa ames
that because of assembler code expansion risc-style (to ascii, yet),
the compile pipeline makes at&t's faster (scalar-wise) cray x-mp about the
speed of a high-end vax for such application.

if seymour ever hopes to regain the 'scalar' computing championship title,
he'd better get hip to a transparent data cache.

-- ames!aurora!jaw