LikwidMarkerAPIPitfalls.md

@@ -249,7 +249,7 @@ if (k == NTIMES/2)
 
 Now we can guarantee that all threads are are finished with their measurements and that no one starts the measurement while switching the events.
 
-Generally, `LIKWID_MARKER_SWITCH` has quite a high overhead compared to the other MarkerAPI function. Setting up the hardware registers is commonly done in `LIKWID_MARKER_INIT`, hence in a part of the application which is commonly not performance critical. `LIKWID_MARKER_SWITCH` performs three operations in code regions close to performance-critical code: stopping the old event set, setting up the new event set and starting it. The recommendation is to avoid using `LIKWID_MARKER_SWITCH` and re-run the application once for each group.
+Generally, `LIKWID_MARKER_SWITCH` has quite a high overhead compared to the other MarkerAPI function. Setting up the hardware registers is commonly done in `LIKWID_MARKER_INIT`, hence in a part of the application which is commonly not performance critical. `LIKWID_MARKER_SWITCH` performs three operations in code regions close to performance-critical code: stopping the old event set, setting up the new event set and starting it. The recommendation is to avoid using `LIKWID_MARKER_SWITCH` and re-run the application once for each group. Please use `LIKWID_MARKER_SWITCH` only in parts of your application that are not performance critical.
 
 # How to get the measured values in my application
 
@@ -343,4 +343,3 @@ 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`.
-