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

[Mark Abraham]

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.

Mark


On Fri, Aug 8, 2014 at 11:49 AM, Theodore Si <sjyzhxw at gmail.com> wrote:

>  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" -DCMAKE_INSTALL_PREFIX=/home/theo/myprg/gmx
> -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda
> -DCMAKE_C_COMPILER=/home/theo/myprg/vt/bin/vtcc
> -DCMAKE_CXX_COMPILER=/home/theo/myprg/vt/bin/vtcxx
> -DCUDA_NVCC_EXECUTABLE=/home/theo/myprg/vt/bin/vtcxx
> -DCUDA_NVCC_EXECUTABLE=/home/theo/myprg/vt/bin/vtnvcc
>
>  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> 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.
>>
>
>
>
>
>
> --
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140808/b8cd48b4/attachment.html>