RE: [mpi-21] ABI - call for working group

["William Yu" <wyu@xxxxxxxxxx>]

But software like oracle do this all the time. A bit of it is always built during install time? Their customers dont seem to mind?

Of that is if the supported local mpi is supported and installed properly.
________________ Reply Header ________________
Subject:	RE: [mpi-21] ABI - call for working group
Author:	Edric Ellis <Edric.Ellis@xxxxxxxxxxxxxxx>
Date:		January 13th 2008 12:33 pm


> >To respond briefly to some of the other points raised in this thread
> >from the perspective of The MathWorks - yes, something like a "morph"
> >layer would be acceptable - but to be effective for our customers,
this
> >needs to be something that they have ready access to (i.e. they don't
> >need to build it, as I believe they would with the current MorphMPI
> >solution). Compatibility of mpirun/mpiexec would certainly be useful
for
> >our customers, but that's easier to work around since no
recompilation
> >is required.
> Since you're distributing your software in binary form, you would
> compile the morph layer yourself and distribute your software already
> pre-linked with it. The morph layer would then adapt to your local
> MPI when you install your software. At install time it would need to
> have enough information about the local MPI to be able to link to it
> but shouldn't need much more than that.

But surely the morph layer needs to be compiled against the local MPI? I
would much prefer a situation whereby my customers do not have to build
anything. By having a standard binary interface (which MPI
implementations are free to satisfy using the morph layer - and there
should still be an option to compile and link against the "native"
implementation to avoid any performance penalty in the morph layer),
there's nothing to compile. 

Cheers,

Edric.



From owner-mpifrm-mpi-21-outgoing@xxxxxxxxxxxxxxxxxxxxxxx  Sun Jan 13 09:02:10 2008
Return-Path: <owner-mpifrm-mpi-21-outgoing@xxxxxxxxxxxxxxxxxxxxxxx>
X-Original-To: mpifrm-mpi-21-outgoing@xxxxxxxxxxxxxxxxxxxxxxx
Delivered-To: mpifrm-mpi-21-outgoing@xxxxxxxxxxxxxxxxxxxxxxx
Received: from localhost (localhost [127.0.0.1])
	by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 7921A12E22
	for <mpifrm-mpi-21-outgoing@xxxxxxxxxxxxxxxxxxxxxxx>; Sun, 13 Jan 2008 09:02:09 -0600 (CST)
Received: by mailbouncer.mcs.anl.gov (Postfix, from userid 83)
	id DC0C412E00; Sun, 13 Jan 2008 09:02:08 -0600 (CST)
X-Original-To: mpifrm-mpi-21@xxxxxxxxxxxxxxxxxxxxxxx
Delivered-To: mpifrm-mpi-21@xxxxxxxxxxxxxxxxxxxxxxx
Received: from localhost (localhost [127.0.0.1])
	by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id E704C12E00
	for <mpifrm-mpi-21@xxxxxxxxxxxxxxxxxxxxxxx>; Sun, 13 Jan 2008 09:02:07 -0600 (CST)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179])
	by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 6F29812E1C
	for <mpi-21@xxxxxxxxxxxxx>; Sun, 13 Jan 2008 09:02:02 -0600 (CST)
Received: by wa-out-1112.google.com with SMTP id m34so3539463wag.9
        for <mpi-21@xxxxxxxxxxxxx>; Sun, 13 Jan 2008 07:02:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:from:reply-to:to:cc:subject:date:message-id:x-mailer:mime-version:content-language:content-type:content-transfer-encoding:sender;
        bh=6pM2IMFvBDAtkP1GPpNOHK/yi7K59skx9YoCp8stUxY=;
        b=DXQLMi9e1lOm+U8rkGHze4u0JTvrNw0ZH1KctSB325zT3zYu7g8CKCXamh36v2c2mTYOf0cK13zXxsShKVPZaAA03xn880IX1JPuC1LyXU+F2GAOuzImf0UsvG6o77JKmrsmJP3e2Jg8exClAjtXVbiuf5KN4KVo2Do+IcZ5RU8DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:reply-to:to:cc:subject:date:message-id:x-mailer:mime-version:content-language:content-type:content-transfer-encoding:sender;
        b=jK+AjaTaUac8BuDX1YU+IWn+YH0yrAdBHaxh7EGOy23FwGqTk8V3QShHObGKQsyZIbskTYb9Hh93ETcQwUHY2E8INuEfUaJrtigg81QsNbv/u/n3yxCFzYbL/wJ6uWT7sVQKcnmCdlmAWtZyyM3BrglpxjWVetyDDLfBFgMTP+kReceived: by 10.115.49.16 with SMTP id b16mr2050151wak.65.1200236519603;
        Sun, 13 Jan 2008 07:01:59 -0800 (PST)
Received: from ?192.168.1.18? ( [125.60.241.38])
        by mx.google.com with ESMTPS id f20sm13599206waf.56.2008.01.13.07.01.57
        (version=SSLv3 cipher=OTHER);
        Sun, 13 Jan 2008 07:01:59 -0800 (PST)
From: "William Yu" <wyu@xxxxxxxxxx>
To: mpi-21@xxxxxxxxxxxxx
Cc: mpi-21@xxxxxxxxxxxxx
Subject: RE: [mpi-21] ABI - call for working group
Date: Sun, 13 Jan 2008 23:02:11 +0800
Message-ID: <Vjd6FrZ9LcDB.jwnzpY5d@xxxxxxxxxxxxxx>
X-Mailer: EPOC Email Version 2.10
MIME-Version: 1.0
Content-Language: i-default
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov
Sender: owner-mpi-21@xxxxxxxxxxxxx
Precedence: bulk
Reply-To: mpi-21@xxxxxxxxxxxxx
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov


But software like oracle do this all the time. A bit of it is always built during install time? Their customers dont seem to mind?

Of that is if the supported local mpi is supported and installed properly.
________________ Reply Header ________________
Subject:	RE: [mpi-21] ABI - call for working group
Author:	Edric Ellis <Edric.Ellis@xxxxxxxxxxxxxxx>
Date:		January 13th 2008 12:33 pm


> >To respond briefly to some of the other points raised in this thread
> >from the perspective of The MathWorks - yes, something like a "morph"
> >layer would be acceptable - but to be effective for our customers,
this
> >needs to be something that they have ready access to (i.e. they don't
> >need to build it, as I believe they would with the current MorphMPI
> >solution). Compatibility of mpirun/mpiexec would certainly be useful
for
> >our customers, but that's easier to work around since no
recompilation
> >is required.
> Since you're distributing your software in binary form, you would
> compile the morph layer yourself and distribute your software already
> pre-linked with it. The morph layer would then adapt to your local
> MPI when you install your software. At install time it would need to
> have enough information about the local MPI to be able to link to it
> but shouldn't need much more than that.

But surely the morph layer needs to be compiled against the local MPI? I
would much prefer a situation whereby my customers do not have to build
anything. By having a standard binary interface (which MPI
implementations are free to satisfy using the morph layer - and there
should still be an option to compile and link against the "native"
implementation to avoid any performance penalty in the morph layer),
there's nothing to compile. 

Cheers,

Edric.