Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!tnc!m0154
From: m0154@tnc.UUCP (GUY GARNETT)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: A3000 CPU Wars!!
Message-ID: <831@tnc.UUCP>
Date: 6 Jun 91 12:53:57 GMT
References: <16888@helios.TAMU.EDU> <1991Jun5.060518.9683@news.iastate.edu> <1991Jun5.072620.18879@mintaka.lcs.mit.edu>
Reply-To: m0154@tnc.UUCP (GUY GARNETT)
Organization: The Next Challenge, Fairfax, Va.
Lines: 60


[re: Multiprocessing]

There are two factors which cause a multiple processor computing
system to show diminishing returns (instead of adding up processor
power linearly as you add processors).  One is the communications
overhead: in order for more than one processor to work on a problem,
both processors involved must spend some time communicating with each
other (passing partial results, status information, or whatever)
rather than directly working on the problem.  The other, which occurs
when the processors share a bus, memory, or communications subsystem,
is contention: when one processor is on the bus (or using the memory,
or sending data) the other processors cannot use that resource.  If
the resource involved is memory the problem is particularly acute; the
other processors can't get new instructions or data until the bus or
memory is free again.

The first bottleneck can be addressed by arranging the processors in a
"topology" (connecting them in a certain order or array) which is
suited to the problem being computed.  A snag is that there is no one
topology which is optimal for all problems.

The second bottleneck can be addressed by larger and smarter caches on
each processor, or by giving each processor its own, independent
memory and bus.

The Transputer is an interesting attempt at proposing a solution to
these problems.  It is a small RISC CPU, which can control its own,
local memory bus.  Each one also has 4 high-speed serial links for
communicating with other transputers.  The serial links are DMA
driven, and require very minimal processor overhead.  Since the links
are a single serial line, it is easy to use a plugboard or a
programmable switching array to change the topology of the transputer
array to suit the problem at hand.  Transputers also come with a
special programming language, Occam, which is supposed to make it easy
to program an application for parallel processing.  Transputer C and
FORTRAN compilers emit Occam code.

For something closer to an Amiga owner's heart, the 68040 is, at least
in theory, quite capable of operating in a multiprocessor environment,
especially with other 68040s.  The large cache means that several
processors could share memory, with a relatively low amount of
contention (only when the cache missed would the processor need the
memory subsystem: hopefully less than 20% of the time, if Motorolla is
to be believed).  In theory, a version of the Amiga OS could be
constructed to work with an arbitrary number of processors, but such
an operating system would only work on 68030 and 68040 systems.  Hmmm,
v3 or v4 anyone?

For another interesting thought:  While it is not possible to run
the Amiga OS as a task under UNIX (Amiga OS is a real-time system
while UNIX is not), it might be possible to run UNIX under the Amiga
OS.  The UNIX would have to have kernel modifications to operate
correctly, but it could allocate RAM from the Amiga OS, and then use
the MMU to map it for UNIX operation.  The UNIX file system could be
directed into an ASSIGNed logical device (UNIXFS:) and the swap space
to another (UNIXSW:).  How about it?

Wildstar
"Any lesser duck would have given up by now!" -- D.Duck