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

Re: [Mpi-forum] Merged Nonblocking Collectives into MPI-3 - Please Review!
by Rolf Rabenseifner 16 Feb '10

16 Feb '10

Hello Torsten, Jeff and Rich, I'm sorry that I could not attend the discussion at last meeting. Jeff's minutes are not yet available, therefore my opinion may be in contrary to votes at the meeting - then please tell me. My opinion after looking at ticket 254, file chap-coll/coll.tex : I strongly disagree with the current state of the latex source. You reinvented all the old MPI-2.2 markups, i.e., you uncleaned the tex source of exactly one file: coll.tex. All MPI-2.2 markups are removed to allow the usage of Bills macros to mark all new MPI-3.0 changes. I could not find any \MPIupdate{3.0}... or similar markups in your new source. The 73 changes (found be grep'ing "htor") should be done into "current" coll.tex revision 253 and not into a very old revision. There is no chance to do the cleaning again on your current unclean coll.tex revision 254! All these 73 changes should be marked with Bill's macros as ticket {3.0}{109}. If the forum decided to step back to the uncleaned source then it should be done for all sources and not only for coll.tex. Rich and Jeff, I cannot see any comments on ticket #203, nor any review from you. Did you discussed it at the Jan 2010 meeting? Best regards Rolf On Mon, 15 Feb 2010 14:15:39 -0600 Torsten Hoefler <htor(a)cs.indiana.edu> wrote: > Hello Forum, > > I finished my merger of NBC into MPI-3 as we discussed at the last > meeting. I did the merge in the following order: > > 1) I merged all MPI-2.2 changes into NBC rev. 6 (the version that we > voted into MPI-3, attached to #109). This was a relatively > straightforward manual process. > > 2) I merged the combined document into the MPI-3 tree. This was much > more complex than anticipated because the MPI-3 tree is "cleaned >up" > (i.e., many change-macros are gone) and after discussion with >Jeff, > we realized that the script could not be applied to separate > chapters. This, I performed a manual cleanup and removed the >change > macros in this process. This was not as simple as 1) and seems >more > error-prone. > > 3) I re-read and compared the colored MPI-2.2 document and the MPI-3 > document and committed it as rev. 524. > > > The ability to highlight the changes between the revisions >(particularly > the MPI-2.2 changes) were important for the merger. Bill did a great >job > making those extremely helpful for my review. I would suggest that >we > use the same or a similar mechanism for MPI-3. Right now, I left all >my > (b/w) change-macros (\htorchange, defined at the bottom of >mpi-macs.tex) > in the source so that we can see what changed after MPI-2.2. I would > volunteer to transition them to a new mechanism based on whatever we > decide. > > Please review the document carefully, the changes that I made were >not > minor and much more intrusive then all MPI-2.2 changes to the > collectives chapter. It would be good to have some designated >careful > reviewers, any volunteers? > > I think we strived to have reviews at the March meeting and I was > supposed to deliver a draft two weeks in advance. Now we have three > weeks left. That is not very long imho, so we might consider to move >the > review deadline. > > Here are some things that I added which we did not explicitly vote >on > (however, they are minor and straight-forward from our past votes): > > 1) fixed some typos (missing ")" and removed some spaces where > appropriate (see svn diff) > > 2) added MPI_Reduce_scatter to various lists in the introduction of > Chapter 5 (this is a bug in MPI-2.2) > > 3) added MPI_Ireduce_scatter_block to the listing of nonblocking > collectives. Please review the function interface carefully! This >was > not voted on or reviewed yet. > > 4) added a \label{} in the p2p Chapter 3 to reference nonblocking > progression semantics (they're referenced nowhere else ;-)). > > I put two versions of the document online for easier reviewing. Both > versions have the MPI-2.2 changes highlighted (purple for removals, >red > for additions plus the ticket number at the margin) and also the >MPI-3 > changes (striked out for removals, underlined for additions, limited >to > Chapter 5). > > MPI-2.2: http://www.unixer.de/sec/mpi-2.2.pdf > MPI-3.0: http://www.unixer.de/sec/mpi-3.0.pdf > > It should be sufficient to review Chapter 5 only. Please let me know >if > you have any questions or find any problems. > > All the Best, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler | Research Associate > Blue Waters Directorate | University of Illinois > 1205 W Clark Street | Urbana, IL, 61801 > NCSA Building | +01 (217) 244-7736 > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Merged Nonblocking Collectives into MPI-3 - Please Review!
by Torsten Hoefler 15 Feb '10

15 Feb '10

Hello Forum, I finished my merger of NBC into MPI-3 as we discussed at the last meeting. I did the merge in the following order: 1) I merged all MPI-2.2 changes into NBC rev. 6 (the version that we voted into MPI-3, attached to #109). This was a relatively straightforward manual process. 2) I merged the combined document into the MPI-3 tree. This was much more complex than anticipated because the MPI-3 tree is "cleaned up" (i.e., many change-macros are gone) and after discussion with Jeff, we realized that the script could not be applied to separate chapters. This, I performed a manual cleanup and removed the change macros in this process. This was not as simple as 1) and seems more error-prone. 3) I re-read and compared the colored MPI-2.2 document and the MPI-3 document and committed it as rev. 524. The ability to highlight the changes between the revisions (particularly the MPI-2.2 changes) were important for the merger. Bill did a great job making those extremely helpful for my review. I would suggest that we use the same or a similar mechanism for MPI-3. Right now, I left all my (b/w) change-macros (\htorchange, defined at the bottom of mpi-macs.tex) in the source so that we can see what changed after MPI-2.2. I would volunteer to transition them to a new mechanism based on whatever we decide. Please review the document carefully, the changes that I made were not minor and much more intrusive then all MPI-2.2 changes to the collectives chapter. It would be good to have some designated careful reviewers, any volunteers? I think we strived to have reviews at the March meeting and I was supposed to deliver a draft two weeks in advance. Now we have three weeks left. That is not very long imho, so we might consider to move the review deadline. Here are some things that I added which we did not explicitly vote on (however, they are minor and straight-forward from our past votes): 1) fixed some typos (missing ")" and removed some spaces where appropriate (see svn diff) 2) added MPI_Reduce_scatter to various lists in the introduction of Chapter 5 (this is a bug in MPI-2.2) 3) added MPI_Ireduce_scatter_block to the listing of nonblocking collectives. Please review the function interface carefully! This was not voted on or reviewed yet. 4) added a \label{} in the p2p Chapter 3 to reference nonblocking progression semantics (they're referenced nowhere else ;-)). I put two versions of the document online for easier reviewing. Both versions have the MPI-2.2 changes highlighted (purple for removals, red for additions plus the ticket number at the margin) and also the MPI-3 changes (striked out for removals, underlined for additions, limited to Chapter 5). MPI-2.2: http://www.unixer.de/sec/mpi-2.2.pdf MPI-3.0: http://www.unixer.de/sec/mpi-3.0.pdf It should be sufficient to review Chapter 5 only. Please let me know if you have any questions or find any problems. All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Research Associate Blue Waters Directorate | University of Illinois 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

CFP relevant to MPI
by William Gropp 11 Feb '10

11 Feb '10

ACM SIGPLAN Workshop on Advances in Message Passing (AMP) Languages, Compilers, and Run-time Support at the SIGPLAN 2010 Conference on Programming Language Design and Implementation June 6, 2010 Toronto, Canada CALL FOR PAPERS Submission: March 20, 2010 Notification: April 25, 2010 Final paper: May 16, 2010 http://www.cs.rochester.edu/u/cding/amp -------------------------------------------------------------------------------- As feature sizes in electronics grow smaller, physical issues such as bounds on the speed of light, pin counts and 2-dimensional network layouts threaten to constrain improvements in communication bandwidth and latency even as increasing core counts improve compute performance. The resulting limitations force application and system developers to explicitly optimize communication locality and timing sensitivity by using explicit communication primitives such as point-to-point sends/receives, puts/gets and collective operations such as broadcast. Today message passing is supported by a wide variety of APIs, including run-time libraries such as MPI, network interfaces such as TCP/IP and Internet protocols such as HTTP. However, relatively little attention has been paid to the connection between message-passing runtimes and programming languages and compilers. Programming a message-passing system involves the fundamental tasks of computation partitioning, data partitioning, and data communication. It poses a distinct set of challenges in the analysis, transformation, and support of such programs. Significant advances have been made in the areas programming languages, compiler support, and run-time systems for message passing programs. Such progress can be accelerated by integrating and sharing ideas, results, and tools, enabling new parallel programming techniques and improving the performance and maintainability of scientific applications as well as collaboration software. The AMP workshop brings together researchers in academia, industry and government research institutes to discuss the shared challenges and present state- of-art research results. It aims to become a focused forum on subjects in the interaction of programming language, program analysis, and run-time support of message passing systems. The topics of interest include but are not limited to o algorithms and applications o parallel languages and programmability studies o compiler and run-time techniques for improving locality, scalability, and reliability o performance, testing, and debugging tools o program analysis tools for message passing programs o programming constructs to improve the usability of message-passing AMP is soliciting both position papers (3 pages) and research papers (10 pages) report previously unpublished work. Papers must be PDF files in ACM proceedings format (http://www.acm.org/sigs/sigplan/authorInformation.htm , 9 pt template), printable on US Letter and A4 sized paper. ORGANISERS: Greg Bronevetsky, Lawrence Livermore National Laboratory greg(a)bronevetsky.com Chen Ding, University of Rochester cding(a)cs.rochester.edu Sven-Bodo Scholz, University of Hertfordshire S.Scholz(a)herts.ac.uk Michelle Strout, Colorado State University mstrout(a)cs.colstate.edu 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] C-MPI DYNAMIC ALLOCATION / DERIVED DATATYPES
by Simone Pellegrini 11 Feb '10

11 Feb '10

On 02/11/2010 01:42 PM, kostas pinokio wrote: > HALLO, > > I would like to send a whole column of a dynamicly allocated array (in > C language). > When i use derived datatypes(for example MPI_Type_vector) i can send a > column ONLY if i have static array but when i use dynamic allocation i > have problem! > Please tell me one way to send a column of a dynamc allocated array. > > For example : > MPI_Datatype columntype; > MPI_Type_vector(10, 1, 10, MPI_INT, &columntype); > MPI_Type_commit(&columntype); > if(rank==0){ > dyn_array=(int **) calloc(10,sizeof(int *)); > for(i = 0; i < 10; i++){ > dyn_array[i] =(int *) calloc(10,sizeof(int)); > } > for(i=0;i<10;i++){ for(j=0;j<10;j++) > dyn_array[i][j]=9;} > MPI_Send(&dyn_array[0][0], 1, columntype, dest, > tag,MPI_COMM_WORLD); > } > if(rank==1){ > MPI_Recv(&other_dyn_array[0][0], 1, columntype, 0, tag, > MPI_COMM_WORLD, &Stat); > } > > the values of the receive are not correct!! > The MPI_Type_vector assumes your data is contiguous in memory and this is not the case in your code. As each raw is allocated using a different calloc. You need to arrange the 2D array in memory in a more clever way: if(rank==0){ dyn_array=(int **) calloc(10,sizeof(int *)); dyn_array[0] = (int*) calloc(10*10, sizeof(int)); for(i = 1; i < 10; i++) dyn_array[i] = dyn_array[0] + i*10; /*same code*/ } this should work! cheers, Simone > > Thank You! > > > __________________________________________________ > οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ Yahoo!; > οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ (spam); οΏ½οΏ½ Yahoo! Mail οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½ > οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ > http://mail.yahoo.gr > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

C-MPI DYNAMIC ALLOCATION / DERIVED DATATYPES
by kostas pinokio 11 Feb '10

11 Feb '10

HALLO, I would like to send a whole column of a dynamicly allocated array (in C language). When i use derived datatypes(for example MPI_Type_vector) i can send a column ONLY if i have static array but when i use dynamic allocation i have problem! Please tell me one way to send a column of a dynamc allocated array. For example : MPI_Datatype columntype; MPI_Type_vector(10, 1, 10, MPI_INT, &columntype); MPI_Type_commit(&columntype); if(rank==0){ dyn_array=(int **) calloc(10,sizeof(int *)); for(i = 0; i < 10; i++){ dyn_array[i] =(int *) calloc(10,sizeof(int)); } for(i=0;i<10;i++){ for(j=0;j<10;j++) dyn_array[i][j]=9;} MPI_Send(&dyn_array[0][0], 1, columntype, dest, tag,MPI_COMM_WORLD); } if(rank==1){ MPI_Recv(&other_dyn_array[0][0], 1, columntype, 0, tag, MPI_COMM_WORLD, &Stat); } the values of the receive are not correct!! Thank You! __________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://mail.yahoo.gr

1 0

March 8-10 Forum meeting
by Graham, Richard L. 05 Feb '10

05 Feb '10

The agenda for the March 8-10 meeting have just been posted. Please take a look at it, and see if there are changes that you would like to see. In particular, only a few working groups have been given time slots, but there is plenty of time for parallel sessions. So if your working group is not on the agenda, and you would like to be added, please let me know. Logistics are not yet setup, but as soon as we get the last needed approval, will proceed with these. Rich

1 0