Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!ccncsu!bizet.CS.ColoState.Edu!rro
From: rro@bizet.CS.ColoState.Edu (Rod Oldehoeft)
Newsgroups: comp.sys.sequent
Subject: Re: What?  I'm confused. Sequent their strengths & weaknesses
Message-ID: <2545@ccncsu.ColoState.EDU>
Date: 9 Sep 89 14:45:00 GMT
References: <1263@syma.sussex.ac.uk> <1309@syma.sussex.ac.uk> <218@runxtsa.runx.oz> <17580@bellcore.bellcore.com> <5053@eos.UUCP> <11500@boulder.Colorado.EDU>
Sender: news@ccncsu.ColoState.EDU
Reply-To: rro@bizet.CS.ColoState.Edu.UUCP (Rod Oldehoeft)
Organization: /etc/organization
Lines: 45

In article <11500@boulder.Colorado.EDU> rsk@boulder.Colorado.EDU (Rich Kulawiec) writes:
>In article <5053@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:
>>In article <17580@bellcore.bellcore.com> johno@dduck.UUCP (John OBrien) writes:
>>>The sequent architecture does automatic multiprocessing
>>across the available processors.
>>>The "Parallel Processing" is not done automatically!
>>
>>Oh?      What's the difference?  [*if you think this terminology is bad,
>>I can refer you to other vendors with bad terminology...*]
>
>Here's the deal:
>
>If you and I each launch a dozen processes or so on a ten processor
>machine, the kernel scheduler worries about which to run where, and
>silently handles getting our 24 jobs done on 10 processors.
>
>However, if I want to run a DSP application in parallel on 4 processors,
>then I have to embed the appropriate parallel directives in my code
>at compile-time, ie. the compilers won't generate parallel code for me.
>
>---Rsk

And, if you and I each launch a parallelized application involving 10
processes on a 16 processor machine, the scheduler does _not_ assure
that either all my processes or all your processes are running.  In
this situation a process can spend an entire time slice waiting busily
for a lock to clear while the process that could clear it is not
occupying a processor.  This leads to poor and erratic performance.

But wait, Sequent provides the capability for tacking a process to a
processor (preempted by only a few system activities), thereby
improving single-application performance (and making it repeatable).
This is called "processor affinity."

At LLNL software was developed in 1986-87 that scheduled "gangs" of processes
together, preempting entire gangs when a new gang appeared or when
a looooong time slice elapsed.  This is a very nice approach if
generalized to schedule more than one gang when possible.  Sequent
spoke of doing this, but I know nothing of the status of this thing.


Rod Oldehoeft                    Email: rro@CS.ColoState.EDU
Computer Science Department      Voice: 303/491-5792
Colorado State University        Fax:   303/491-2293
Fort Collins, CO  80523