🚀 go-pugleaf

In article <7766@thorin.cs.unc.edu> davis@cs.unc.edu (Mark Davis) writes:
>You can always improve bandwidth with silicon (and wires).  To double
>bandwidth, double the data bus size.
>
>On the other hand, latency (roughly the number of cycles to get the
>data after you figure out its address), is a much more difficult problem.
>Making the latency twice as good (50% as long) can be very tough.
>Mark (davis@cs.unc.edu or uunet!mcnc!davis)

One place where the distinction between latency and bandwidth shows up
very clearly is in the CDC/ETA line of supercomputers.  These machines
(the Cyber 205 and ETA-10) use a memory-to-memory vector architecture.

The machine being installed now at FSU (an ETA-10G) supports a
sustained bandwidth of 6.85 GByte/s from each CPU's 32 MByte (soon 128
MByte) local memory through the vector pipes and back to memory.  This
bandwidth consists of two 64-bit loads and one 64-bit store for each of
2 vector pipes on each CPU every 7 ns cycle. Total: 6 words/clock * 8
Bytes/word * 143 M clock/s = 6.85 GB/s.  I think that this memory is
implemented in 35 ns SRAM.  Latency on the 10.5ns machine is about 6-8
cycles, or 60-80 ns.  I don't know how this will scale with the faster
CPU's.

The second-level memory consists of 1 GByte of DRAM.  It has 8 ports 
capable of sustaining one 64-bit word/clock transfers. The aggregate 
transfer rate is thus 9.1 GByte/s. The hardware setup time for a transfer
is supposed to be about 256 cycles, but I don't know what fraction of this
is the actual memory latency.

Disclaimer: I don't work for CDC/ETA.  In fact, I don't work much at all....
-- 
----------------------   John D. McCalpin   ------------------------
Dept of Oceanography & Supercomputer Computations Research Institute
mccalpin@masig1.ocean.fsu.edu		mccalpin@nu.cs.fsu.edu
--------------------------------------------------------------------