| ... | ... | @@ -343,3 +343,6 @@ LIKWID_MARKER_CLOSE; |
|
|
|
```
|
|
|
|
|
|
|
|
This code does a vector summation (`sum += A[i]`) in a seperate function and if the evaluation tells to use [Kahan summation](https://en.wikipedia.org/wiki/Kahan_summation_algorithm) instead, we reset the measurements and do the Kahan summation again using the same region name. Of course, `likwid-perfctr` has no clue about `LIKWID_MARKER_RESET`, so the "final" results printed by `likwid-perfctr` are those after the last `LIKWID_MARKER_RESET`.
|
|
|
|
|
|
|
|
# LIKWID measures FP operations with MarkerAPI for non-FP code
|
|
|
|
When you have an application that does not perform any FP operations, like an array copy, but measure `FLOPS_DP` (and on some systems even `FLOPS_SP` as there is no differentiation between SP and DP) with the MarkerAPI, the regions will always show some scalar FP operations. This is a result of the MarkerAPI internal calculations. In every `LIKWID_MARKER_START`, the MarkerAPI calls `perfmon_getResult()` to get the current value as start value. At `LIKWID_MARKER_STOP`, the MarkerAPI calls `perfmon_getResult()` again and add the start/stop difference to the MarkerAPI internal value. As `perfmon_getResult()` returns the values as `double`, the MarkerAPI also uses `double` types internally. These calculations cause scalar double-precision FP operations which can be seen in the region results. With each event/counter in the eventset and the number of region calls, the value increases. The LIKWID library uses `double` to return also floating-point values like the energy in joules from the Intel/AMD RAPL interface. |
|
|
\ No newline at end of file |
