[Pw_forum] How to tune cputimes using mpich2-1.0.8

[Mahmoud Payami Shabestari]

Hi Axel,

> 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 [...].

It is the converse! I am trying to save the community's time. Here you are:
-------------------------------------------------------------
mpich2_with_those_switches_that_I_mentioned:

     PWSCF        :  9m46.25s CPU time,    12m 9.57s wall time
---------------------------------------------------------------
openmpi-1.2.9 (default switches):

     PWSCF        :  32m8.27s CPU time,    51m 23.38s wall time
----------------------------------------------------------------
These are the results of an scf calculation for 21-layered Al(110) slab
with Ecut=22Ry, k_mesh=45x45x1, degauss=0.05 on a box with 2 x amd64 quad
(8 cores).
The memory used in mpich2 is less than half of that in (default
switches)openmpi.

Cheers,
       mahmoud


>
> 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.