Link Copied
Hi,
If you wish to get PMU events' observation when you want to profile a piece of code, it might be more effective to instrument your application with Task or Frame API.
As result, you'll see exact function boundaries in the overtime view and will be able to group performance data by tasks or frames with or without applying filters.
The following steps should be performed to enable ITT based code annotation for target application:
- Get ITT source code from github.
- Call ITT functions to annotate the regions-of-interest inside the source code:
#include <ittnotify.h>
int main() {
__itt_domain* domain = __itt_domain_create("Domain.Global");
assert(domain != nullptr);
// Place a new frame
__itt_frame_begin_v3(domain, nullptr);
{
// Annotate the first task
__itt_string_handle* first_task_handle =
__itt_string_handle_create("FirstTask");
__itt_task_begin(domain, __itt_null, __itt_null, first_task_handle);
{
/* First Task Body */
}
__itt_task_end(domain);
// Annotate the second task
__itt_string_handle* second_task_handle =
__itt_string_handle_create("SecondTask");
__itt_task_begin(domain, __itt_null, __itt_null, second_task_handle);
{
/* Second Task Body */
}
__itt_task_end(domain);
}
__itt_frame_end_v3(domain, nullptr);
return 0;
}
- Build the application and link it with ITT library implementation. One may build ITT static library first, and then link the application with it. Another way is to add ITT sources (in particular, ittnotify_static.c file) into the application directly.
- Run the application under Intel(R) VTune(TM) Analyzer to see the result.
If you are profiling a piece of code that executes within few microseconds, 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.
For usage example : https://www.intel.com/content/www/us/en/docs/vtune-profiler/user-guide/2023-0/frame-api.html
ITT API usage example : https://github.com/intel/pti-gpu/blob/master/chapters/code_annotation/ITT.md
After collection completes, the analysis results appear in a viewpoint specific to the analysis type selected. The API data collected is available in the following locations:
Timeline view: Each API type appears differently on the timeline view. In the example below, the code was instrumented with the task API, frame API, event API, and collection control API. Tasks appear as yellow bars on the task thread. Frames appear at the top of the timeline in pink. Events appear on the appropriate thread as a triangle at the event time. Collection control events span the entire timeline. Hover over a task, frame, or event to view the type of API task.
Grid view: Set the Grouping to Task Domain / Task Type / Function / Call Stack or Task Type / Function / Call Stack to view task data in the grid pane.
Platform tab: Individual tasks are available in a larger view on the Platform tab. Hover over a task to get more information.
Hope this clarifies your query.
Thanks
Hi,
Performance Monitoring Unit (PMU) provides a list of events to measure micro-architectural events such as the number of cycles, instructions retired, L1 cache misses and so on.
Those events are called PMU hardware events or hardware events for short. They vary with each processor type and model.
If you wants to see the PMU for say L1D cache , you can use Memory Subsystem PMU Events.
There's MEM_LOAD_RETIRED.L1_MISS and MEM_LOAD_RETIRED.L1_HIT. Alternatively, you can use L1-dcache-loads - L1-dcache-load-misses
Please refer the below link for more informations:
https://www.cs.utexas.edu/~pingali/CS377P/2018sp/lectures/vtune-cache-jackson.pdf
In Memory Access analysis type uses hardware event-based sampling to collect data for Memory Bound metric, that shows a fraction of cycles spent waiting due to demand load or store instructions
L1 Bound metric that shows how often the machine was stalled without missing the L1 data cache.
The Summary window gives the percentage of pipeline slots in each category for the whole application. You can explore results in multiple ways.
The most common way to explore results is to view metrics at the function level:
Most of the metrics under the Memory Bound category identify which level of the memory hierarchy from the L1 cache through the memory is the bottleneck.
Grayed out metric values indicate that the data collected for this metric is unreliable. This may happen, for example, if the number of samples collected for PMU events is too low. You may either ignore this data, or rerun the collection with the data collection time, sampling interval, or workload increased.
Reference : https://www.intel.com/content/www/us/en/docs/vtune-profiler/user-guide/2023-1/memory-access-analysis.html
If this resolves your issue, make sure to accept this as a solution. This would help others with similar issue.
Thanks
