The reason to include it is that it would make integrating with batch
systems less of a headache for system administrators. Right now most
only support 1 MPI version because this is annoying.
Easy integration with a batch system would be a huge bonus. Also, the
ability to test a new revisio
On Fri, Mar 11, 2005 at 02:21:58PM +1100, Stuart Midgley wrote:
> One major implementation issue is the equivalent of mpirun (which I
> assume would be part of an ABI?) - or the startup requirements of
> different MPI's.
This may or may not be part of an ABI.
The reason to not include it is th
First, I think an ABI would be an excellent idea, if only for ease of
support on our systems. However, after a quick discussion with a
colleague, I have a few concerns.
One major implementation issue is the equivalent of mpirun (which I
assume would be part of an ABI?) - or the startup requi
On Thu, Mar 10, 2005 at 11:49:52AM -0500, Larry Stewart wrote:
> The presentation ignores the issue of instruction set. Even within
> the x86 family we have IA-32, EMT 64, and AMD-64.
Larry,
Thanks for sending some interesting comments.
The presentation wasn't intended to be all things to all
Toon Knapen wrote:
Greg Lindahl wrote:
http://www.openib.org/docs/oib_wkshp_022005/mpi-abi-pathscale-lindahl.pdf
mostly talks about why we need an ABI, who wins and loses as a result
of having one, and the pieces that could be in it. Please give it a
look.
The presentation ignores the issue
As posted on comp.parallel.mpi, I also wanted to forward this message to
us...@open-mpi.org because I think it is relavent to the (undoubtly
upcoming) mpich2 <-> open-mpi discussion.
Greg Lindahl wrote:
The first question is: Does an ABI provide enough benefit for people
to care?
I care a
