Link Copied
Hi,
Thank you for your patience.
Frame APIs are different from Pause/Resume APIs. Using Frame APIs does not mean that the collection is stopped/paused outside the frame. When using frame APIs, VTune continue to gather performance data, even outside the frame, at the specified sampling rate. When the sampling interval is reached, VTune will associate the gathered data with the frame which is active at that instance and you can later view this data by grouping them as shown in snapshot below.
You will see the frames you have defined in your code along with a string “[No frame domain - Outside any frame]”. Any samples collected by VTune which cannot be associated with the user-defined frames, will show up under this section.
However, users should pay attention to the sampling interval set for data collection. The sampling interval should be well below the frame time (time taken to execute the code between frame-begin and frame-end API calls) for gathering meaningful performance data.
From your sample code, we could see that the frame APIs have been used to frame a very small piece of code. The recommended maximum rate for calling the frame API is 1000 frames per second (see our product documentation for more information). Based on your sample, you mentioned that the frame APIs created an overhead of 2x. This simply means that your code sample is executing within a very short duration and its execution time is comparable to the overhead created by the frame APIs.
__itt_frame_begin_v3(pD, NULL);
for (unsigned j = i*step_size; j < (i+1)*step_size; j++) {
auto it = map.find(p[j]);
if (it != map.end()) {
s += j;
}
}
__itt_frame_end_v3(pD, NULL);
In short, if you are profiling a piece of code that executes within few microseconds, neither Pause/Resume nor Frame APIs are suitable for this case. One way to work-around this problem is by increasing the number of loop iterations to increase the workload between the API calls. You can later do the math and calculate how much it took to execute one iteration of the loop. However this approach is not suitable if the execution time vary heavily between different iterations of the loop.
Under such circumstances, you can look at VTune Anomaly Detection which may be a viable option. Users can rely on Anomaly Detection to identify performance anomalies in frequently recurring intervals of code, like loop iterations. It can perform fine-grained analysis at the microsecond and nanosecond level. However, keep in mind that the performance data collected will be associated with each iteration of the loop, different from the way its presented when using a hotspot or microarchitecture analysis. You can check our product documentation for more information on Anomaly detection: https://software.intel.com/content/www/us/en/develop/documentation/vtune-help/top/analyze-performance/algorithm-group/anomaly-detection-analysis.html .
NOTE: The ITT messages (“vtune: Collection paused and vtune: Collection resumed.”) do not create additional overhead to the API calls. These messages are not coming from the APIs per se. Instead the APIs signal the VTune collector and the messages are displayed by the collector itself.
Hope this helps
Regards
Gopika
