[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan mee ting
- To: mpi-21@xxxxxxxxxxxxx
- Subject: RE: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan mee ting
- From: "William Yu" <wyu@xxxxxxxxxx>
- Date: Mon, 3 Dec 2007 21:57:43 +0800
- Delivered-to: mpifrm-mpi-21-outgoing@mailbouncer.mcs.anl.gov
- Delivered-to: mpifrm-mpi-21@mailbouncer.mcs.anl.gov
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date:message-id:x-mailer:mime-version:content-language:content-type:content-transfer-encoding:sender; bh=EgtBzRYSt9mZUwCPPipU2ezl964rFJ60obf2ACXnVv0=; b=hPKPn1qqlQK6TlYsIF33wUL7oBv2jxUIQSD4u5UgYB3ok6tGfpFPo76EmEjaK/MhbvQ0RqK6bJkFKM1BAqJkPAK5LdA9vDsQGZ7NFzyBqLwNcFwlE/U2e5nwRKZFvpK7EaBUgFYbUhcLC/5ZquZrsgGtpTdyRGJ67vZkq1CrVDk=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:reply-to:to:subject:date:message-id:x-mailer:mime-version:content-language:content-type:content-transfer-encoding:sender; b=JZ+Tkz6gVxe8B/vKrJvSvt6DBscQtT2e4mf8gcx0Fc3oQhgQuMTVBHGUJs8Ec7wcZYG4TV2FVzzNRQXz8FG2yEKs+MfFVShb7KBg44TFa0Zgs2E1hKdkGng1yFx1gFhmRkKiCZEAYV44p/bIM+ndBo3AbXRn7XqFf8k2ml+e6aY=
- Reply-to: mpi-21@xxxxxxxxxxxxx
- Sender: owner-mpi-21@xxxxxxxxxxxxx
Right. A unified way of doing input/output redirection would be nice. Maybe something like bcast? MPI_Printf()? MPI_Signal()?
But i guess these things are MPI 3 items?
________________ Reply Header ________________
Subject: RE: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan meeting
Author: Ashley Pittman <apittman@xxxxxxxxxxxxxxxxxxxxxxx>
Date: December 03rd 2007 1:39 pm
On Mon, 2007-12-03 at 11:05 +0000, Supalov, Alexander wrote:
> Having a common ABI and still behaving
> differently on some applications won't help customers move between MPI
> implementations, which is a common ABI is primarily intended for.
It's perfectly normal for different MPI implementations to work within
the spec but still exhibit different behaviour and expose different bugs
in applications, a ABI won't help here.
> By the
> way, the ABI extends beyond the function interface - it includes library
> naming, process startup, etc.
This is at least as difficult as a common function interface in my view
and whilst worth discussing I'm of the opinion that it's a different
issue and hence should be a different topic of discussion.
To the non-functional interface I should probably add output/input
redirection, signal handling, error teardown protocol and exit codes.
Ashley,