Newsgroups: comp.parallel.mpi
From: tony@aurora.cs.msstate.edu (Tony Skjellum)
Subject: Re: mpi availability & performance
Organization: Mississippi State University
Date: 19 May 1995 19:05:18 GMT
Message-ID: <3piq5e$4aa@NNTP.MsState.Edu>

First, in regards realtime extensions, if you are interested in the
next informal meeting of MPI realtime group at MPI Meeting, it will
be either June 5 or June 6, at Chicago O'Hare.  We need to use a free
breakout room of the MPI meeting, and we may not decide on this till
the meeting starts.  I am soliciting interest from people to start
working on the realtime issues in earnest.  


CampbellM (campbellm@aol.com) wrote:
: I have been trying to determine if mpi is (or willbe) appropriate for
: high-throughput
: real-world real-time systems.  This determination includes availability
: and performance.

: 1. What platforms is mpi *currently* available on?
We know that there are many MPI's around.  The key ones are as follows:
	LAM - for clusters, not emphasizing performance but rather environment for
		development
	MPICH - Argonne/MSU, runs on T3D, Paragon, iPSC860, SGI multiprocessors,
			SP-2, SP-1, clusters (Sun, HP, etc), clusters with Myrinet,
			Convex, PVP's from Cray, etc.
	CHIMP/MPI - T3D, and probably others.
Both MPICH and CHIMP are aimed at high performance.

: 2. For *existing* mpi implementations:
:     a)  What is the non-blocked node-to-node set-up time?
:     b)  What is the non-blocked node-to-node communication time and
: bandwidth
:          as a function of message length?
:     c)  What is the non-blocked node-to-node communication time and
: bandwidth using 
:          the best available native communications?
:     d)  What is the peak/theoretical bandwidth & latency?

It is not easy to answer this question without some length and without
a lot of graphs.  I think that our forthcoming paper on MPICH will show
the performance on a number of platforms.  I can tell you that the
latency/bandwidth numbers are quite competitive or better than internal
general message passing systems when optimization is possible on a
given platform.  Our initial layered implementations are not quite so
strong, but they are being replaced, especially as vendors give more
help or start doing the task themselves.

Further experience from vendors is that high bandwidth, low latency
implementations of the MPICH device work quite well.  Nay sayers who
have shared memory should talk to SGI about their excellent results
with the power challenge (585mbyte/second bandwidth, approx. 10us latency,
data left in cache of destination process).

: 3. What is the *planned* availability and *expected* performance of future
: upcoming
: mpi implementations?
This is kind of vague to say the least.  We are running on clusters, all
general purpose parallel machines and clusters, and some not-so-well-known
machines.  As you know, even some embedded boards have MPI on them already.

The investment in highly optimized implementations will be driven by demand.
So far, MPICH is addressing performance enhancements more than new implementations
as its major emphasis.


: Answers sent to me will be collected and posted.

: Thanks,

: Marc Campbell
: Northrop Grumman
: campbellm@aol.com

--
Anthony Skjellum, Asst. Professor, MSU/CS/ERC, Ph: (601)325-8435; FAX: (601)325-8997.
Mosaic: http://www.erc.msstate.edu/~tony; e-mail: tony@cs.msstate.edu
Maxim:  "There is no lifeguard at the gene pool." - C. H. Baldwin
	.	.	.	.	.	.	.	.      .      .
Mosaic info on applying to MSU: see http://msuinfo.ur.msstate.edu/prospect.htm (not html)
	.	.	.	.	.	.	.	.      .      .

