[gmx-developers] What is the best choice to profile
sjyzhxw at gmail.com
Fri Aug 8 04:50:59 CEST 2014
Thanks for your attention. I have some questions for you.
1. Profilers that just need to compile with standard profiling flags are
fine - just configure with -DCMAKE_BUILD_TYPE=Profile and go for it.
It seems that this is convenient. What profilers can be used in this
way? What tools do you guys use to profile?
2. If you need to pass things to the wrapper compiler, make yourself a
script to wrap the wrapper compiler and give that to CMake.
I think it's the case when I compile GMX with Vampir Trace. We need to
use the command vtcc -vt:cc mpicc sourcefile.c -o a.out to instrument
MPI code. Should "-vt:cc mpicc" be passed to vtcc, which is set to
CMAKE_C_COMPILER, as argument? I don't know how to "make yourself a
script to wrap the wrapper compiler and give that to CMake". How to give
a script to CMake exactly? I have not used CMake before, please give me
When I use Vampir Trace, some weird errors occur:
1. In some source files, some multiple-line comments are processed by
the compiler. If I change them to one-line comments, it works fine. I
have no idea why that happens.
2. If I use the following configuration:
The compilation can be done. And when I run grompp to generate tpr, it's
OK and Vampir Trace will generate trace files. When I run mdrun without
parameters, it also generate trace files. However, when I actually start
mdrun with a tpr file, it will give a segmentation fault.
On 8/7/2014 10:56 PM, Mark Abraham wrote:
> 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
> 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.
> 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
> before posting!
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> * For (un)subscribe requests visit
> 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...
More information about the gromacs.org_gmx-developers