Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Alliant/Intel PAX parallel computing standard
Message-ID: <6615@pt.cs.cmu.edu>
Date: 21 Oct 89 03:18:16 GMT
References: <23184@cup.portal.com>
Organization: Carnegie-Mellon University, CS/RI
Lines: 41


In article <23184@cup.portal.com> mslater@cup.portal.com 
	(Michael Z Slater) writes:
>Alliant Computer and Intel announced a deal earlier this week...
>Another key part of the deal is the establishment of the PAX (parallel
>architecture extension), to become part of a multiprocessor binary standard
>for i860-based machines.
>Does anyone think this is really significant?

That it's a standard? No. The Alliant compilers have to have some
sort of spec for their output. When new, improved chips arrive, it's
of course desirable that the spec not have to change. But if change
was per-se horrible, then Intel wouldn't have so many instruction
sets in its product line.

What IS significant, is the technical direction that this signals.
First, Alliant's compilers decide for themselves how to parallelize.
The programmer doesn't have to provide compiler directives. 

Second, it means that Intel intends for us to build gangs of 860's.
The Alliant scheme is based on the idea that typical code has nested
loops, with each iteration of the inner loop, separable from the
other iterations. So, there are N chunks of work, each chunk
containing a single loop. Alliant runs the N chunks on M processors,
M <= 8.  When a processor finishes a chunk, it obtains another: there
is an interprocessor bus for doling out the work. When all M
processors are out of work, M-1 of them become irrelevant, and 1 of
them continues forward through the serial program.

Note that memory is an interesting issue in such systems.

This is good stuff, but not unique. Cray has something similar called
"microtasking". The Cray wrinkle is that a process on one CPU can
have one ghost process on each of the other CPUs. When a CPU becomes
idle, the OS checks to see if the CPU has any ghost processes, whose
master processes (elsewhere) are now inside a nested loop.  In this
case, the OS fires up that ghost, which begins doing chunks of its
master's work.  Notice the neatness: the number of CPUs you get may
actually fluctuate!
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science