<div dir="ltr">These problems are why I suggested making a wrapper script. I don't know why vtcc and vtcxx require you to tell it what the language will be with -vt:cc and -vt:cxx respectively (since the name of the compiler is available already in $0), but that means they're not a drop-in replacement for a compiler. Making one with a wrapper script is one way to work around that interface, and I think it will be more stable for use with CMake.<div>
<br></div><div>Mark</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 8, 2014 at 11:49 AM, Theodore Si <span dir="ltr"><<a href="mailto:sjyzhxw@gmail.com" target="_blank">sjyzhxw@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Mark,<br>
<br>
I run cmake two times.<br>
The first time I use these options:<br>
<span lang="zh-CN">cmake .. </span><span lang="en-US">-DCMAKE_C_FLAGS="</span><span style="color:#b43512" lang="en-US">-L /usr/local/cuda/lib64</span><span lang="en-US"> -vt:cc mpicc" -DCMAKE_CXX_FLAGS="-L
/usr/local/cuda/lib64
-vt:cxx mpicxx" </span><span lang="zh-CN">-DCMAKE_INSTALL_PREFIX=/home/theo/myprg/gmx
-DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda
-DCMAKE_C_COMPILER=/home/theo/myprg/vt/bin/vtcc</span><span lang="en-US"> </span><span lang="zh-CN">-DCMAKE_CXX_COMPILER=/home/theo/myprg/vt/bin/vtc</span><span lang="en-US">xx </span><span lang="zh-CN">-DCUDA_NVCC_EXECUTABLE=/home/theo/myprg/vt/bin/vtc</span><span lang="en-US">xx</span><span lang="zh-CN">
-DCUDA_NVCC_EXECUTABLE=/home/theo/myprg/vt/bin/vtnvcc</span><span lang="en-US"> </span><br>
<br>
and the second time just cmake .. without any option.<br>
<br>
If I build GMX with the first approach, when I run mdrun, I get a <font color="#ff0000">segmentation fault</font>. If I build GMX with the
second one, everything is fine.<br>
So I compared the output of the two cmake commands, I found this:<br>
17 -- Detecting best SIMD instructions for this CPU<br>
18 -- Run output: <font color="#ff0000">Segmentation fault</font><br>
19 -- Detected best SIMD instructions for this CPU - None<br>
<br>
17 -- Detecting best SIMD instructions for this CPU<br>
18 -- Detected best SIMD instructions for this CPU - AVX_256<br>
<br>
I believe that you know where I am going.<br>
So do you know how to fix this? Looking forward to your reply,
thanks!<div><br>
<br>
<br>
<div>On 8/7/2014 10:56 PM, Mark Abraham
wrote:<br>
</div>
</div><div><div><blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>First, what are you hoping to learn? Many questions have a
known answer, or are known not to have a clear answer ;-)</div>
<div><br>
</div>
<div>It's a compound problem. Profilers that just need to
compile with standard profiling flags are fine - just
configure with -DCMAKE_BUILD_TYPE=Profile and go for it. Those
that need to influence the compilation or linker line are more
problematic. Just passing the (full path to) the wrapper
compiler should work fine. If you need to pass things to the
wrapper compiler, make yourself a script to wrap the wrapper
compiler and give that to CMake. Whether the things the tool's
wrapper compiler does clashes with things GROMACS is doing
varies a lot, and you will need to get involved in the details
to see what the origin of any problems are. That's not
anybody's fault, per se, but the writer of a wrapper compiler
typically hopes the end user is not managing details
themselves, but to get high performance you often have to
manage details, and some of those details show up on the
compiler command lines generated by the GROMACS build system.
And naturally you'll be interested in MPI+OpenMP+CUDA, each of
which compounds the problem with further wrapper compilers or
command-line stuff.</div>
<div><br>
</div>
<div>Once it's working, you have the problem of whether you can
get useful data. Instrumenting every function call, or
compromising function inlining is guaranteed to be useless
because that overhead kills things. The main interesting case
to profile is where the MD step iteration time is a few
milliseconds, and you can't introduce thousands of increments
of tens of nanoseconds and get sensible profiles. So either
you have to restrict the instrumentation to high-level
functions (which is painful; the output at the end of the
GROMACS log file is a coarse version of this averaged over
many steps and execution contexts), or use a sampling-based
approach.</div>
<div><br>
</div>
<div>Then you need to start collecting data after the run-time
performance tuning that mdrun does has already stabilized - at
least a few hundred MD steps. Longer if the MD load is
imbalanced, which is also the main interesting case to
consider for code modifications.</div>
<div><br>
</div>
<div>Mark</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Aug 6, 2014 at 10:58 AM,
Theodore Si <span dir="ltr"><<a href="mailto:sjyzhxw@gmail.com" target="_blank">sjyzhxw@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">what kind of tools work best with gromacs 5.0?</p>
<br>
--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a>
before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a>
or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
<br>
</div></div></div>
<br>--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote></div><br></div></div>