January 2010 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] MPI_Count
by Rajeev Thakur 24 Jan '10

24 Jan '10

I don't know who wants to communicate >2GB at a time, but HP seemed to have enough users wanting it to cause Kannan to create and pursue ticket #117 until he moved to a different project. Rajeev > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of > Underwood, Keith D > Sent: Sunday, January 24, 2010 5:20 PM > To: Main MPI Forum mailing list; mpi3(a)lists.mpi-forum.org > Subject: Re: [Mpi-forum] MPI_Count > > > Still seems a little odd to have a solution for I/O > functions and not > > for communication functions (the original ticket was for > communication > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/117) > > If > 2GB can be written from a single process in a single > call, they > > can also be communicated. If it is tedious to break up the > write into > > smaller writes, the same applies to communication. > > "can be" and "will be" are very different phrases. The > feeling within the group that was there Thursday morning was > that the "way 64 bit is done" (TM) is to replicate all of the > function calls. The group felt like a compelling case had > been made for I/O, because you would want to write all of > your memory to file (e.g. checkpointing) and memory per node > is growing beyond 2 GB. However, it was much harder to make > the case that you really wanted to send that much data from a > contiguous location to any other node. In fact, someone made > the statement "all of the application users understand that > you can't do that and still scale on any network in the > foreseeable future". > > Your interoperability comments may be a more motivating > example, but as of Thursday morning, it was clear that there > was not consensus among the forum members who were - > especially given the pain that is going to be involved in > fixing this for the general case. > > Keith > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

Re: [Mpi-forum] MPI_Count
by Underwood, Keith D 24 Jan '10

24 Jan '10

> Still seems a little odd to have a solution for I/O functions and not > for communication functions (the original ticket was for > communication https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/117) > If > 2GB can be written from a single process in a single > call, they can also be communicated. If it is tedious to break up the > write into smaller writes, the same applies to communication. "can be" and "will be" are very different phrases. The feeling within the group that was there Thursday morning was that the "way 64 bit is done" (TM) is to replicate all of the function calls. The group felt like a compelling case had been made for I/O, because you would want to write all of your memory to file (e.g. checkpointing) and memory per node is growing beyond 2 GB. However, it was much harder to make the case that you really wanted to send that much data from a contiguous location to any other node. In fact, someone made the statement "all of the application users understand that you can't do that and still scale on any network in the foreseeable future". Your interoperability comments may be a more motivating example, but as of Thursday morning, it was clear that there was not consensus among the forum members who were - especially given the pain that is going to be involved in fixing this for the general case. Keith

1 0

Re: [Mpi-forum] MPI_Count
by Rajeev Thakur 24 Jan '10

24 Jan '10

Still seems a little odd to have a solution for I/O functions and not for communication functions (the original ticket was for communication https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/117) If > 2GB can be written from a single process in a single call, they can also be communicated. If it is tedious to break up the write into smaller writes, the same applies to communication. Also this doesn't address the other real problem in I/O that occurs on 32-bit systems because of the mismatch between MPI_Aint and MPI_Offset. Datatypes are used to describe file layout, and they use MPI_Aint. If you have a distributed array of global size 1K x 1K x 1K and try to use the subarray or darray datatype, its extent becomes negative on 32-bit systems. Similarly, you can't use an hindexed type as a filetype if you want to index beyond 2G. Rajeev > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of > Jeff Squyres > Sent: Friday, January 22, 2010 2:07 PM > To: MPI Forum list; mpi3(a)lists.mpi-forum.org > Subject: [Mpi-forum] MPI_Count > > Please note that there was a bunch of discussion about > MPI_Count and other compatibility issues at the meeting in > Atlanta this week. I posted a summary of takeaways from the > discussion on the bwcompat WG mailing list and wiki: > > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/BackCompatMeetings > http://lists.mpi-forum.org/mpi3-bwcompat/2010/01/0024.php > > Although there are still some decisions to be made (e.g., > about Fortran), a surprising amount of consensus emerged. > Please read up on the notes to see what was discussed -- > please chime in ASAP if you have dissenting views. > > Thanks! > > -- > Jeff Squyres > jsquyres(a)cisco.com > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

Slides from Atlanta
by Jeff Squyres 22 Jan '10

22 Jan '10

I think I reminded some of you already, but don't forget to send me your slides so that I can put them up on the web. Thanks. -- Jeff Squyres jsquyres(a)cisco.com

1 0

MPI_Count
by Jeff Squyres 22 Jan '10

22 Jan '10

Please note that there was a bunch of discussion about MPI_Count and other compatibility issues at the meeting in Atlanta this week. I posted a summary of takeaways from the discussion on the bwcompat WG mailing list and wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/BackCompatMeetings http://lists.mpi-forum.org/mpi3-bwcompat/2010/01/0024.php Although there are still some decisions to be made (e.g., about Fortran), a surprising amount of consensus emerged. Please read up on the notes to see what was discussed -- please chime in ASAP if you have dissenting views. Thanks! -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [Mpi-forum] Compile-time check for MPI_Init or MPI_Init thread
by William Gropp 20 Jan '10

20 Jan '10

No, but either autoconf or the kind of test strategy that it uses (can I link a program with the routine) is relatively easy to implement when creating the application build environment (and note that these tests work in a cross-compilation environment). Bill On Jan 20, 2010, at 3:49 PM, Kendall, Ricky A. wrote: > But does the standard say you need to have autoconf available to use > MPI? > This is a good solution but has issues. > > Ricky A. Kendall > Group Leader, Scientific Computing > Oak Ridge Leadership Computing Facility (OLCF) > Oak Ridge National Laboratory > Phone: (865) 576-6905 > Cell: (865) 356-3461 > Email: kendallra _at_ ornl.gov > AIM and Yahoo: rickyakendall > Gmail: rickyk > > > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected] > ] On Behalf Of William Gropp > Sent: Wednesday, January 20, 2010 11:18 AM > To: Main MPI Forum mailing list > Cc: Markus Geimer > Subject: Re: [Mpi-forum] Compile-time check for MPI_Init or MPI_Init > thread > > In this exact situation (building tests for any MPI implementation, > including tests of thread safety, I use the autoconf macros to check > for the functions that I need. > > Bill > > On Jan 20, 2010, at 3:15 AM, Marc-Andre Hermanns wrote: > >> Hi all, >> >> we are currently puzzled about how to check whether to call MPI_Init >> or >> MPI_Init_thread in one of our programs. >> >> Our performance analyzer scout can be built in different versions: >> MPI, >> OpenMP, and hybrid MPI/OpenMP. As the code-base is shared, we have >> #define statements to separate individual portions of the code. To >> decide whether to call MPI_Init or MPI_Init_thread at compile time we >> check the #define set by MPI. However, POE on our Power6 Cluster >> correctly reports MPI 1, as it does not support spawning and is >> therefore not MPI 2 compliant, yet MPI_Init_thread would be >> available, >> and must be used for the hybrid version. >> >> My initial idea is to take 'nm' at configure-time of our tool. Check >> whether MPI_Init_thread is in the library, and set my own #define. >> >> Is there a more elegant solution? How are users supposed to portably >> detect it? >> >> Is it something we can/should fix? >> >> Best regards, >> Marc-Andre >> -- >> Marc-Andre Hermanns >> Juelich Supercomputing Centre >> Institute for Advanced Simulation >> Forschungszentrum Juelich GmbH >> D-52425 Juelich >> Germany >> >> Phone : +49-2461-61-2054 >> Fax : +49-2461-61-6656 >> eMail : m.a.hermanns(a)fz-juelich.de >> WWW : http://www.fz-juelich.de/jsc/ >> >> JSC is the coordinator of the >> John von Neumann Institute for Computing >> and member of the >> Gauss Centre for Supercomputing >> >> Sitz der Gesellschaft: Juelich >> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >> Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe >> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), >> Dr. Ulrich Krafft (stellv. Vorsitzender), >> Prof. Dr. Harald Bolt, >> Prof. Dr. Sebastian M. Schmidt >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-forum] Compile-time check for MPI_Init or MPI_Init thread
by Kendall, Ricky A. 20 Jan '10

20 Jan '10

But does the standard say you need to have autoconf available to use MPI? This is a good solution but has issues. Ricky A. Kendall Group Leader, Scientific Computing Oak Ridge Leadership Computing Facility (OLCF) Oak Ridge National Laboratory Phone: (865) 576-6905 Cell: (865) 356-3461 Email: kendallra _at_ ornl.gov AIM and Yahoo: rickyakendall Gmail: rickyk -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of William Gropp Sent: Wednesday, January 20, 2010 11:18 AM To: Main MPI Forum mailing list Cc: Markus Geimer Subject: Re: [Mpi-forum] Compile-time check for MPI_Init or MPI_Init thread In this exact situation (building tests for any MPI implementation, including tests of thread safety, I use the autoconf macros to check for the functions that I need. Bill On Jan 20, 2010, at 3:15 AM, Marc-Andre Hermanns wrote: > Hi all, > > we are currently puzzled about how to check whether to call MPI_Init > or > MPI_Init_thread in one of our programs. > > Our performance analyzer scout can be built in different versions: > MPI, > OpenMP, and hybrid MPI/OpenMP. As the code-base is shared, we have > #define statements to separate individual portions of the code. To > decide whether to call MPI_Init or MPI_Init_thread at compile time we > check the #define set by MPI. However, POE on our Power6 Cluster > correctly reports MPI 1, as it does not support spawning and is > therefore not MPI 2 compliant, yet MPI_Init_thread would be available, > and must be used for the hybrid version. > > My initial idea is to take 'nm' at configure-time of our tool. Check > whether MPI_Init_thread is in the library, and set my own #define. > > Is there a more elegant solution? How are users supposed to portably > detect it? > > Is it something we can/should fix? > > Best regards, > Marc-Andre > -- > Marc-Andre Hermanns > Juelich Supercomputing Centre > Institute for Advanced Simulation > Forschungszentrum Juelich GmbH > D-52425 Juelich > Germany > > Phone : +49-2461-61-2054 > Fax : +49-2461-61-6656 > eMail : m.a.hermanns(a)fz-juelich.de > WWW : http://www.fz-juelich.de/jsc/ > > JSC is the coordinator of the > John von Neumann Institute for Computing > and member of the > Gauss Centre for Supercomputing > > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender), > Prof. Dr. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Compile-time check for MPI_Init or MPI_Init thread
by William Gropp 20 Jan '10

20 Jan '10

In this exact situation (building tests for any MPI implementation, including tests of thread safety, I use the autoconf macros to check for the functions that I need. Bill On Jan 20, 2010, at 3:15 AM, Marc-Andre Hermanns wrote: > Hi all, > > we are currently puzzled about how to check whether to call MPI_Init > or > MPI_Init_thread in one of our programs. > > Our performance analyzer scout can be built in different versions: > MPI, > OpenMP, and hybrid MPI/OpenMP. As the code-base is shared, we have > #define statements to separate individual portions of the code. To > decide whether to call MPI_Init or MPI_Init_thread at compile time we > check the #define set by MPI. However, POE on our Power6 Cluster > correctly reports MPI 1, as it does not support spawning and is > therefore not MPI 2 compliant, yet MPI_Init_thread would be available, > and must be used for the hybrid version. > > My initial idea is to take 'nm' at configure-time of our tool. Check > whether MPI_Init_thread is in the library, and set my own #define. > > Is there a more elegant solution? How are users supposed to portably > detect it? > > Is it something we can/should fix? > > Best regards, > Marc-Andre > -- > Marc-Andre Hermanns > Juelich Supercomputing Centre > Institute for Advanced Simulation > Forschungszentrum Juelich GmbH > D-52425 Juelich > Germany > > Phone : +49-2461-61-2054 > Fax : +49-2461-61-6656 > eMail : m.a.hermanns(a)fz-juelich.de > WWW : http://www.fz-juelich.de/jsc/ > > JSC is the coordinator of the > John von Neumann Institute for Computing > and member of the > Gauss Centre for Supercomputing > > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender), > Prof. Dr. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

SVN perms
by Jeff Squyres 20 Jan '10

20 Jan '10

We talked about this yesterday in the meeting but I didn't have an internet connection to check at the time; here's how the permissions in the SVN tree are currently set (trunk): Groups: ------- Editor 1: Rainer Editor 2.1: Rolf, Rajeev, Bill Editor 2.2: all the chapter authors --> I'm not sure why we lumped all the chapter authors in the "editor" group for 2.2, but we did Editor 3: Rich Author 3: me, Torsten, Rolf --> Should I add all the MPI-2.2 chapter authors to the "Author 3" group? WG: me, Ashley, John D., Marc AH, Martin S. Trees: ------ /trunk/MPI-1: Editor 1 can write /trunk/MPI-2.1: Editor 2.1 can write /trunk/MPI-2.2: Editor 2.2 can write /trunk/MPI-3.0: Editor 3 and Author 3 can write /trunk/MPI-3.0/wg: WG -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [Mpi-forum] Compile-time check for MPI_Init or MPI_Init thread
by Jeff Squyres 20 Jan '10

20 Jan '10

Just to make sure I understand -- you're saying that you have an MPI implementation where MPI_VERSION is being reported as 1, but it also has MPI_INIT_THREAD available. Is that right? If so, then having an nm check or using something like Autoconf's AC_CHECK_FUNCTION is probably your best bet. Alternatively, you could try to dlopen (or whatever the equivalent is on that platform) the current process and dlsym looking for MPI_Init and MPI_Init_thread and invoke whichever one you find/prefer indirectly through a function pointer. On Jan 20, 2010, at 4:15 AM, Marc-Andre Hermanns wrote: > Hi all, > > we are currently puzzled about how to check whether to call MPI_Init or > MPI_Init_thread in one of our programs. > > Our performance analyzer scout can be built in different versions: MPI, > OpenMP, and hybrid MPI/OpenMP. As the code-base is shared, we have > #define statements to separate individual portions of the code. To > decide whether to call MPI_Init or MPI_Init_thread at compile time we > check the #define set by MPI. However, POE on our Power6 Cluster > correctly reports MPI 1, as it does not support spawning and is > therefore not MPI 2 compliant, yet MPI_Init_thread would be available, > and must be used for the hybrid version. > > My initial idea is to take 'nm' at configure-time of our tool. Check > whether MPI_Init_thread is in the library, and set my own #define. > > Is there a more elegant solution? How are users supposed to portably > detect it? > > Is it something we can/should fix? > > Best regards, > Marc-Andre > -- > Marc-Andre Hermanns > Juelich Supercomputing Centre > Institute for Advanced Simulation > Forschungszentrum Juelich GmbH > D-52425 Juelich > Germany > > Phone : +49-2461-61-2054 > Fax : +49-2461-61-6656 > eMail : m.a.hermanns(a)fz-juelich.de > WWW : http://www.fz-juelich.de/jsc/ > > JSC is the coordinator of the > John von Neumann Institute for Computing > and member of the > Gauss Centre for Supercomputing > > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender), > Prof. Dr. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > -- Jeff Squyres jsquyres(a)cisco.com

1 0