- devel - mailman3.cels.anl.gov

Re: [mpich-devel] P states and MPI
by William Gropp 17 Jan '14

17 Jan '14

There has been some work on this for parallel programs; Wu Feng at Virginia Tech has done some, for example. I don't recall seeing any work that used the profiling interface. Some of the issues raised, especially the required privs, mean that this is only available for experiments, not production, until that changes. Also, its sometimes possible to make predictions about wait times based on previous iterations; that could be used to refine such control. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Jan 16, 2014, at 9:36 PM, Jeff Hammond wrote: > I was impressed by > http://www.hpcadvisorycouncil.com/events/2013/Spain-Workshop/pdf/5_Dell.pdf > / http://www.bsc.es/sites/default/files/public/mare_nostrum/2013hpcac-05.pdf. > I wonder if anyone else has seen this, done anything similar, is > interested in doing something similar, etc. I can imagine that a more > integrated implementation has some performance advantages, albeit at > much greater maintenance cost. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com

1 0

P states and MPI
by Jeff Hammond 16 Jan '14

16 Jan '14

I was impressed by http://www.hpcadvisorycouncil.com/events/2013/Spain-Workshop/pdf/5_Dell.pdf / http://www.bsc.es/sites/default/files/public/mare_nostrum/2013hpcac-05.pdf. I wonder if anyone else has seen this, done anything similar, is interested in doing something similar, etc. I can imagine that a more integrated implementation has some performance advantages, albeit at much greater maintenance cost. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [mpich-devel] Weak symbols, clang, and users compiling with -fvisibility=hidden
by Kenneth Raffenetti 13 Jan '14

13 Jan '14

Hi Jed, Thanks for reporting this. I don't know the exact history of the configure tests, but my "fix" was to make the results consistent across our testing platforms. From your email, it appears there is larger issue we need to address in order to do what's intended. I'll create a new ticket. Ken On 01/08/2014 02:19 PM, "Antonio J. Peña" wrote: > > Let me discuss this with Ken. We'll get back to you. > > Antonio > > > On 01/06/2014 06:19 PM, Jed Brown wrote: >> Jed Brown <jedbrown(a)mcs.anl.gov> writes: >> >>> Pavan Balaji <balaji(a)mcs.anl.gov> writes: >>>> This attribute is tested in configure before it’s added to mpi.h.in. >>> Yes, the configure test is incorrect and the resulting usage in MPICH is >>> broken (does not do what you intend). >> As far as I know, >> >> #pragma weak MPI_Xyz = PMPI_Xyz >> >> is equivalent to what was intended with the attribute syntax >> >> __attribute__((weak, alias("PMPI_Xyz"))) >> >> (which belongs in an implementation file, not in the public header). Is >> there a reason to bother testing for the attribute syntax? > >

1 0

Webex info: MPI implementation requirements for a network layer
by Jeff Squyres (jsquyres) 13 Jan '14

13 Jan '14

Thanks to all who replied to the Doodle and emailed me feedback. Those who have not yet done so, please send me feedback by COB tomorrow (Tues, 14 Jan 2014). Per the Doodle, everyone is able to attend at 2pm US Eastern time, Wednesday, 15 Jan 2014. Webex info is below. I'm sending this notice to all the lists from which I initially requested feedback, and am also BCC'ing everyone who replied to the Doodle. But I do not have email addresses for the following Doodle responders -- can someone forward this mail to them? - Michael Blocksome - Chulho Kim - Michael Raymond - Shane Farmer Webex link: https://cisco.webex.com/ciscosales/j.php?ED=250656997&UID=0&PW=NMmMxZWU1NWZ… Password: mpi Complete webex info below See you Wednesday; thanks. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ **** You can forward this email invitation to attendees **** Jeff Squyres invites you to attend this online meeting. Topic: MPI implementation requirements for network layer Date: Wednesday, January 15, 2014 Time: 2:00 pm, Eastern Standard Time (New York, GMT-05:00) Meeting Number: 209 436 402 Meeting Password: mpi ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=250656997&UID=0&PW=NMmMxZWU1NWZ… 2. Enter your name and email address. 3. Enter the meeting password: mpi 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=250656997&UID=0&PW=NMmMxZWU1NWZ… ---------------------------------------------------------------- ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: jsquyres(a)cisco.com 1-408-525 0971 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://cisco.webex.com/ciscosales/j.php?ED=250656997&UID=0&ICS=MI&LD=1&RD=… The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going tohttps://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com CCP:+14085256800x209436402# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by Jed Brown 09 Jan '14

09 Jan '14

"Antonio J. Peña" <apenya(a)mcs.anl.gov> writes: > In our group meeting we decided to keep using the Signed-off-by field, > as it's more convenient for us. This has been clarified in our wiki page > on the workflow section: > https://wiki.mpich.org/mpich/index.php/Git#Overall_Workflow Cool, thanks for the update.

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by "Antonio J. Peña" 09 Jan '14

09 Jan '14

In our group meeting we decided to keep using the Signed-off-by field, as it's more convenient for us. This has been clarified in our wiki page on the workflow section: https://wiki.mpich.org/mpich/index.php/Git#Overall_Workflow Thank you for bringing our attention to this. Toni On 01/05/2014 01:24 PM, Pavan Balaji wrote: > On Jan 5, 2014, at 11:59 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: >>> Essentially, itï¿½s what we define it to be. I guess we could have used >>> ï¿½Reviewed-byï¿½, but Iï¿½m not sure it really matters that much. >> FWIW, I think it's a needless deviation from a widespread convention. > Iï¿½ll bring this up at the next group meeting and see what the other developers think. > > ï¿½ Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > -- Antonio J. Peï¿½a Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

Re: [mpich-devel] Weak symbols, clang, and users compiling with -fvisibility=hidden
by "Antonio J. Peña" 08 Jan '14

08 Jan '14

Let me discuss this with Ken. We'll get back to you. Antonio On 01/06/2014 06:19 PM, Jed Brown wrote: > Jed Brown <jedbrown(a)mcs.anl.gov> writes: > >> Pavan Balaji <balaji(a)mcs.anl.gov> writes: >>> This attribute is tested in configure before it’s added to mpi.h.in. >> Yes, the configure test is incorrect and the resulting usage in MPICH is >> broken (does not do what you intend). > As far as I know, > > #pragma weak MPI_Xyz = PMPI_Xyz > > is equivalent to what was intended with the attribute syntax > > __attribute__((weak, alias("PMPI_Xyz"))) > > (which belongs in an implementation file, not in the public header). Is > there a reason to bother testing for the attribute syntax? -- Antonio J. Peña Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

MPI implementation requirements for low-layer network APIs
by Jeff Squyres (jsquyres) 08 Jan '14

08 Jan '14

Short version: ============== Sean Hefty from Intel is soliciting feedback from the MPI community about what MPI needs from a new low-level networking API (that hopes to be the successor to libibverbs). He has asked me to gather this feedback and present it to the OpenFabrics "libfabric" working group on January 21. Please a) unicast email to me what you would like to convey to this working group by COB next Tuesday (January 14), and/or b) sign up on the Doodle below to join a webex to review the collected feedback before I present it to the OpenFabrics working group. Due to the short turnaround, I picked several days at the end of next week: http://doodle.com/44uea5v38euu6smh More detail: ============ As some of you may already be aware, Sean Hefty at Intel is leading an effort in the OpenFabrics community to basically re-design the network layer API for userspace to talk directly with hardware. Sean has been presenting his vision of this new "libfabric" for a little while now; he even hosted a BOF about it at SC'13. You can think of it as "verbs 2.0", but it's really quite a bit more than that: a) it's starting the API over from scratch b) there's no implicit design requirements for InfiniBand c) there's no need to be API/ABI compatible with current generations of the libibverbs API One of the major explicit goals of libfabric is to support MPI well. Bad memory registration support is probably the easiest-to-discuss verbs complaint that we MPI developers have had over the years, but there are other areas where verbs is lacking, too. Now is the chance for us to voice MPI's requirements. Here's my plan: 1. I have many opinions in this area, and I know many of you do, too. Please send me your opinions and feedback in whatever format you'd prefer: - email/text - slides - word documents - pictures of whiteboards with notes - ...etc. NOTE: The OpenFabrics working group is basically assuming that we can all rattle off the tops of our heads what MPI wants (which is probably a good assumption), so please send your feedback by COB Tuesday, January 14, 2014. 2. I'll take all this feedback and assemble it into a cohesive story/set of slides. 3. I'll then host a webex late next week (signup on the Doodle so that we can find a time that works for the most people) to both go over the slides from the feedback received so far as well as solicit any further feedback from people on the call. http://doodle.com/44uea5v38euu6smh 4. Finally, I'll take the results of discussion from the webex and present the final slides to the OpenFabrics working group on Jan 21. Your input would be greatly appreciated. Many thanks for your time. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

pwrite/pread
by Rob Latham 07 Jan '14

07 Jan '14

In 2013 are there any platforms I should worry about that do not have pwrtie/pread ? ROMIO's already using them in the Lustre and XFS drivers, but those file systems are closely correlated to "modern" operating systems. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] Weak symbols, clang, and users compiling with -fvisibility=hidden
by Jed Brown 06 Jan '14

06 Jan '14

Jed Brown <jedbrown(a)mcs.anl.gov> writes: > Pavan Balaji <balaji(a)mcs.anl.gov> writes: >> This attribute is tested in configure before it’s added to mpi.h.in. > > Yes, the configure test is incorrect and the resulting usage in MPICH is > broken (does not do what you intend). As far as I know, #pragma weak MPI_Xyz = PMPI_Xyz is equivalent to what was intended with the attribute syntax __attribute__((weak, alias("PMPI_Xyz"))) (which belongs in an implementation file, not in the public header). Is there a reason to bother testing for the attribute syntax?

1 0