A timer is wrapped around the whole application and a TAU profile is generated with a single entry: .TAU application indicating the total runtime. This is useful for performing basic comparisons and for quantifying any artificial runtime dilation that may result from instrumentation or sampling. Compiling with the normal procedure is fine.
Sample
Use event based sampling to periodically poll the application and determine where it is spending its time. The application (and any libraries that may contain bottlenecks) should be compiled with debug symbols (-g) to allow TAU to resolve addresses. No other changes are required to compilation
Compiler-inst
This is the most accurate form of profiling when done carefully and correctly. TAU adds additional compiler flags so that the generated code will call into TAU's instrumentation API upon entry and exit from procedures. Normal compilation commands should be proceeded by tau, e.g., tau gfortran -c foo.f90. This is achieved by telling CMake to use the wrapper scripts in the root of the zgoubi repository.
Summary of changes:
Two selective instrumentation files are included to prevent injecting instrumentation calls (when using compiler-inst, i.e., compiler based instrumentation. One eliminates most calls across all 4 tests that trigger TAU to throttle & cause large runtime dilation. Time spent in excluded procedures is attributed to the first instrumented parent up the call stack.
A script was provided to aid in the installation of TAU Commander. It is self documented, run ./install-update-tau.sh --help for usage information.
A script was provided that will initialize a TAU Commander project for zgoubi. This should be run in the root of the zgoubi directory via ./setup_tau_project.sh.
Wrapper scripts were added to enable compilation and linking via tau gfortran ... from CMake. There is a good way to prepend tau to the compiler for compilation in CMake, but no way to do it for the link step. This is a work around.
CMake files and the test script template were modified so that:
If a non-profiling build configuration is selected, the build will happily work and proceed as before with or without TAU Commander installed and a TAU project setup
If a profiling build was selected the build will attempt to check that TAU Commander is installed, installing it if it is missing
If a profiling build is selected, TAU Commander is present, but no TAU project has been initialized then the build system will initialize a TAU Commander project, assuming GFortran/GCC for the compilers
If a profiling build is selected, the build system will attempt to select the corresponding TAU Commander experiment during configuration. This may fail if multiple "targets" or "applications" are defined in the TAU project, because, in that case specifying a "measurement" is insufficient to disambiguate the "experiment" to select
If a profiling build was selected, the test runner template will execute the tests with profiling enabled
Caveats
At a minimum, profiling typically requires debug flags to be turned on (-g). This is enabled by default.
Profile measurements other than baseline and sample require tau to be pre-pended to compilation and linking steps. As such, if you are performing a profiling build you should set FC to the gfortran wrapper script in the project root and CC to the gcc wrapper script in the project root.
Parallel builds when using the wrapper scripts & TAU can cause corruption of the TAU Commander database. This is a bug. If you select a profile build, DO NOT BUILD IN PARALLEL.
If you select a profile build and you do not have TAU Commander installed, CMake will invoke the script to install TAU Commander and install it into ~/taucmdr/, you can then add ~/taucmdr/bin to your PATH.
This pull request provides a means for semi-automatic profilingof zgoubi on Linux machines using TAU Commander.
To try profiling configure the build with:
The three types of profiling are as follows:
Baseline
A timer is wrapped around the whole application and a TAU profile is generated with a single entry:
.TAU applicationindicating the total runtime. This is useful for performing basic comparisons and for quantifying any artificial runtime dilation that may result from instrumentation or sampling. Compiling with the normal procedure is fine.Sample
Use event based sampling to periodically poll the application and determine where it is spending its time. The application (and any libraries that may contain bottlenecks) should be compiled with debug symbols (
-g) to allow TAU to resolve addresses. No other changes are required to compilationCompiler-inst
This is the most accurate form of profiling when done carefully and correctly. TAU adds additional compiler flags so that the generated code will call into TAU's instrumentation API upon entry and exit from procedures. Normal compilation commands should be proceeded by
tau, e.g.,tau gfortran -c foo.f90. This is achieved by telling CMake to use the wrapper scripts in the root of the zgoubi repository.Summary of changes:
compiler-inst, i.e., compiler based instrumentation. One eliminates most calls across all 4 tests that trigger TAU to throttle & cause large runtime dilation. Time spent in excluded procedures is attributed to the first instrumented parent up the call stack../install-update-tau.sh --helpfor usage information.zgoubidirectory via./setup_tau_project.sh.tau gfortran ...from CMake. There is a good way to prependtauto the compiler for compilation in CMake, but no way to do it for the link step. This is a work around.Caveats
-g). This is enabled by default.baselineandsamplerequiretauto be pre-pended to compilation and linking steps. As such, if you are performing a profiling build you should setFCto thegfortranwrapper script in the project root andCCto thegccwrapper script in the project root.~/taucmdr/, you can then add~/taucmdr/binto yourPATH.This should wrap up issue #36