July 2009 - Mpich2-core - mailman3.cels.anl.gov

Re: [mpich2-core] f77 binding objects in libmpich.a
by chan＠mcs.anl.gov 14 Aug '09

14 Aug '09

----- "Dave Goodell" <goodell(a)mcs.anl.gov> wrote: > Is there a good technical reason why we put the object files for the > f77 binding into both libmpich.a and libfmpich.a? We currently don't > use the libfmpich.a version in the mpif77 wrapper script, although > Rajeev suspects that it might be used somewhere in MPE. Would there > be a _technical_ problem with removing those objects from libmpich.a > and adding -lfmpich to the link-line of the mpif77 wrapper script? MPE has its own version of libfmpich.a, called libmpe_f2cmpi.a, which is meant to be a more portable version. But once in a while when libmpe_f2cmpi.a has bug, MPE will use libfmpich.a (which is actually more complete than libmpe_f2cmpi.a). Also, some profiling tool does not have its fortran to C wrapper, it relies on the implemention to provide one and that is the reason for libfmpich.a's existence, e.g. fpmpi. AFAIK, the duplicated fortran object files in libmpich.a is for convenience. There are still users who do not like (or is not able) to use mpif77 and prefer to link the library themselve, link with one library, -lmpich, for fortran application is convenient for them. If I remember correctly, some older MPICH-1's mpif77 links with -lfmpich as well. > The backstory here is that one of our students this summer, Kumud, is > implementing parallel make. Part of those changes involve separating > ROMIO files out into a separate mpio.a that is added to the various > mpiXX wrappers. When the f77 bindings are included in libmpich.a this > causes a problem because they are to the right of -lmpio on the link > line and thus can't find most of the MPI-I/O symbols. > > Current mpif77 link line: $F77 $user_args -lmpich -lopa > Proposed mpif77 link line: $F77 $user_args -lfmpich -lmpio -lmpich > -lopa Besides the order issue that you mentioned, some applications out there depend on all MPI related object files to be in libmpich.a. Separating ROMIO object files into libmpio.a will likely break those applications' Makefile. I am OK with the idea separateing -lmpich as -lfmpich -lmpio -lmpich. BTW, if we do decide on breaking up libmpich.a, should libmpio be called libmpichio or libiompich just to be consistent with the existing naming convention. > The alternative is to repeat -lmpio/-lmpich as many times as are > needed to make the linker happy. I think this is quite a bit uglier > and would prefer the clear separation of the f77 binding library. Agreed. repeating multiple times of -lmpio/-lmpich is too ugly. If we cannot keep all MPI object files in -lmpich, separating them into -lfmpich -lmpio -lmpich seems to be only reasonable option. What is the reason that parallel make build needs to separate romio objects into -lmpio ? A.Chan

4 4

f77 binding objects in libmpich.a
by Dave Goodell 24 Jul '09

24 Jul '09

Is there a good technical reason why we put the object files for the f77 binding into both libmpich.a and libfmpich.a? We currently don't use the libfmpich.a version in the mpif77 wrapper script, although Rajeev suspects that it might be used somewhere in MPE. Would there be a _technical_ problem with removing those objects from libmpich.a and adding -lfmpich to the link-line of the mpif77 wrapper script? Before going and making this sort of change, I want to make sure that there aren't any Fortran eccentricities that I've never heard of here. There might be other reasons that we put them there, including habit/ history and user convenience for users that don't use our wrapper scripts. But I'm mostly concerned about any technical issues that I don't know about. This is already what we do for Fortran90 so I would be surprised if this was an issue, but of course f77!=f90. The backstory here is that one of our students this summer, Kumud, is implementing parallel make. Part of those changes involve separating ROMIO files out into a separate mpio.a that is added to the various mpiXX wrappers. When the f77 bindings are included in libmpich.a this causes a problem because they are to the right of -lmpio on the link line and thus can't find most of the MPI-I/O symbols. Current mpif77 link line: $F77 $user_args -lmpich -lopa Proposed mpif77 link line: $F77 $user_args -lfmpich -lmpio -lmpich -lopa The alternative is to repeat -lmpio/-lmpich as many times as are needed to make the linker happy. I think this is quite a bit uglier and would prefer the clear separation of the f77 binding library. -Dave

1 0

OpenCL
by Rajeev Thakur 22 Jul '09

22 Jul '09

I am able to run OpenCL programs, including running them as MPI + OpenCL, but OpenCL is hopelessly ugly as a programming language for end users. It takes a 150 lines of extra junk to run a simple OpenCL kernel, whereas it takes only 4 lines to do it in CUDA (not that CUDA is a great language either). See attached example from the OpenCL spec. The dot product kernel is a few lines of code, followed by 3 pages of additional stuff needed just to run it. OpenCL examples fron NVIDIA are in ~thakur/OpenCl-1.0/OpenCL/src on breadboard. oclVectorAdd is the one I added some MPI too. Rajeev

1 0

mpich2-1.1.1 tarball sanity check
by Dave Goodell 21 Jul '09

21 Jul '09

OK, per discussion with Rajeev and Pavan, I have cut a release tarball for v1.1.1. You can download it here: http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/1.1.1/mp… As with the rc1 tarball, please sanity check this tarball to make sure nothing really obvious is broken. We won't release this to the rest of the world until tomorrow after we've had a run of nightly tests and we've given Jayesh enough time to generate Windows binaries. -Dave

3 4

Misplaced brackets in romio configure
by Jayesh Krishna 20 Jul '09

20 Jul '09

Rob, Looks like misplaced brackets to me... Let me know if itz ok and I can commit it in... $ svn diff Index: src/mpi/romio/configure.in =================================================================== --- src/mpi/romio/configure.in (revision 4997) +++ src/mpi/romio/configure.in (working copy) @@ -1991,7 +1991,7 @@ AC_CHECK_FUNCS(lseek64) if test "$ac_cv_func_lseek64" = "yes" ; then - PAC_FUNC_NEEDS_DECL([#include <unistd.h>, lseek64]) + PAC_FUNC_NEEDS_DECL([#include <unistd.h>],lseek64) fi # # Create the directory lists for the Makefile -Jayesh

2 1

mpich2-1.1.1rc1 tarball sanity checking
by Dave Goodell 20 Jul '09

20 Jul '09

I've created an mpich2-1.1.1rc1 tarball and placed it in the web space. I haven't linked to it yet from the website or announced it on any of the lists. I've personally sanity checked it on my Mac, but we could probably use a quick look-over from others before officially releasing it. Also, I'll coordinate with Jayesh about windows binaries. You can get the RC from here: http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/1.1.1rc1… -Dave

3 20

mpich2 code freeze tonight
by Dave Goodell 16 Jul '09

16 Jul '09

We've only got a couple of open bugs left for the 1.1.1 release [1]. One of them I believe is already fixed, so I'm just waiting for Anthony to confirm that. RobL just agreed to fix the other bug (lseek64 on FreeBSD) today. I know Jayesh also has an SMPD change that he will commit by the end of the day. Other than the three things mentioned above, does anyone have anything else important pending for the 1.1.1 release? If not, I'd like us to freeze the code base this evening so that we can hopefully release 1.1.1 either tomorrow or Monday. Any objections? -Dave [1] https://trac.mcs.anl.gov/projects/mpich2/report/11

2 2

First MPI+CUDA program
by Rajeev Thakur 16 Jul '09

16 Jul '09

OK, I wrote my first MPI+CUDA program (attached). I took the simple CUDA example from the NVIDIA tutorial that adds two vectors on the GPU. I added MPI around it so that each process does its local computation and at the end rank 0 broadcasts a "Done" message to other processes, who print it out. They also do a barrier at the end. The vector addition is not distributed among the processes yet, but that can be easily done since MPI communication is working. I built MPICH2 with CC set to nvcc. Nothing special was needed. Even the Fortran interface and everything else got built as usual. Just compiled the program as mpicc vecadd.cu and ran as mpiexec -n 4 a.out. It works. My next step is to port the MPICH2 cpi example to CUDA, i.e., doing the local pi computation in CUDA. Rajeev

2 1

Is trac working fine ?
by Jayesh Krishna 16 Jul '09

16 Jul '09

I am not able to access trac and my ticket update email was not sent. Is anyone else having this problem ? -Jayesh

1 0

spotty SVN history
by Dave Goodell 15 Jul '09

15 Jul '09

Watch your SVN interactions today very carefully. Systems has upgraded the SVN server (and trac) to new versions, but they seem to have lost and/or mangled some history in the process. For example, I committed r4954 against trunk at 2009-07-13 15:26:57 and it doesn't appear correctly in the svn history anymore. Instead it ends up showing me change a commit by Kumud (r4907) on the "kumudb" dev branch. At least, it shows me the log message for that commit. It doesn't have any diff for the whole repository for that change. If you try to view the same changeset from the trac website [1] it shows you the right message, but it again thinks that no files or properties changed. I know this change was originally recorded correctly because I have a commit email that shows the property change occurring. Ken is still out at lunch, but I'm planning to follow up with him about this once he returns. In the mean time, I should be able to answer revision history questions accurately from my local git-svn repository as long as you don't need to know about any property changes (including svn:externals). Feel free to ask if you want to double-check an svn query. -Dave [1] https://trac.mcs.anl.gov/projects/mpich2/changeset/4954

2 3