[gmx-developers] What is the best choice to profile

Theodore Si sjyzhxw at gmail.com
Fri Aug 8 18:55:26 CEST 2014

Hi Mark,

I run cmake two times.
The first time I use these options:
cmake .. -DCMAKE_C_FLAGS="-L /usr/local/cuda/lib64-vt:cc mpicc" 
-DCMAKE_CXX_FLAGS="-L /usr/local/cuda/lib64 -vt:cxx mpicxx" 

  and the second time just cmake .. without any option.

If I build GMX with the first approach, when I run mdrun, I get a 
segmentation fault. If I build GMX with the second one, everything is fine.
So I compared the output of the two cmake commands, I found this:
  17 -- Detecting best SIMD instructions for this CPU
  18 -- Run output: Segmentation fault
  19 -- Detected best SIMD instructions for this CPU - None

  17 -- Detecting best SIMD instructions for this CPU
  18 -- Detected best SIMD instructions for this CPU - AVX_256

I believe that you know where I am going.
So do you know how to fix this? Looking forward to your reply, thanks!

On 8/7/2014 10:56 PM, Mark Abraham wrote:
> Hi,
> First, what are you hoping to learn? Many questions have a known 
> answer, or are known not to have a clear answer ;-)
> 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.
> 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.
> 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.
> Mark
> On Wed, Aug 6, 2014 at 10:58 AM, Theodore Si <sjyzhxw at gmail.com 
> <mailto:sjyzhxw at gmail.com>> wrote:
>     what kind of tools work best with gromacs 5.0?
>     --
>     Gromacs Developers mailing list
>     * Please search the archive at
>     http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>     before posting!
>     * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>     * For (un)subscribe requests visit
>     https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>     or send a mail to gmx-developers-request at gromacs.org
>     <mailto:gmx-developers-request at gromacs.org>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140808/5c9e386e/attachment-0001.html>

More information about the gromacs.org_gmx-developers mailing list