Re: [CMake] History and ideas behind FindMPI.cmake?
Michael, You make good points. I will look into the Module you list below. Thanks, - Ross > -Original Message- > From: Michael Wild [mailto:them...@gmail.com] > Sent: Wednesday, January 14, 2009 2:43 AM > To: Bartlett, Roscoe A > Cc: cmake@cmake.org > Subject: Re: [CMake] History and ideas behind FindMPI.cmake? > > > On 13. Jan, 2009, at 15:17, Bartlett, Roscoe A wrote: > > > > In Trilinos, an MPI configured build creates all MPI > executables (in > > some sense). Also, most Trilinos software is set up to > automatically > > check to see if MPI is initialized or not and will run correctly in > > serial mode with MPI enabled but not initialized. > > > > Also, most newer MPI implementations that I have used allow you to > > build with MPI support but never call MPI_Init(...) and > never have to > > use mpiexec/mpirun in order to run a serial executable (as > long as you > > don't call MPI functions). That is how you can get away > with defining > > CMAKE_[C,CXX,Fortran]_COMPILER as the MPI compiler > wrappers. Also, if > > you only use try_compile(...) tests at configure time, then > you will > > never have any problem with this. Even with try_run(...), > as long as > > these tests don't call MPI functions then they should work > just fine > > also with most newer MPI implementations. > > > > Lastly, our project Trilinos does not really define *any* > executables > > except for tests and examples. To set up even single- process > > tests/examples to work with MPI is trivial. There is a > single object > > that you have to create in main(...) like: > > > > Teuchos::GlobalMPISession mpiSession(&argc, &argv); > > > > and you just have to run the test/example with > mpirun/mpiexec with one > > process in case your MPI implementation requires that you do so. > > > > The C++ class Teuchos::GlobalMPISession works with both MPI > and non- > > MPI enabled software. > > That might be true for Trilinos, but not necessarily for > other projects. I can easily imagine a project where the main > executable/ library is built using MPI, but some > helper/utility programs are not. > There is no point in linking them against MPI. This not only > makes startup slower, but also increases memory footprint. In > some cases it might even be harmful. > > > > > > >>> 4) The standard MPI install structure of many MPI implementations > >>> (e.g. MPICH, OpenMPI, LAM MPI etc.) of prefix/[include, > >> bin] will be > >>> exploited and searching from MPI_BASE_DIR (which is set by the > >>> client) will be done. In this way, you can just set a > single cache > >>> variable on most systems and get MPI totally set up. > >> > >> This won't work at all. See the --includedir and --libdir > options of > >> the OpenMPI configure script. Your proposal will force > these values > >> to the default, making too many assumptions. > > > > You misunderstood. This would not require that MPI must be > installed > > in PREFIX/[include, bin, lib] but if it is, then the user > could just > > give the base directory. It is not hard to set this up at > all and I > > am surprised that the other CMake find modules don't do this. > > However, if we are going to just use mpicc/mpiCC/mpiC++/ > > mpif77 etc and mpirun/mpiexec then we just need the 'bin' directory > > and can thrown the rest of this out. > > > It's not necessary. The user can define CMAKE_PREFIX_PATH and > this has the effect you want. > > > > > > > >>> These days, I don't know if anyone still uses raw compilers > >> and then > >>> tries to manually pass in the compiler options and link > >> libraries. > >>> We can still support such a thing but I think this is the > >> 1% exception > >>> instead of the rule. Am I wrong about this? > >> > >> I know of at least one large project which does not use > the wrappers > >> because the developers abstracted the communications into separate > >> libraries, one for MPI, one for GAMMA and one for LVM. The > user has > >> then the choice of which library should be used when he starts the > >> program. Couldn't do that with your proposal. > > > > Is this a runtime option or a configure-time option in this "large > > project"? If it is a runtime option, then you have to at > least b
Re: [CMake] History and ideas behind FindMPI.cmake?
On 13. Jan, 2009, at 15:17, Bartlett, Roscoe A wrote: In Trilinos, an MPI configured build creates all MPI executables (in some sense). Also, most Trilinos software is set up to automatically check to see if MPI is initialized or not and will run correctly in serial mode with MPI enabled but not initialized. Also, most newer MPI implementations that I have used allow you to build with MPI support but never call MPI_Init(...) and never have to use mpiexec/mpirun in order to run a serial executable (as long as you don't call MPI functions). That is how you can get away with defining CMAKE_[C,CXX,Fortran]_COMPILER as the MPI compiler wrappers. Also, if you only use try_compile(...) tests at configure time, then you will never have any problem with this. Even with try_run(...), as long as these tests don't call MPI functions then they should work just fine also with most newer MPI implementations. Lastly, our project Trilinos does not really define *any* executables except for tests and examples. To set up even single- process tests/examples to work with MPI is trivial. There is a single object that you have to create in main(...) like: Teuchos::GlobalMPISession mpiSession(&argc, &argv); and you just have to run the test/example with mpirun/mpiexec with one process in case your MPI implementation requires that you do so. The C++ class Teuchos::GlobalMPISession works with both MPI and non- MPI enabled software. That might be true for Trilinos, but not necessarily for other projects. I can easily imagine a project where the main executable/ library is built using MPI, but some helper/utility programs are not. There is no point in linking them against MPI. This not only makes startup slower, but also increases memory footprint. In some cases it might even be harmful. 4) The standard MPI install structure of many MPI implementations (e.g. MPICH, OpenMPI, LAM MPI etc.) of prefix/[include, bin] will be exploited and searching from MPI_BASE_DIR (which is set by the client) will be done. In this way, you can just set a single cache variable on most systems and get MPI totally set up. This won't work at all. See the --includedir and --libdir options of the OpenMPI configure script. Your proposal will force these values to the default, making too many assumptions. You misunderstood. This would not require that MPI must be installed in PREFIX/[include, bin, lib] but if it is, then the user could just give the base directory. It is not hard to set this up at all and I am surprised that the other CMake find modules don't do this. However, if we are going to just use mpicc/mpiCC/mpiC++/ mpif77 etc and mpirun/mpiexec then we just need the 'bin' directory and can thrown the rest of this out. It's not necessary. The user can define CMAKE_PREFIX_PATH and this has the effect you want. These days, I don't know if anyone still uses raw compilers and then tries to manually pass in the compiler options and link libraries. We can still support such a thing but I think this is the 1% exception instead of the rule. Am I wrong about this? I know of at least one large project which does not use the wrappers because the developers abstracted the communications into separate libraries, one for MPI, one for GAMMA and one for LVM. The user has then the choice of which library should be used when he starts the program. Couldn't do that with your proposal. Is this a runtime option or a configure-time option in this "large project"? If it is a runtime option, then you have to at least build in support for MPI so using the MPI compiler wrappers is just fine. If it is a configure-time option, then you can configure with and without MPI. That is exactly what Trilinos does. You can build a serial version of Trilinos with and without MPI. If there was some other great communication layer we could also wrap that and use that with most of Trilinos (most of Trilinos uses thin abstract adapters for communication and is not directly tied to MPI). It is a runtime option. Before you start a solver you can choose which implementation of the communications library you want. One of the reasons I don't like linking against all possible parallel communications libraries is our heterogeneous cluster. On some compute nodes PVM is available, but not MPI and vice versa. There are also differenc MPI implementations around (OpenMPI, Quadrics, etc.) The queueing system automagically submits the job to the right queue. Problem is now, that if e.g. everything is linked against OpenMPI but is submitted to a queue where only PVM or Quadrics MPI is installed, the program won't even start. If you really want to use an MPI compiler for everything, then you could use the following FindMpiCompilers.cmake module I came up with: # - Find the MPI compiler wrappers # This module locates the MPI compiler wrappers (mpicc, mpicx
Re: [CMake] History and ideas behind FindMPI.cmake?
Brad, Thanks for the clarifications. Note that MPI is unique in that it specifics how main(...) must be written and how to run programs on the command-line. I can't think of any other library that does this (except perhaps other message passing standards). - Ross > -Original Message- > From: Brad King [mailto:brad.k...@kitware.com] > Sent: Tuesday, January 13, 2009 11:22 AM > To: Bartlett, Roscoe A > Cc: alin.el...@qub.ac.uk; cmake@cmake.org > Subject: Re: [CMake] History and ideas behind FindMPI.cmake? > > Alin M Elena wrote: > > Do you really need an module for MPI? > > > > All you need is to set the normal shell variables for > compilers to the > > MPI wrappers. > > You need both mpi and non-mpi binaries just use different > build folders. > > Alin is correct. If the project works with an all-MPI build > you can just specify mpicc as the compiler (and similarly for > C++). If anything in CMake prevents this from working we can > address the specific issue. > The FindMPI module is useful for mixed projects that want > some MPI and some non-MPI binaries in the same tree. > > AFAIK the MPI compiler wrappers are provided to help > non-software people (who may not understand ABIs, library > search paths, etc.) use MPI. If every library took this > approach it would be impossible to use more than one library. > Imagine if zlib required one to use zlibcc to link to it. > There is nothing wrong with using MPI libraries directly so > long as the proper compiler flags are found. Teaching > FindMPI how to do this for all MPI distributions may take > some work but is not a wrong approach. > > The current FindMPI module is one of the oldest find-modules in CMake. > It has mostly been updated minimally as necessary for the > needs of folks willing to contribute their changes back to > us. No one has taken the time to contribute a thorough treatment. > > -Brad > > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] History and ideas behind FindMPI.cmake?
Alin M Elena wrote: > Do you really need an module for MPI? > > All you need is to set the normal shell variables for compilers to the MPI > wrappers. > You need both mpi and non-mpi binaries just use different build folders. Alin is correct. If the project works with an all-MPI build you can just specify mpicc as the compiler (and similarly for C++). If anything in CMake prevents this from working we can address the specific issue. The FindMPI module is useful for mixed projects that want some MPI and some non-MPI binaries in the same tree. AFAIK the MPI compiler wrappers are provided to help non-software people (who may not understand ABIs, library search paths, etc.) use MPI. If every library took this approach it would be impossible to use more than one library. Imagine if zlib required one to use zlibcc to link to it. There is nothing wrong with using MPI libraries directly so long as the proper compiler flags are found. Teaching FindMPI how to do this for all MPI distributions may take some work but is not a wrong approach. The current FindMPI module is one of the oldest find-modules in CMake. It has mostly been updated minimally as necessary for the needs of folks willing to contribute their changes back to us. No one has taken the time to contribute a thorough treatment. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] History and ideas behind FindMPI.cmake?
> -Original Message- > From: Michael Wild [mailto:them...@gmail.com] > Sent: Monday, January 12, 2009 10:57 PM > To: Bartlett, Roscoe A > Cc: cmake@cmake.org > Subject: Re: [CMake] History and ideas behind FindMPI.cmake? > > > I am seriously considering completely writing our own version of > > FindMPI.cmake for Trilinos (called FindTPLMPI.cmake). The major > > features of a new MPI find module would be: > > > > 1) It will differentiate C, C++, and Fortran MPI compilers > > > > 2) It will keep the MPI compilers intact and not try to extract out > > compile options and MPI libraries. > > > > 3) The MPI compilers will automatically be set as > > CMAKE_[C,CXX,Fortran]_COMPILER *before* the languages are > enabled and > > the compilers are checked. This will make sure that every > bit of code > > is built and linked in a consistent way (including during > the various > > configure-time checks). The trouble that you might have is with > > try_run(...) commands and some MPI implementations that require an > > explicit boot (like LAM MPI). Most MPI implementations > allow you to > > just run the executable without mpirun or mpiexec and it will run > > correctly for a single process. > > I consider this to be a "buggy" idea. It would be impossible > to have a project which builds both normal and MPI > executables. I would probably prefer a target property called > "MPI" which can be set to TRUE if one wants to compile a > specific target with MPI. In Trilinos, an MPI configured build creates all MPI executables (in some sense). Also, most Trilinos software is set up to automatically check to see if MPI is initialized or not and will run correctly in serial mode with MPI enabled but not initialized. Also, most newer MPI implementations that I have used allow you to build with MPI support but never call MPI_Init(...) and never have to use mpiexec/mpirun in order to run a serial executable (as long as you don't call MPI functions). That is how you can get away with defining CMAKE_[C,CXX,Fortran]_COMPILER as the MPI compiler wrappers. Also, if you only use try_compile(...) tests at configure time, then you will never have any problem with this. Even with try_run(...), as long as these tests don't call MPI functions then they should work just fine also with most newer MPI implementations. Lastly, our project Trilinos does not really define *any* executables except for tests and examples. To set up even single-process tests/examples to work with MPI is trivial. There is a single object that you have to create in main(...) like: Teuchos::GlobalMPISession mpiSession(&argc, &argv); and you just have to run the test/example with mpirun/mpiexec with one process in case your MPI implementation requires that you do so. The C++ class Teuchos::GlobalMPISession works with both MPI and non-MPI enabled software. > > 4) The standard MPI install structure of many MPI implementations > > (e.g. MPICH, OpenMPI, LAM MPI etc.) of prefix/[include, > bin] will be > > exploited and searching from MPI_BASE_DIR (which is set by the > > client) will be done. In this way, you can just set a single cache > > variable on most systems and get MPI totally set up. > > This won't work at all. See the --includedir and --libdir > options of the OpenMPI configure script. Your proposal will > force these values to the default, making too many assumptions. You misunderstood. This would not require that MPI must be installed in PREFIX/[include, bin, lib] but if it is, then the user could just give the base directory. It is not hard to set this up at all and I am surprised that the other CMake find modules don't do this. However, if we are going to just use mpicc/mpiCC/mpiC++/mpif77 etc and mpirun/mpiexec then we just need the 'bin' directory and can thrown the rest of this out. > > These days, I don't know if anyone still uses raw compilers > and then > > tries to manually pass in the compiler options and link > libraries. > > We can still support such a thing but I think this is the > 1% exception > > instead of the rule. Am I wrong about this? > > I know of at least one large project which does not use the > wrappers because the developers abstracted the communications > into separate libraries, one for MPI, one for GAMMA and one > for LVM. The user has then the choice of which library should > be used when he starts the program. Couldn't do that with > your proposal. Is this a runtime option or a configure-time option in this "large project"? If it is a runtime option, then you have to at least build in support for MPI
Re: [CMake] History and ideas behind FindMPI.cmake?
Hi, Do you really need an module for MPI? All you need is to set the normal shell variables for compilers to the MPI wrappers. You need both mpi and non-mpi binaries just use different build folders. Alin -- __ "If the Universities will not study useless subjects, who will?" G. F. Fitzgerald, Nature, 45/46, 392 (1892) __ Mr. Alin M. ELENA Atomistic Simulation Centre School of Mathematics and Physics Queen's University Belfast Office: +44 (0)28 9097 1428 Fax: +44 (0)28 9097 5359 http://titus.phy.qub.ac.uk/group/Alin/ alin.el...@yahoo.co.uk alin.el...@qub.ac.uk __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] History and ideas behind FindMPI.cmake?
On 12. Jan, 2009, at 23:02, Bartlett, Roscoe A wrote: Hello, What is the origin of the current FindMPI.cmake module? I am not very happy with this module and I don't even fully understand why is was written the way that it is. I agree, it is not very robust. But I'd like to point out a few things: I am seriously considering completely writing our own version of FindMPI.cmake for Trilinos (called FindTPLMPI.cmake). The major features of a new MPI find module would be: 1) It will differentiate C, C++, and Fortran MPI compilers 2) It will keep the MPI compilers intact and not try to extract out compile options and MPI libraries. 3) The MPI compilers will automatically be set as CMAKE_[C,CXX,Fortran]_COMPILER *before* the languages are enabled and the compilers are checked. This will make sure that every bit of code is built and linked in a consistent way (including during the various configure-time checks). The trouble that you might have is with try_run(...) commands and some MPI implementations that require an explicit boot (like LAM MPI). Most MPI implementations allow you to just run the executable without mpirun or mpiexec and it will run correctly for a single process. I consider this to be a "buggy" idea. It would be impossible to have a project which builds both normal and MPI executables. I would probably prefer a target property called "MPI" which can be set to TRUE if one wants to compile a specific target with MPI. 4) The standard MPI install structure of many MPI implementations (e.g. MPICH, OpenMPI, LAM MPI etc.) of prefix/[include, bin] will be exploited and searching from MPI_BASE_DIR (which is set by the client) will be done. In this way, you can just set a single cache variable on most systems and get MPI totally set up. This won't work at all. See the --includedir and --libdir options of the OpenMPI configure script. Your proposal will force these values to the default, making too many assumptions. These days, I don't know if anyone still uses raw compilers and then tries to manually pass in the compiler options and link libraries. We can still support such a thing but I think this is the 1% exception instead of the rule. Am I wrong about this? I know of at least one large project which does not use the wrappers because the developers abstracted the communications into separate libraries, one for MPI, one for GAMMA and one for LVM. The user has then the choice of which library should be used when he starts the program. Couldn't do that with your proposal. Michael ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] History and ideas behind FindMPI.cmake?
On Mon, Jan 12, 2009 at 13:02, Bartlett, Roscoe A wrote: > Does anyone else have similar frustrations with FindMPI.cmake and would like > to see a new implementation as described above? How many CMake projects > have a serious MPI component that use FindMPI.cmake? I make do with the current implementation, but it is a bit brittle and I would prefer the implementation you describe. I suspect the history comes from regarding MPI as `just another library' in which case wrapper compilers are not desirable since you can't combine wrappers. Some will surely disagree, but I'm happy to give MPI special priority. Jed ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] History and ideas behind FindMPI.cmake?
Hello, What is the origin of the current FindMPI.cmake module? I am not very happy with this module and I don't even fully understand why is was written the way that it is. Specific issues that I have are: 1) It does not really take advantage of MPI compiler wrappers like it should. The whole purpose of having an MPI compiler wrapper is to avoid having to explicitly match up the C/C++/Fortran compilers, get the compiler flags, and list the link libraries. Trying to match the raw C, C++, and Fortran compilers with the MPI compiler wrappers is asking for trouble and will result in subtle bugs. 2) It does not provide or differentiate C, C++, and Fortran compilers. It just specifies MPI_COMPILER. Is that a C or C++ compiler? This matter to many projects. 3) Getting MPI setup when it is in a non-standard location is very hard (or at least I have not figured out the easy way). I am seriously considering completely writing our own version of FindMPI.cmake for Trilinos (called FindTPLMPI.cmake). The major features of a new MPI find module would be: 1) It will differentiate C, C++, and Fortran MPI compilers 2) It will keep the MPI compilers intact and not try to extract out compile options and MPI libraries. 3) The MPI compilers will automatically be set as CMAKE_[C,CXX,Fortran]_COMPILER *before* the languages are enabled and the compilers are checked. This will make sure that every bit of code is built and linked in a consistent way (including during the various configure-time checks). The trouble that you might have is with try_run(...) commands and some MPI implementations that require an explicit boot (like LAM MPI). Most MPI implementations allow you to just run the executable without mpirun or mpiexec and it will run correctly for a single process. 4) The standard MPI install structure of many MPI implementations (e.g. MPICH, OpenMPI, LAM MPI etc.) of prefix/[include, bin] will be exploited and searching from MPI_BASE_DIR (which is set by the client) will be done. In this way, you can just set a single cache variable on most systems and get MPI totally set up. These days, I don't know if anyone still uses raw compilers and then tries to manually pass in the compiler options and link libraries. We can still support such a thing but I think this is the 1% exception instead of the rule. Am I wrong about this? Does anyone else have similar frustrations with FindMPI.cmake and would like to see a new implementation as described above? How many CMake projects have a serious MPI component that use FindMPI.cmake? Cheers, - Ross ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
