[Pw_forum] How to tune cputimes using mpich2-1.0.8

[Axel Kohlmeyer]

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.