[Mpi-forum] MPI user survey
Richard Treumann
treumann at us.ibm.com
Mon Nov 16 07:15:24 CST 2009
I did not see this until Monday morning but here are some late comments.
Dick
How do you plan to give a reasonable range of stake holders a chance to
understand the questions and provide their answers?
ISVs or "closed source product" providers should be queried. They need to
deal with their customers who are delivered an MPI 3
Buyers of closed source products are stake holders in this issue. If I am
using an MPI based product in my business, how do I feel about needing to
buy and validate new software when my MPI provider says his new release
breaks my production software?
Providers of MPI implementations may want to think about the implications
of an influential customer saying "Ship MPI 3 if you want to but to keep my
business you must also keep shipping and supporting the MPI 2.2 that my
apps still use.
Typical number of tasks in an MPI job may not be very informative. The
question should (also?) try to get at:
1) What is the largest job you tend run today and consider important (vs
something run but not critical to the mission / business)
2) What number of tasks do you anticipate wanting to run (and consider
important) within the next few years?
I do not see anything clearly addressing the question of "How many cores.
CPUs. PEs (whatever term) would you hope/expect to be able to apply to your
largest problems?" Much of the hybrid discussion is about solving problems
with so many PEs that MPI cannot scale to enough tasks. It seems likely to
me that someone may want to use a million processing elements and that MPI
will never scale well to a million tasks.
I assume question with the check boxes is asking about "error handlers".
It refers to "error handles"
http://mpi-forum.questionpro.com/akira/TakeSurvey;jsessionid=dcaTO_iOlMbIqcQeW98ts
I do not know what this question means.
MPI one-sided communication performance is more important to me than
supporting a rich remote memory access (RMA) feature set.
Having been involved in several email discussions and knowing what is being
pressed, I can guess the desired answer. We cannot legitimately make
decisions based on such an ambiguous question: What expectations of typical
MPI communication are included in "rich"? Is using any communicator except
MPI_COMM_WORLD part of "rich"? Is getting a non-MPI_SUCCESS return code for
an error part of rich?
"MPI application control of fault tolerance" -- sounds too easy. Who would
say no? I would be happy to have MPI_Tolerate_faults( yes | no)
It would be helpful to be able to read the survey questions before starting
to answer. I personally dislike answering a survey question without
knowing what all the questions are. I must try to pick the best answer
even though the question does not really fit my concern or I must ignore
my concern on the assumption a better targeted question must be on the
survey. (I cannot count the number of times I have started to answer a
telephone survey only to say in the middle "We're done" because I have
deduced the survey questions will not really help capture my views")
Dick
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
From: Jeff Squyres <jsquyres at cisco.com>
To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
Date: 11/14/2009 08:12 PM
Subject: Re: [Mpi-forum] MPI user survey
Sent by: mpi-forum-bounces at lists.mpi-forum.org
Actually, when we put the questions in the survey web site, they came
out slightly differently. Have a look here:
http://mpi-forum.questionpro.com/
*** DO NOT GIVE THIS URL OUT TO USERS YET! ***
Feel free to fill out the survey; we'll be clearing all the data on
Monday evening so that it can "go live".
On Nov 14, 2009, at 4:08 PM, Jeff Squyres (jsquyres) wrote:
> Forum -- here's the questions that I took down on Friday morning.
> Josh Hursey and I cleaned them up quite a bit, and we grabbed Bill
> Gropp for 5 minutes on Saturday to give us a bit of spot feedback.
> Here's the results.
>
> *** Please send comments by Monday evening so that we can get these
> posted on a web site. Thanks.
>
> ------------------------
> x. Which of the following best describes you?
> - User of MPI applications
> - MPI application developer
> - MPI implementer
> - Academic educator, student, or researcher
> - Program / project management
> - Other ________________
>
> x. Rate your familiarity with the MPI standard?
> - 1/not familiar at all ... 5/extremely familiar
>
> x. Think of an MPI application that you run frequently. What is the
> typical number of MPI processes per job that you run? (select all
> that apply)
> - 1-16 MPI processes
> - 17-64 MPI processes
> - 65-512 MPI processes
> - 513-2048 MPI processes
> - 2049 MPI processes or more
> - I don't know
>
> x. Using the same MPI application from #3, what is the typical number
> of MPI processes that you run per node? (select all that apply)
> - 1 MPI process
> - 2-3 MPI processes
> - 4-7 MPI processes
> - 8-15 MPI processes
> - 16 MPI processes or more
> - I don't know
>
> x. Using the same application from #3, is it a 32 or 64 bit
> application?
> (select all that apply)
> - 32 bit
> - 64 bit
> - I don't know
> - Other: _________________
>
> x. Which of the following do your *any* of your MPI applications use?
> (select all that apply)
> - Threads
> - OpenMP
> - Shmem
> - Global Arrays
> - Co-processors / accelerators
> - PGAS languages
> - I don't know
> - Other: ______________
>
> x. How important are each of the following sets of MPI functionality
> to *any* of your MPI applications?
> 1/not important at all ... 5/very important
> - Point-to-point communications
> - Collective communications
> - Derived / complex datatypes
> - Communicators other than MPI_COMM_WORLD
> - Graph or Cartesian process topologies
> - Error handles / error checking
> - Dynamic MPI processes (spawn, connect/accept, join)
> - One-sided communication
> - Generalized requests
> - Parallel I/O
> - "PMPI" profiling interface
> - Multi-threaded applications (for example, MPI_THREAD_MULTIPLE)
> - Other: ______________
> If you marked any set with 1 or 2, please explain why.
> __________
>
> x. Are any of your MPI applications written to use the MPI C++
> bindings?
> - Yes
> - No
> - I don't know
>
> x. I expect to be able to upgrade to an MPI-3 implementation and still
> be able to run my legacy MPI aplications *without recompiling*.
> Strongly agree/1 ...... Strongly disagree/5
> Open comment: _________________________
>
> x. I expect to be able to upgrade to an MPI-3 implementation and only
> need to recompile my legacy MPI applications *with no source code
> changes*.
> Strongly agree/1 ....... Strongly disagree/5
> Open comment: _________________________
>
> x. My MPI application would benefit from being able to reference more
> than 2^31 data items in a single MPI function invocation.
> Strongly agree/1 ....... Strongly disagree/5
> Open comment: _________________________
>
> x. MPI one-sided communication performance is more important to me
> than supporting a rich remote memory access (RMA) feature set.
> Strongly agree/1 ....... Strongly disagree/5
> Open comment: _________________________
>
> x. The following are a list of topics that the MPI Forum is
> considering for MPI-3. Rank them in order of importance to your
> MPI applications:
> - Non-blocking collective communications
> - Revamped one-sided communications (compared to MPI-2.2)
> - MPI application control of fault tolerance
> - New Fortran bindings (type safety, etc.)
> - "Hybrid" programming (MPI in conjunction with threads,
> OpenMP, ..)
> - Standardized third-party MPI tool support
> - Other: ______________
>
> x. What *ONE THING* would you like to see added or improved in the MPI
> standard?
> _____________
>
> x. Rate the following in order of importance to your MPI applications:
> - Performance
> - Feature-rich API
> - Run-time reliability
> - Scalability to large numbers of MPI processes
> - Integration with other communication protocols /
>
> x. Did you attend the MPI Forum BOF at SC09?
> - Yes
> - No
>
> x. Use the space below to provide any other information, suggestions,
> or comments to the 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
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20091116/0a1d9e15/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20091116/0a1d9e15/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20091116/0a1d9e15/attachment-0003.gif>
More information about the mpi-forum
mailing list