Gee, this is the first time I can remember being called a rebel. And by a
man who himself is on the LAM :-) And on my 40th birthday, no less. Just
wait 'til I'm 60!
> Non-blocking operations, beginning in MPI-1 and culminating in
> generalized requests, are turning MPI into an operating system
> wanna-be. Synchronization and blocking processes are major parts
> of what an OS does. We want to wait on an arbitrary subset
> of communication events and preferably release the processor in
> the meantime. In MPI-2, we also include I/O devices. Oh, and
> because we want underlying progress, don't forget to watch all
> other outstanding requests at the same time. These things are
> best and most efficiently coordinated at the lowest level, the
> operating system that is fielding all the interrupts from the
> devices. But no OS lets the user tap into all of this in
> a completely flexible way [Win32 WaitForMultipleObjects() is more
> powerful than UNIX select(); let's require NT :-)]. So we decided
> to force all of this into MPI, at the cost of considerable complexity
> for both the user and the implementor.
I think this is an extremely important point, and one of the reasons that
I have begun proposing that CDS1 (or something like it) belongs in the OS.
(See my paper, and probably others, at the upcoming CANPC workshop in San
Antonio.) MPI, with its current size and complexity, is not a viable
candidate for kernel-level implementation, but if it were built in a layered
fashion, its lower levels might be. Still, the current MPI demonstrates the
kinds of functionality which it must be possible to build upon the OS layer,
whatever it is, and any standard API proposed today cannot count on
functionality that might not be in the OS until tomorrow.
(And MPI is certainly not alone in its creeping featurism leading to OS-like
powers. Have you seen Netscape lately?)
> Fortunately, the total lack of correct implementations has resulted
> in the acceptance of the weak interpretation of the progress rule.
> Otherwise, you would need to have or to build an OS to implement MPI
> - forget about lean, mean embedded implementations running with
> the interrupts turned off. But this has caused all sorts of agony
> in designing one-sided to be suitable to distributed memory machines.
> My wish, in hindsight, is that MPI_I*() only provided information
> to the implementation for possible overlapping or idle-consuming progress.
> There would be zero guarantee of progress until a Wait or Test was called.
> This would at least allow implementations to concentrate on the request
> array used in the Wait/Test call, and not the entire outstanding request list.
Yes, these are exactly some of the drawbacks I was alluding to when I said that
one-sided had suffered from the policy of basing MPI-2 on an unchanged MPI-1.
> tidbit MPI-2 feedback: I, like many, felt that dynamic processes were
> a major draw-back, marketing-wise, for MPI-1. As an (the only?) implementor
> of MPI-2 dynamic processes, I can report that we have had near-zero
> feedback on these functions, which leads me to believe that they are
> not being used very much. Maybe Marc's unconventional wisdom on this
> chapter will prove correct...
At some level, all processes on all machines could be considered to be dynamic
processes -- i.e. they weren't there, and then they were -- so I argue that
the basic functionality is indeed useful. So the question is: How many
restrictions can you place upon that basic functionality, with the goal of
making process creation and/or inter-process communication more efficient,
before users give up and find another way? I think that MPI should give us
simple dynamic processes, with few or no strings attached, or not bother.
(I'm not sure I've heard Marc's comments to which you refer.)
-Dave
========================================================================
David C. DiNucci | MRJ, Inc., Rsrch Scntst | NASA Ames Rsrch Ctr
dinucci@nas.nasa.gov| NAS (Num. Aerospace Sim.)| M/S T27A-2
(415)604-4430 | Parallel Tools Team | Moffett Field, CA 94035