<div dir="ltr"><div>FFTW3 library only have a few functions thread-safe <a href="http://www.fftw.org/doc/Thread-safety.html">http://www.fftw.org/doc/Thread-safety.html</a></div><div>I think MKL FFTW3 and DFTI interfaces should be no worse than that.</div><div><br></div><div>Anyway, QE DFTI route doesn't call DFTI functions inside explicitly OpenMP threaded regions and instead rely on the internal threading capability of threaded MKL to do batched 1D FFT.</div><div></div><div>This is a safe.<br></div><div>QE with OpenMP turned on + DFTI from threaded MKL should work solid.<br></div><div>If you find any threading issue, it may be a bug and we need to investigate.</div><div><br></div><div>Best,<br></div><div>Ye<br></div><div><div><div><div dir="ltr" class="m_2402304707356949062gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">===================<br>
Ye Luo, Ph.D.<br>Computational Science Division & Leadership Computing Facility<br>
Argonne National Laboratory</div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Lorenzo Paulatto <<a href="mailto:paulatz@gmail.com" target="_blank">paulatz@gmail.com</a>> 于2019年9月17日周二 上午1:44写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We have three things:<br>
1. Intel fourier transform library DFTI<br>
2. Intel fourier transform library with FFTW3-like interface in <br>
MKLROOT/interfaces/fft3xf<br>
3. Internal FFTW2 or system FFTW3 open-source library<br>
<br>
From what I've see, performance wise<br>
1 is faster 2 is faster than 3<br>
<br>
But 1 is not thread safe, hence not compatible with openmp<br>
<br>
cheers<br>
<br>
<br>
On 9/16/19 5:33 PM, Ye Luo wrote:<br>
> I got a bit confused. When you say FFTW, did you it mean the FFTW3 <br>
> library or the internal FFTW shipped with QE?<br>
> <br>
> DFTI vs FFTW3 on intel platforms<br>
> Intel claimed comparable performance using DFTI and FFTW3 interfaces <br>
> provided by MKL.<br>
> But QE with DFTI outperforms FFTW3 in both absolute performance and <br>
> thread salability.<br>
> <br>
> I never did a comparison between MKL DFT and <a href="http://fftw.org" rel="noreferrer" target="_blank">fftw.org</a> <<a href="http://fftw.org" rel="noreferrer" target="_blank">http://fftw.org</a>> <br>
> FFTW3 on Intel platforms.<br>
> <br>
> Best,<br>
> <br>
> Ye<br>
> ===================<br>
> Ye Luo, Ph.D.<br>
> Computational Science Division & Leadership Computing Facility<br>
> Argonne National Laboratory<br>
> <br>
> <br>
> Lorenzo Paulatto <<a href="mailto:paulatz@gmail.com" target="_blank">paulatz@gmail.com</a> <mailto:<a href="mailto:paulatz@gmail.com" target="_blank">paulatz@gmail.com</a>>> 于2019年 <br>
> 9月16日周一 上午4:18写道：<br>
> <br>
> Ok, I answer to myself: using DFTI with openmp causes mysterious<br>
> problems usually using diagonalization. Do you know if using the Intel<br>
> FFTW interface would work around these or if it is exactly the same<br>
> thing? Because, the little bit of scalability that I can gain from<br>
> openmp is exactly lost by the performance I loose with FFTW3 wrt DFTI...<br>
> <br>
> cheers<br>
> <br>
> On 16/09/2019 10:30, Lorenzo Paulatto wrote:<br>
> > Hello,<br>
> > I have noticed that the configure script detects and enables<br>
> > automatically the DFTI FFT libraries when executed without any<br>
> specific<br>
> > switch, but that it uses FFTW instead when executed with the<br>
> > --enable-openmp switch.<br>
> ><br>
> > I was wondering if this is intentional (i.e. because FFTW can give<br>
> > better performance with openmp? Or DFTI does not work with<br>
> openmp?) or<br>
> > it is a bug.<br>
> ><br>
> > cheers<br>
> ><br>
> <br>
> -- <br>
> Dr. Lorenzo Paulatto<br>
> IdR @ IMPMC - CNRS UMR 7590 & Sorbonne Université<br>
> phone: +33 (0)1 442 79822 / skype: paulatz<br>
> <<a href="http://www.impmc.upmc.fr/~paulatto/" rel="noreferrer" target="_blank">http://www.impmc.upmc.fr/~paulatto/</a>> <<a href="http://sf.net/p/d3q" rel="noreferrer" target="_blank">http://sf.net/p/d3q</a>><br>
> 23-24/423 B115, 4 place Jussieu 75252 Paris CX 05<br>
> <br>
> -- <br>
> Lorenzo Paulatto - Paris<br>
> _______________________________________________<br>
> developers mailing list<br>
> <a href="mailto:developers@lists.quantum-espresso.org" target="_blank">developers@lists.quantum-espresso.org</a><br>
> <mailto:<a href="mailto:developers@lists.quantum-espresso.org" target="_blank">developers@lists.quantum-espresso.org</a>><br>
> <a href="https://lists.quantum-espresso.org/mailman/listinfo/developers" rel="noreferrer" target="_blank">https://lists.quantum-espresso.org/mailman/listinfo/developers</a><br>
> <br>
> <br>
> _______________________________________________<br>
> developers mailing list<br>
> <a href="mailto:developers@lists.quantum-espresso.org" target="_blank">developers@lists.quantum-espresso.org</a><br>
> <a href="https://lists.quantum-espresso.org/mailman/listinfo/developers" rel="noreferrer" target="_blank">https://lists.quantum-espresso.org/mailman/listinfo/developers</a><br>
> <br>
<br>
-- <br>
Lorenzo Paulatto - Paris<br>
_______________________________________________<br>
developers mailing list<br>
<a href="mailto:developers@lists.quantum-espresso.org" target="_blank">developers@lists.quantum-espresso.org</a><br>
<a href="https://lists.quantum-espresso.org/mailman/listinfo/developers" rel="noreferrer" target="_blank">https://lists.quantum-espresso.org/mailman/listinfo/developers</a><br>
</blockquote></div></div></div>