🚀 go-pugleaf

In article <7369@thor.acc.stolaf.edu> mike@thor.stolaf.edu () writes:
>In article <1081@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes:
>>I take my hat off to them, too, because that's no mean feat.  But don't
>>forget that the supercomputers didn't set out to be the fastest machines
>>on scalar code.  If they had, they'd all have data caches, non-interleaved
>>main memory, and no vector facilities.  What the supercomputer designers
>
>Excuse me, non-interleaved main memory?  I've always assumed that
>interleaved memory could help scalar code too.  After all, instruction
>fetch tends to take place from successive addresses.  Of course if
>main memory is very fast there is no point to interleaving it, but
>if all you've got is drams with slow cycle times, I would expect
>that interleaving them would benefit even straight scalar code.

I meant that as a shorthand way of putting across the idea that the usual
compromise is one of memory size, memory bandwidth, and memory latency.
For the canonical scalar code you don't need a very large memory, and
the bandwidth may not be as important to you as the latency (pointer
chasing is an example).

The point I was making was that the supercomputers have incorporated
design decisions, such as very large physical memory, and very high
bandwidth to and from that memory, so that their multiple functional
units can be kept usefully busy while executing 'parallel' code.  Were
you to set out to design a machine which didn't (or couldn't) use those
multiple buses (pin limits on a single-chip micro for instance) then
that bandwidth isn't worth as much to you and you might be better off
with a flat, fast memory, which is what most workstations do (or used
to do, anyway).

Bob Colwell               ..!uunet!mfci!colwell
Multiflow Computer     or colwell@multiflow.com
31 Business Park Dr.
Branford, CT 06405     203-488-6090