[Mpi-forum] MPI user survey

Tue Nov 17 10:16:21 CST 2009

No objections - let's go for 2 separate questions, e.g.:

"Do you want to achieve higher performance by disabling certain MPI-3 features in your program?
"If so, do you prefer subsetting or assertions?"

________________________________
From: mpi-forum-bounces at lists.mpi-forum.org [mailto:mpi-forum-bounces at lists.mpi-forum.org] On Behalf Of Richard Treumann
Sent: Tuesday, November 17, 2009 2:09 PM
To: Main MPI Forum mailing list
Subject: Re: [Mpi-forum] MPI user survey

I have serious doubts about the rationale forf doing a survey but if the Forum goes ahead, I would want these questions made distinct. Please do not put assertions and subsetting in the same question.

I think subsetting MPI is probably not useful. Too messy in so many ways. I would reply NO.

I think assertions are relatively clean and simple for both application writer and MPI implementor. Assertions address problems that will become serious at scale. They do provide a bit of a hurdle for authors of 3-party libraries but not a serious one. (explained below). I would reply YES

Dick

footnote re 3rd party libraries

If a legacy code version of a third party library depends on some guarantee provided by the MPI standard and the application author asserts that guarantee is not needed, there could be surprise results (perhaps wrong answers, more often error messages saying an assertion is violated) from the library. The transition problem is real.

New versions of the library can query whether there are assertions it cannot live with and give a clean error message. Something like "The use of assertion MPI_NO_CANCEL is not allowed when using Fredlib."

If certain assertions prove to be valuable because applications that use them either run faster or use less memory, the 3rd party library author may be pressured by customers to find a a way to make the library live within the assertions. This may be a bit of work for the library author but rejecting an MPI feature or a customer request that has significant value just because it would mean a bit of work does not deserve much sympathy.

If some assertion proves to have little or no value, the 3rd party library author can tell his customer that and and decline to rewrite the library to allow that assertion on a application that uses the library.

The middle ground in which the assertion has real payoff but the 3rd party library cannot reasonably live with it can be a marketing inconvenience for the library author but it is ultimately the customer's choice whether to remove the assertion or find a way to solve his problem without that library.

Dick Treumann - MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363

[cid:859011516 at 17112009-2827]"Supalov, Alexander" ---11/17/2009 02:10:36 AM---Dear Jeff, Please add, irrespective of the RMA aspect, the following question:

From:
"Supalov, Alexander" <alexander.supalov at intel.com>

To:
Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>

Date:
11/17/2009 02:10 AM

Subject:
Re: [Mpi-forum] MPI user survey

Sent by:
mpi-forum-bounces at lists.mpi-forum.org
________________________________

Dear Jeff,

Please add, irrespective of the RMA aspect, the following question:

"Do you want to achieve higher performance by disabling certain MPI-3 features in your program (thru subsetting, assertions, etc.)?"

Best regards.

Alexander

-----Original Message-----
From: mpi-forum-bounces at lists.mpi-forum.org [mailto:mpi-forum-bounces at lists.mpi-forum.org] On Behalf Of Jeff Squyres
Sent: Monday, November 16, 2009 7:36 PM
To: Main MPI Forum mailing list
Subject: Re: [Mpi-forum] MPI user survey

Folks --

Tel me exactly what to put on the survey.  :-)

On Nov 16, 2009, at 10:11 AM, Christian Bell wrote:

>
> On Nov 16, 2009, at 11:55 AM, Jeff Hammond wrote:
>
> > Can we completely ignore the performance-richness dichotomy and ask
> > the following?
> >
> > "Would you benefit if the MPI Forum enhances and extends the
> existing
> > one-sided operations?  That is, would you like to replace MPI
> > two-sided calls in your code with one-sided ones and/or use MPI
> > instead of another one-sided API (e.g. ARMCI)?"
>
> Why not be frank and to the point:
>
> The MPI Forum is currently investigating whether it is worthwhile
> supporting two RMA interfaces -- a feature-rich RMA interface and/or a
> performance-oriented interface with potentially more constraints.
>
> a) I only care about performance-oriented RMA
> b) I want RMA to implement a rich set of features at the cost of some
> performance/portability
> c) I think supporting 2 interfaces is a must because...
> [...]
>
> I won't elaborate more here because my slant against a feature-rich
> RMA will start showing (if it hasn't already).
>
>
> For the RMA folks:
>
> FWIW, I think a new feature-rich RMA just gives users more ways to
> write bad programs and hints at a performance benefit that
> implementations may never actually deliver.  An all-encompassing RMA
> interface is a noble goal but it doesn't seem compatible with all the
> specialization that needs to happen to exploit newer architectures.
> RMA will always be a form of specialization so it better come with a
> large carrot for users to consider it.  I'd rather have a skinny and
> constrained RMA interface that has a fighting chance to deliver what
> it aims to provide.  What's wrong with labeling a performance-oriented
> interface with "DEPRECATED: BAD IDEA" in 5 years if it will have
> failed?  IMHO, it's no worse than banking on a feature-rich RMA
> interface that may (yet again) drown in apathy.
>
> No disrespect is intended to those already working hard to come up
> with a complete feature-rich and performance-portable RMA, but I see
> too much pain for very little gain.
>
>         . . christian
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>

--
Jeff Squyres
jsquyres at cisco.com

_______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

_______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20091117/65f637cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: graycol.gif
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20091117/65f637cf/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: ecblank.gif
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20091117/65f637cf/attachment-0003.gif>