<div dir="auto">When you say "as fast" do you mean for single core machines or multicore with threads and/or mpi? Almost everything slow in Wien2k is lapack/scalapack/elpa. For most parts of the code with 30-200 atom problems ifort is good but not as critical as the libraries and network.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 2, 2018, 16:05 Pavel Ondračka <<a href="mailto:pavel.ondracka@email.cz">pavel.ondracka@email.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
<br>
---------- Původní e-mail ----------<br>
Od: Fecher, Gerhard <<a href="mailto:fecher@uni-mainz.de" target="_blank" rel="noreferrer">fecher@uni-mainz.de</a>><br>
Komu: Pavel Ondračka <<a href="mailto:pavel.ondracka@email.cz" target="_blank" rel="noreferrer">pavel.ondracka@email.cz</a>>, <a href="mailto:wien@zeus.theochem.tuwien.ac.at" target="_blank" rel="noreferrer">wien@zeus.theochem.tuwien.ac.at</a> <<a href="mailto:wien@zeus.theochem.tuwien.ac.at" target="_blank" rel="noreferrer">wien@zeus.theochem.tuwien.ac.at</a>><br>
Datum: 2. 5. 2018 16:08:06<br>
Předmět: AW: [Wien] Installation with MPI and GNU compilers <br>
<blockquote>Dear Pavel, <br>
maybe it's better to ask Laurence, seems he was writing the VML things. <br>
<br>
I didn't look into the code within the last years, what I found on a fast look is:
<br>
<br>
The only place where the INTEL_VML is used any longer seems to be in Hamilt.f of LAPW1
<br>
I found that it is commented in all other cases where it was once used. <br>
<br>
If you don't use INTEL_VML, the INTEL ifort will vectorice the loops in vectf.f of LAPW1 (see code in Hamilt.f that calls it)
<br>
(as I mentioned, maybe one has to link the libsvml explicitely </blockquote>
<blockquote></blockquote>
<p> <br>
</p>
<blockquote></blockquote>
<p>BTW is svml part of the MKL or do you need the ifort for that? <br>
</p>
<blockquote><br>
For example <br>
-O2 -xHost -qopt-report=1 -qopt-report-phase=vec <br>
will show you which loops were vectorized</blockquote>
<p><br>
</p>
<p>Indeed, if I add the -O2 and -xHost to the default Wien2k flags (with ifort and MKL) there is no performance hit if I remove the -DINTEL_VML.</p>
<p><br>
</p>
<blockquote>I could not see that the svml has a reduced accuracy, however, you can set the performance/accuracy level in the VML.
<br>
What you can do is to set a threshhold for the loop size (similar to unroll), might need some short study of the manual.
</blockquote>
<p><br>
</p>
<p>Interesting, I will try to run some tests for the speed and accuracy of some basic trigonometric functions for ifort vs gfortran and standard glibc vs libmvec vs VML vs svml.<br>
</p>
<blockquote><br>
I could not see that in W2kinit.F a threshold for the loops (size of the arrays) was set,
<br>
only the precision was set there for the INTEL_VML script, however, <br>
I guess that Laurence used it where only large arrays appeared. <br>
<br>
NB: I enjoy more questions about how to increase the speed or how to improve the code.
</blockquote>
<p><br>
</p>
<p>Well,  I do believe that the code is well optimized when you have the ifort + MKL, however the rest of the options is a somewhat worse.</p>
<p><br>
</p>
<p>Since you can nowadays get the MKL library for free (but not the ifort) there is the combination of gfortran + MKL, which does not have any default config  and is slow as was reported by Rui in beginning of the thread. I'm quite sure this combination can
 be made almost as fast as the ifort + MKL (either by somewhat fixing the INTEL_VML define to fix the missing ifcore problem, or possibly by using the -mveclibabi=svml gfortran switch or some other trick). I'm not sure how many people have this setup though.
<br>
</p>
<p><br>
</p>
<p>The most problematic is the gfortran + OpenBLAS combination, where I was not able to force gfortran use the vectorized (SIMD) math. It works with C code (which is why my approach to making lapw1 fast includes porting the vectf.f to C) but not with Fortran.
 It is possible there is some way to make this work but I had no luck so far. The libmvec has a public interface so it might be possible to call it directly similarly to the VML, however it would introduce a lot of #ifdef LIBMVEC to the code which I guess is
 not a good idea. I would like to have this working better out of the box so I'll keep looking for some solution which would not require extensive changes in the code or siteconfig script. Dunno if the authors are accepting patches anyway...<br>
</p>
<p><br>
</p>
<p>Best regards</p>
<p>Pavel<br>
</p>
<p> </p>
<blockquote><br>
Ciao <br>
Gerhard <br>
<br>
DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy: <br>
"I think the problem, to be quite honest with you, <br>
is that you have never actually known what the question is." <br>
<br>
==================================== <br>
Dr. Gerhard H. Fecher <br>
Institut of Inorganic and Analytical Chemistry <br>
Johannes Gutenberg - University <br>
55099 Mainz <br>
and <br>
Max Planck Institute for Chemical Physics of Solids <br>
01187 Dresden <br>
________________________________________ <br>
Von: Pavel Ondračka [<a href="mailto:pavel.ondracka@email.cz" target="_blank" rel="noreferrer">pavel.ondracka@email.cz</a>] <br>
Gesendet: Mittwoch, 2. Mai 2018 12:05 <br>
An: Fecher, Gerhard <br>
Betreff: Re: [Wien] Installation with MPI and GNU compilers <br>
<br>
I'm using private answer since this might be getting too technical for <br>
the list and in fact not interesting for majority of users... <br>
<br>
Fecher, Gerhard píše v St 02. 05. 2018 v 09:00 +0000: <br>
> I never checked that: does the -DINTEL_VML switch correspond to the <br>
> VML library routines of MKL <br>
> or to the <br>
> SVML library routines of the compiler <br>
<br>
The lapw1 calls directly the VML library, for example the vdcos, vdsin <br>
functions, but I have not checked the rest of Wien2k. <br>
<br>
> this makes a difference, the svml routines are automatically invoked <br>
> by the INTEL compiler if one uses -O2 optimization or higher. <br>
> (check also the usage of the switches -vec, -no-vec, -vec-report) <br>
> <br>
> The VML routines of the MKL make only sense for appropriate sizes of <br>
> the vectors, otherwise, they may even slow down the program (how much <br>
> might also depend on threads etc.). <br>
<br>
The common usage of the VML in Wien2k is to call the VML functions with <br>
a _large_ array as an argument. So if I understand it correctly the <br>
vectorization is done inside the VML and the VML chooses the best <br>
intrinsic. Since the arrays are large, there is a speedup in all cases. <br>
<br>
BTW are you sure the -O2 switch alone will give you the svml <br>
intrinsic? IMO the svml intrinsic have different accuracy (might not be <br>
strictly IEEE compliant as compared to the scalar variants) so I would <br>
expect you need to specify it explicitly with some additional flag that <br>
you are OK with this (e.g. for GCC you need the -ffast-math switch to <br>
get the vectorized sse,avx goniometric fuctions from the libmvec). <br>
<br>
> A note (for the INTEL Fortran): <br>
> I vaguely remember that the -DINTEL_VML switch did not bring any <br>
> better performance, at that time one needed to give the -lsvml (with <br>
> path to the compiler libs) explicitely. <br>
> <br>
> Ciao <br>
> Gerhard <br>
> <br>
Best regards <br>
Pavel <br>
</blockquote>
</div>

</blockquote></div>