NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/next/advocacy/3508

Text File | 1992-12-30 | 1.6 KB | 32 lines

Newsgroups: comp.sys.next.advocacy
Path: sparky!uunet!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!zaphod.mps.ohio-state.edu!rpi!usc!enterpoop.mit.edu!thunder.mcrcim.mcgill.edu!sifon!charnel!rat!zeus!
From: [e-mail] (Mark Neidengard)
Subject: Re: 100 Mips Intel NeXT (processor comparison)
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Academic Computing Services, Cal Poly San Luis Obispo
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 31 Dec 1992 01:31:41 GMT
Lines: 20

I think that the way of getting around this bottleneck is to use EXTENSIVE
caching with sophisticated read-ahead logic.  I figure that a 200 MHz
processor like the Alpha should be mated with 5 ns RAM in order to do "hot
cycle" memory access, which is a practical impossibility.  So, like everyone
else, they have waitstates and attempts at caching.  And the Alpha is only
the tip of the iceberg.  If you got a chip that executes a lot of
instructions at once (say, three or more in parallel sustained), just
trying to keep the instruction prefetch pipelines filled would require more
throughput than the memory bus could handle.  The only solution will have to
be making faster memory, and caching to a farethewell until then.

Don't be surprised if CPU's start coming out with 1 meg of onboard cache
within the next year...

Mark Neidengard
[e-mail]
"You gotta concentrate on the mission you be takin'.
 It's not so much the mission, but you got crazy ignition!"
           A Tribe Called Quest