Project

General

Profile

Bug #1811

Extrae build issues

Added by Szilárd Páll over 4 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
build system
Target version:
-
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

I have tried to build with the Extrae support in 5.1 (wanting to get simple MPI/OpenMP event traces and ran into the following issues:
  • The mapping of the features to library names is not entirely correct, AFAIK the ompitrace library does MPI+OpenMP and ompicudatrace does MPI+OpenMP+CUDA.
  • The build scipts make no attempt to generate linker flags to at least try to link against the Extrae dependecies (nor does the script make any attempt to automatically detect these dependencies); hence, I get tons of link-stage warnings about libxml, BFD (which are AFAIK mandatory dependencies) as well as PAPI.

Given these issues the current GMX_EXTRAE CMake feature is hardly of any use, one may often have to override the library selection and assemble the link arguments manually.

The former should be fixed by:
  • fixing the features to tracing library mapping (suggest in 5.1)
  • allowing manual override (see attached patch) (maybe post 5.1 if the above is fixed?)
The latter needs more attention:
  • for 5.1: could a helper message should be issued with some suggested linker arguments (e.g. "Bla-bla-bla: -lpapi -lxml -lbfd);
  • post-5.1 a proper FindExtrae could actually look at the library dependecies and issue a more educated guess/suggestion for the link options the user has to use (looking for them manually may be an overkill).
FindExtrae.cmake.patch (692 Bytes) FindExtrae.cmake.patch Szilárd Páll, 08/20/2015 05:27 PM

History

#1 Updated by Szilárd Páll over 4 years ago

Szilárd Páll wrote:

  • The build scipts make no attempt to generate linker flags to at least try to link against the Extrae dependecies (nor does the script make any attempt to automatically detect these dependencies); hence, I get tons of link-stage warnings about libxml, BFD (which are AFAIK mandatory dependencies) as well as PAPI.

Looks like I was wrong about this because when I use some Extrae libraries other than the ones I just built (and manually pick the tracing library) I did get the linking to succeed. Do the extrae libs always contain full RPATH?

#2 Updated by Szilárd Páll over 4 years ago

Szilárd Páll wrote:

  • The mapping of the features to library names is not entirely correct, AFAIK the ompitrace library does MPI+OpenMP and ompicudatrace does MPI+OpenMP+CUDA.
One more correction:
  • ompitrace is correctly mapped and ompicudatrace is in fact cudaompitrace.
  • standard single-node tMPI+OpenMP+CUDA build however looks for cudaomptrace but that does not exists (and technically even this should be cudaptomptrace, right?), so omptrace would be more appropriate.

Additionally, I noticed that OpenCL is supported by extrae, so that may work too?

#3 Updated by Szilárd Páll over 4 years ago

One more remark:

$ cmake . -DGMX_MPI=ON -DGMX_GPU=OFF
[...]
$ grep "EXTRAE_LIBRARY:" CMakeCache.txt 
EXTRAE_LIBRARY:FILEPATH=/opt/tcbsys/extrae/3.0.1/lib/libompitrace.so

$ cmake . -DGMX_MPI=ON -DGMX_GPU=ON
EXTRAE_LIBRARY:FILEPATH=/opt/tcbsys/extrae/3.0.1/lib/libompitrace.so

So if the ${extraelib} variable changes, the detection is not rerun with the new value.

#4 Updated by Rossen Apostolov over 4 years ago

Szilárd Páll wrote:

  • standard single-node tMPI+OpenMP+CUDA build however looks for cudaomptrace but that does not exists (and technically even this should be cudaptomptrace, right?), so omptrace would be more appropriate.

The only PT libs are lib*pt*trace and lib*ptmpi*trace. And there is no lib*cudaomp*trace. Thus we're left with just lib*omp*trace for the standard single-node setup. would it suffice though?

Additionally, I noticed that OpenCL is supported by extrae, so that may work too?

good point, I'll check that

#5 Updated by Rossen Apostolov over 4 years ago

There is a special flag for building PT support in all libs:

--enable-pthread-support-in-all-libs
Allows all the instrumentation libraries to work
with pthreads. Caution! May add dependencies with
pthread library (disabled by default)

That might solve the pt support problem

#6 Updated by Gerrit Code Review Bot over 4 years ago

Gerrit received a related patchset '3' for Issue #1811.
Uploader: Rossen Apostolov ()
Change-Id: Ie88c1d1a9e3d38a221c7d5a423ed29e512b1e72b
Gerrit URL: https://gerrit.gromacs.org/5043

#7 Updated by Mark Abraham about 4 years ago

  • Target version deleted (5.1.1)

#8 Updated by Erik Lindahl almost 2 years ago

Has anybody actually used Extrae for the last two years? If not (i.e., if there's no feedback here :-), it sounds like a feature begging to be killed.

#9 Updated by Szilárd Páll almost 2 years ago

Erik Lindahl wrote:

Has anybody actually used Extrae for the last two years? If not (i.e., if there's no feedback here :-), it sounds like a feature begging to be killed.

Yes, I do use it regularly (what are others using?), but I often had to default to setting up the build semi-manually due to some of the issue I documented in detail. If I'm really the only one using it, I can set up linking myself and we can just remove this report.

#10 Updated by Erik Lindahl almost 2 years ago

How much work is it to fix this bug report instead?

There's not much point in keeping the option around if it doesn't work, so we should decide to either fix it or remove the support.

#11 Updated by Mark Abraham almost 2 years ago

I could fix it, but I doubt we'll get much new actionable insight. And if we want it, then someone else should probably work on the build system, because our bus factor is too low there.

Also available in: Atom PDF