Re: multi/tasking/processing
- To: MISC
- Subject: Re: multi/tasking/processing
- From: Penio Penev <penev>
- Date: Wed, 16 Aug 1995 14:00:01 -0400 (EDT)
- In-Reply-To: <9508160852.AA16291@lully.inria.fr>
On Wed, 16 Aug 1995, Christophe Lavarenne wrote:
> I agree with Penio Penev that:
> > one is much better off with total control over all of the silicon ...
>
> But his following argument is worth a comment:
> > On the other hand, big states (register files) are not good for
> > multitasking, since _all of them_ need to be swapped to/from memory
> > _every_ context switch. (Don't tell me, that having _only_ two tasks is
> > adequate for a multitasking machine.)
>
> You are right for monoprocessor multipurpose desktop workstations.
>
> For multiprocessor real-time embedded machines, I would rather say that the
> most efficient use of hardware is only one task per instruction sequencer, to
> avoid the overhead of context switches.
>
> On a multi-F21, there are several instruction sequencers.
> Even on a single F21, there are several instruction-sequencers:
My argument was much more trivial than that. If we have three tasks (in
one group) and we have two state containers (register files), this doesn't
buy us anything, since we have to swap the containers with permanent
storage each time we make a switch.
On the other hand, having two small containers versus one larger (or
versus price, heat, etc. penalties) limits the amount of work each single
task can do, while it has access to the shared resources (ALU, instruction
sequencer, etc.)
Now forth to the philosophical topic:
> Briefly, there are several ways to implement parallelism, the most general one
> (pseudo-parallelism with context switches) being the less effective, and the
> most specific one (matching the _available_ parallelism of the target
> architecture) being the most efficient.
The ultimate efficiency is, as you say, to have one sequencer/task, and
that sequencer to be optimized for the task. The ultimate system would
have the ability to add sequencers in a very fine-grain manner, and add
(slightly) differently tailored sequencers for (slightly) different tasks.
The communication bandwidth has to scale with the number of sequencers
(actually with the communication needs of the task at hand).
Does this start to sound familiar to the neuro-geeks in the gang?
--
Penio Penev <Penev@venezia.Rockefeller.edu> 1-212-327-7423