alpaka-group / bactria Goto Github PK

Suggested by @bernhardmgruber. Overusing std::endl can lead to serious performance degradation.

This is currently missing. Thanks for @psychocoderHPC for bringing this up.

After #13 has been solved, we should provide a Score-P metrics plugin.

bactria currently doesn't provide any installation facilities, so users can only use it using CMake's add_subdirectory command. This should change so find_package works as well.

After the very interesting talk @ CASUS by @Techercise about roofline models for GPUs I now want something like this in bactria. Maybe it would be possible for certain backends to automatically generate a roofline plot for individual kernels; I'll need to read some literature...

bactria should have support for AMD's rocTX API.

The original design of bactria envisioned a single plugin that would provide all required functionality:

BACTRIA_PLUGIN=/path/to/plugin.so ./myapp

Since then, three orthogonal branches of functionality have evolved:

1. Metrics collection. This is provided by libraries such as Score-P or CUPTI.
2. Visualization. In some cases it is useful to annotate events / ranges in the code so that they will be highlighted in a profiler. Examples for this are NVTX ranges with the CUDA profiler or Chrome's about:tracing tool.
3. User-defined data / metrics. Since the libraries mentioned in the first two points usually don't support this (or just to a very limited degree) bactria will allow the user to define their own events and save them in the format of their choice (CSV, JSON, a database...).

It makes sense to split up this functionality into separate plugins:

1. BACTRIA_METRICS_PLUGIN will support metrics collection by specialized backends.
2. BACTRIA_RANGES_PLUGIN will support tool visualization.
3. BACTRIA_REPORT_PLUGIN will support user-defined data.

These should have no inter-dependencies or conflicts, so it should be entirely legal to do something like the following:

BACTRIA_METRICS_PLUGIN=/path/to/scorep-plugin.so \
BACTRIA_RANGES_PLUGIN=/path/to/nvtx-plugin.so \
BACTRIA_REPORT_PLUGIN=/path/to/mysql-plugin.so \
./myapp

Suggested by @bernhardmgruber. See the reasoning here: https://stackoverflow.com/questions/56601261/should-methods-returning-const-stdstring-return-const-stdstring-view-instea

After the building the project, I was a little bit surprised, that no plugin covers all three functions. If I look in project structure documentation, it makes sense, but a table would be better.

I think the table can be also a good place to note, which supported combinations are WIP/possible and what is not possible.

Depending on the used backend, the way how to measure and view profile and trace data changes. For example, an application, which is annotated with score-p does automatically generate a profile file, if it is executed. In contrast of it, the nvidia compiler needs to be called manually to profile an application, e.g. nsys -o trace.prof ./app --param foo && nsys-gui trace.prof.

It would be really helpful to have a small get started guide for each backend, to know how to do a profile and view it.

I recently came across the need to profile sections inside a single CUDA kernel. We wanted to figure out which subpart of the kernel consumes how much time. In Bactria terms, that would mean that we could enter and leave phases and sectors inside CUDA device code.

Is such a feature planned or in scope of bactria?

After #13 has been solved, bactria should have a ranges plugin for NVIDIA's NVTX API.

Before we can release bactria 0.1 we need to provide better documentation and examples. This should be tackled once 0.1 is feature-complete.

Currently this only works on Linux (and maybe macOS). We still need a loader for Windows.

Since plugin-mixing will be allowed after #13 is solved it is a good idea to allow configuration for individual plugins (filtering, output files, ...). Initially, users should be able to configure plugins over the command line and configuration files. In a future step, we should investigate options for online access.

After #13 has been solved, we should provide a CUPTI metrics plugin.

Score-P allows for user-defined metrics to be included in the trace. We can take advantage of this by providing a reports plugin for bactria which communicates with the metrics plugin introduced by #19.

Found by @bernhardmgruber. Currently event and phase do not follow these rules, leading to a number of problems.

Suggested by @bernhardmgruber. Apparently this breaks name mangling on Windows systems.