Use the Memory Access analysis to identify memory-related issues, like NUMA problems and bandwidth-limited accesses, and attribute performance events to memory objects (data structures), which is provided due to instrumentation of memory allocations/de-allocations and getting static/global variables from symbol information.
Memory Access analysis type uses event-based sampling to collect data for the following metrics:
-
Loads and Stores metrics that show the total number of loads and stores
-
LLC Miss Count metric that shows the total number of last-level cache misses
-
Local DRAM Access Count metric that shows the total number of LLC misses serviced by the local memory
-
Remote DRAM Access Count metric that shows the number of accesses to the remote socket memory
-
Remote Cache Access Count metric that shows the number of accesses to the remote socket cache
-
-
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
-
L2 Bound metric that shows how often the machine was stalled on L2 cache
-
L3 Bound metric that shows how often the CPU was stalled on L3 cache, or contended with a sibling core
-
L3 Latency metric that shows a fraction of cycles with demand load accesses that hit the L3 cache under unloaded scenarios (possibly L3 latency limited)
-
-
DRAM Bound metric that shows how often the CPU was stalled on the main memory (DRAM)
-
Remote / Local DRAM Ratio metric that is defined by the ratio of remote DRAM loads to local DRAM loads
-
Local DRAM metric that shows how often the CPU was stalled on loads from the local memory
-
Remote DRAM metric that shows how often the CPU was stalled on loads from the remote memory
-
Remote cache metric that shows how often the CPU was stalled on loads from the remote cache in other sockets
-
-
Average Latency metric that shows an average load latency in cycles
Note
The list of metrics may vary depending on your microarchitecture.
Many of the collected events used in the Memory Access analysis are precise. This simplifies understanding the data access pattern. Off-core traffic is divided into the local DRAM and remote DRAM accesses. Typically, you should focus on minimizing remote DRAM accesses that usually have a high cost.
To use the Memory Access analysis type, explore:
-
Configuration options (knobs)
Configuration Options
To configure options for the Memory Access analysis:
-
Click the
New Analysis toolbar button.
The Analysis Type window opens.
-
From the left pane, select Microarchitecture Analysis > Memory Access.
The Memory Access configuration pane opens on the right.
-
Configure the following options:
Analyze memory objects check box
Enable the instrumentation of memory allocation/de-allocation and map hardware events to memory objects.
This option may cause additional runtime overhead due to the instrumentation of all system memory allocation/de-allocation API.
Note
This option can be configured for Linux* targets only and only for processors based on Intel microarchitecture code name Sandy Bridge or later.
Minimal memory object size to track, in bytes spin box
Specify a minimal size of memory allocations to analyze. This option helps reduce runtime overhead of the instrumentation.
Note
This option can be configured for Linux targets only.
Details button
Expand/collapse the Details section to explore the default non-editable settings and hardware events used by the Memory Access analysis for your system.
Note
If you want to modify these settings, click the Copy button in the upper right corner. VTune Amplifier creates an editable copy of the custom hardware event-based sampling analysis type configuration and locates it under the Custom Analysis branch in the analysis tree.
Viewpoints
By default, the Memory Access analysis data shows up in the Memory Usage viewpoint that includes the following windows:
-
Summary window displays statistics on the overall application execution, including the application-level bandwidth utilization histogram.
-
Bottom-up window displays performance data per metric (event ratio/event count/sample count) for each hotspot function. If you enable the Analyze memory objects option for data collection, the Bottom-up window also displays memory allocation call stacks in the grid and Call Stack pane. Use the Memory Object grouping level, preceded with the Function level, to view memory objects as the source location of an allocation call.
-
Platform window provides details on tasks specified in your code with the Task API, Ftrace*/Systrace* event tasks, OpenCL™ API tasks, and so on. If corresponding platform metrics are collected, the Platform window displays overtime data as GPU usage on a software queue, CPU time usage, OpenCL™ kernels data, and GPU performance per the Overview group of GPU hardware metrics, Memory Bandwidth, and CPU Frequency.