Hi Frederik,
there are two issues here: The massive performance reduction for the end-to-end measurement is just a consequence of the short runtime and the significant impact from allocation and initialization. The increase in memory volume for activated markers, however, is not expected. You can solve the problem by registering each marker region at the beginning of your program (after LIKWID_MARKER_INIT) in a parallel region (see also https://github.com/RRZE-HPC/likwid/wiki/LikwidMarkerAPIPitfalls#recommended-usage-of-likwid_marker_register):
there are two issues here: The massive performance reduction for the end-to-end measurement is just a consequence of the short runtime and the significant impact from allocation and initialization. The increase in memory volume for activated markers, however, is not expected. You can solve the problem by registering each marker region at the beginning of your program (after LIKWID_MARKER_INIT) in a parallel region (see also https://github.com/RRZE-HPC/likwid/wiki/LikwidMarkerAPIPitfalls#recommended-usage-of-likwid_marker_register):
#pragma omp parallel
{
LIKWID_MARKER_REGISTER("raytrace");
}
This way, the individual LIKWID threads that are responsible for the monitoring are started already at that point and not when you call LIKWID_MARKER_START for the first time. In addition, internal data structures are set up, and all this overhead is out of the way as soon as you start counting later on. It is unclear to me why not registering the region(s) incurs such a large memory traffic, but the LIKWID developers have been notified about the problem.
Be that as it may, you do not actually need likwid-perfctr to answer the question in the assignment, and we did not expect you to use it at all (or we would probably have spotted the problem ourselves - but still, thank you for pointing it out).
Best,
Georg.