<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Dear Davide,<div><br></div><div> it might be a memory-contention problem, since CPU cache sizes are of the order of a few MB. Please provide the detailed timings at the end of the runs (that are the first thing one should look at in order to interpret these kind of speedup tests).</div><div><br></div><div>Next time please take a few seconds to sign your post using full name and affiliation.</div><div><br></div><div>Regards,</div><div><br></div><div>GS</div><div><br></div><div><br><div><div>Il giorno 14/feb/2011, alle ore 12.18, Davide Sangalli ha scritto:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Thank you for the answer.<br><br>I did a check to be sure, but these jobs use only few MB of memory.<br>The serial run uses just 2.5% of my node memory (so around 15% for the <br>run on 6 CPUs).<br>It does not seems to me that this could be the problem.<br>Moreover in the fft parallelization the memory was not distributed neither.<br><br>Is it possible that pwscf is not properly compiled?<br>Is there any other check that you would suggest to do?<br><br>Best regards,<br>Davide<br><br>*************************************<br> Largest allocated arrays est. size (Mb) dimensions<br> Kohn-Sham Wavefunctions 5.68 Mb ( 6422, 58)<br> NL pseudopotentials 13.33 Mb ( 6422, 136)<br> Each V/rho on FFT grid 7.81 Mb ( 512000)<br> Each G-vector array 1.76 Mb ( 230753)<br> G-vector shells 0.09 Mb ( 12319)<br> Largest temporary arrays est. size (Mb) dimensions<br> Auxiliary wavefunctions 22.73 Mb ( 6422, 232)<br> Each subspace H/S matrix 0.82 Mb ( 232, 232)<br> Each <psi_i|beta_j> matrix 0.12 Mb ( 136, 58)<br> Arrays for rho mixing 62.50 Mb ( 512000, 8)<br> writing wfc files to a dedicated directory<br><br><br>On 02/14/2011 11:34 AM, Paolo Giannozzi wrote:<br><blockquote type="cite">Davide Sangalli wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">What could my problem be?<br></blockquote></blockquote><blockquote type="cite">the only reason I can think of is that k-point parallelization doesn't<br></blockquote><blockquote type="cite">(and cannot) distribute memory, so the total memory requirement will<br></blockquote><blockquote type="cite">be npools*(size of serial execution). If you run on the same node six<br></blockquote><blockquote type="cite">instances of a large executable, memory conflicts may slow down more<br></blockquote><blockquote type="cite">than parallelization can speed up.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">P.<br></blockquote>_______________________________________________<br>Pw_forum mailing list<br><a href="mailto:Pw_forum@pwscf.org">Pw_forum@pwscf.org</a><br>http://www.democritos.it/mailman/listinfo/pw_forum<br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><span class="Apple-style-span" style="color: rgb(126, 126, 126); font-size: 16px; font-style: italic; "><br class="Apple-interchange-newline">§ Gabriele Sclauzero, EPFL SB ITP CSEA</span></div><div><font class="Apple-style-span" color="#7E7E7E"><i> PH H2 462, Station 3, CH-1015 Lausanne</i></font></div></span>
</div>
<br></div></body></html>