Subject: static process subset?

From: [email-masked]
Date: Fri, 5 Mar 93 17:36:39 PST

Al Geist writes:

> Just a point of fact: we just got through testing a fully dynamic model
> on the Intel i860. It is a part of the PVM 3.0 software.

Great!  

Can you share with us how you did it, and what is the performance of
the communications between dynamically allocated processes on two
i860 nodes?

I have visions of layers of daemons (like my tongue-in-cheek
description of how to do dynamic processes on the Delta), 
but then I'm a notorious skeptic.

> I think your phrasing is ment to sway the reader to vote a particular way
> (your way of course) 

This strikes me as a personal attack, although of course I have no
idea how it was intended.  I will resist responding other than to ask,
we can focus on the technical issues?

> We shouldn't loose track of the fact that
> a static model is just a subset of the dynamic model.
> There is no such thing as ONLY a dynamic model.

Here's an example of what I mean by "supporting ONLY a dynamic model".

Suppose we define an interface that says the only way to get P
processes running is to write code that says

   for (i=1; i<P; i++) 
     tid[i] = MPI_create_new_process (nodename,exefilename);

Does this support static processes?

Sure, the MPI spec could say something like "in an environment that
supports only static process creation, the nodename and exefilename
are ignored, and P must equal the number of processes that were
statically created".  But this strikes me as introducing a pretty
large gap between syntax and semantics.

There may be interface definitions that provide equally good support
for both models, in which case I would be delighted to have only one.

> I can not argue that a static model should not be supported.
> This is not the debate. The issue is should we limit MPI
> to a static model (We haven't even voted to have process creation
> of any kind yet) given that a more flexible model interface
> already exists (PVM and others) 

Perhaps this is an area where MPI needs to have a defined subset.

I think it is important that implementations can call themselves
"MPI-compliant" without having dynamic process creation.

I also think that the MPI interfaces should be defined such that
static process creation is cleanly supported.

At the same time, I agree that dynamic process models are important.

I would NOT vote to restrict the design of MPI to a static process
model, in the sense of defining fundamental features that are not
compatible with dynamic processes.  For this reason, I prefer process
ID's to be opaque types rather than sequential integers.

I might however vote to do only static now because of time constraints.
This is a question of priority.

My personal top priority is getting pt-pt and group/context/topology
definitions such that rock-solid libraries can be written that will
run fast at least in static process environments.  Even that much
seems to be taking a gosh-awful long time.

Dynamic processes would probably be my second priority.  

Given the current schedule and rate of progress, I don't think I need
a third (low) priority.  

However, (to switch topics a bit) if I did need to name low priority
stuff, then certainly figuring out how to implement multiple
non-blocking scatter-gather operations on overlapping groups would
fall someplace below third.  That stuff sounds great for an
application, but it's the devil's own time to implement correctly,
even given a good definition.  So that stuff scares me -- I'm afraid
that if we require it, NOBODY will have a compliant implementation.
Does anybody else worry about this?

> Al Geist

--Rik Littlefield