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

[Theodore Si]

Hi Mark,

I set these parameters:

CMAKE_CXX_COMPILER=$MYPRG/vt/bin/vtcxx
CMAKE_CXX_FLAGS=-vt:cxx mpicxx
CMAKE_C_COMPILER=$MYPRG/vt/bin/vtcc
CMAKE_C_FLAGS=-vt:cc mpicc

When I execute make, I get this:
vtcc: unknown option -- -vt:cxx

How come that vtcc get the flags set to vtcxx ?

I just keep running into strange things like this.

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/9b4e8d3d/attachment.html>