[gmx-developers] The build process, and profiling

jan rtm443x at googlemail.com
Tue Apr 14 16:58:23 CEST 2020

Hi Mark,
please see below.

On 13/04/2020, Mark Abraham <mark.j.abraham at gmail.com> wrote:
> 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
>> 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.

I built it with -DGMX_BUILD_SHARED_EXE=OFF which per the manual
by default"

Still no joy. Very odd. I can suss that if I can get my head around
the build process, which I need to anyway, so that's first.

Ignoring gprof oddities for now I found that valgrind has a call graph
option, which is a very good start to see what's happening, so I'm
getting some visibility at least.

It shows main() going down to gmx::LegacySimulator::run() (legacy? I;m
surprised. I've probably done something wrong, but ok for now, will
dig later).
This goes to a few nbnx{n,m} calls which seem to take all the time.
Looking at the code for these, there's some kernel_inner.h which is
#included by kernel_outer.h. I guess this is where the main crunching
takes place, is that right? I'm not concerned about the details for
now, just the general stuff.
I'm asking because I can't see in the callgraph minimize.cpp (I guess
energy minimisation?) which is part of mdrun. I know from poking in it
that it is certainly used so I'm just checking.

> 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

Hm? Hold my beer, I have talent stressing things.

>> 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

Will do. I'll start on that next, of necessity (along with getting a
functioning IDE working).
I clearly get that cmake is a makefile maker, though it wasn't around
when I was doing c/c++. What I don't get is why those makefiles it
generates seem to invoke cmake again. No worries, I'll dig.
I have skimmed this link, or at least the manual, which seems to be
the same info, but will get stuck in properly (along with Joe Jordan's
suggestion - thanks Joe).



> 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.

More information about the gromacs.org_gmx-developers mailing list