On Sat, 21 Feb 2009, Mahmoud Payami Shabestari wrote:
MP> Hi All, MP> I am trying to configure mpich2-1.0.8 for the best performance and perhaps MP> comparison with openmpi-1.2.9 (openmpi-1.3 is still somehow unstable). MP> In making mpich2, I used: MP> FC=ifort F77=ifort F90=ifort ./configure --enable-fast --enable-sharedlibs=gcc MP> MP> Are these the right switches to make mpich2 performance as close as MP> possible to that of openmpi? mahmoud, you should ask that the people developing MPICH2. this is not the right forum for this kind of question. one more remark. that might also help people here not to waste too much time on something pointless. in general, it is not a good idea to try an play with compiler optimization in the hope to make an MPI implementation (and thus communication) faster. if your application performance would depend so much on the optimization level use to compile your MPI library, then either you have a very crappy MPI implementation, or your application spends too much time in MPI calls. in the latter case, that usually corresponds to severe overload of your communication hardware and taking care of that would give you a much better performance increase than any compiler switches will. basically for almost _any_ system library (and that includes ATLAS and FFTW, btw) it is best to stick to a moderate optimization (-O) as aggressive optimization may interfere with the implemented algorithms and existing optimizations (e.g. both ATLAS and FFTW include optimizations on the C-language and algorithm level, higher compiler optimization can change the semantics of your code and thus negate the optimizations performed in the code). even more so, with many current compilers, aggressive optimization (-O3 or higher) incures a very high risk of the compiler miscompiling your library and thus leading to uncontrollable crashes or wrong results. that doesn't mean, that there may be a measurable benefit for singular cases, but from over 10 years of experience in management of HPC resources the overall effect is problematic. most of the time it is hard enough to chase down application bugs that are real or cause by compilers, you don't want to add having to track down problems in your libraries to that. cheers, axel. MP> Any comment is highly appreciated. MP> MP> Best regards, MP> Mahmoud Payami MP> Phys. Group, MP> Atomic Energy Org. of Iran MP> MP> _______________________________________________ MP> Pw_forum mailing list MP> Pw_forum at pwscf.org MP> http://www.democritos.it/mailman/listinfo/pw_forum MP> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot.
