[gmx-developers] The build process, and profiling

[Mark Abraham]

Hi Jan,

On Sun, 12 Apr 2020 at 14:59, jan <rtm443x at googlemail.com> wrote:

> Hi all,
> I've been trying to get profiling working, although I understand
> that's not what gromacs needs. I'm using bit as a way of getting used
> to everything. I'm also aware the manual says gprof probably won't be
> that useful - Pall says there'll be too much overhead to get useful
> timings. That's ok.
> Nonetheless, I can't get it working. If I enable gprof using
>
>  -DCMAKE_BUILD_TYPE=Profile
>
> then gmon.out is about 20K and
>
> gprof gmx
>
> gets me only a longish output describing labels (such as self, % time
> etc) but no actual profiling data.
>

By default, the build makes a wrapper binary gmx, with almost all the
functionality pushed into libgromacs.so. gprof often does not do a good job
of profiling shared libraries. Configure with cmake
-DBUILD_SHARED_LIBRARIES=off and gprof has more chance.

Also, just running gmx only returns the usage, so doesn't take any time. So
maybe gprof doesn't report anything because there's not enough time
analyzed for it to say anything? Mostly gmx mdrun is the only thing
interesting for profiling, although sometimes other tools are of interest,
like grompp. You will need a rather long mdrun for gprof's sampling
approach to do a good job - as an uninformed guess, nothing under 10
minutes.

Looking at the GCC docs it needs to be compiled with -pg, and linked
> with the same flags. Digging through the makefile stuff it *seems*,
> AFAICT, that both flags are being passed for compilation and linking.
> But no gprof output. Could well be I broke the build somehow, but I
> don't know.
>

Wildly unlikely


> About the build process, I don't understand even how to make sense of
> it. For example Cmake makes makefiles, ok, but many such generated
> makefiles seem to themselves call back to Cmake, eg. copied from a
> makefile produced by Cmake:
>
>
> # The CMake executable.
> CMAKE_COMMAND = /usr/bin/cmake
>
> # Special rule for the target install/strip
> install/strip: preinstall
>         @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan
> "Installing the project stripped..."
>         /usr/bin/cmake -DCMAKE_INSTALL_DO_STRIP=1 -P cmake_install.cmake
> .PHONY : install/strip
>
>
> So cmake calls on make which calls on cmake?
>

The cmake binary bundles multiple functionalities, including for supporting
functionality that works across platforms, such as one might use during
file copying during install stages, or pretty-printing to terminals during
the build. See its man page.

I really need to get a feeling of how the build is structured, so
> could anyone drop some useful hints or pointers please.
>

cmake's tutorial material is a useful start if you're just not familiar
with it at all. It's a build system generator, not a build system. As such,
there are CMakeLists.txt files in most GROMACS directories that direct the
process. Some general functionality is found in the top-level cmake
directory too. By the way, there's lots of useful documentation at
http://jenkins.gromacs.org/job/Documentation_Nightly_master/javadoc/dev-manual/index.html
but
if you spot something missing, please let us know!

Mark


> Pall has given me pointers to other profiling tools (again with the
> caveat that it's not what gmx needs, but this is part of my learning
> curve).
>
> cheers
>
> jan
> --
> 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/20200413/08c203fc/attachment.html>