Intel® VTune™ Profiler

Cookbook

Download PDF
ID 766316
Date 10/31/2024
Public
Document Table of Contents
Document Table of Contents x
Cookbook
Cookbook x
Methodologies Configuration Recipes Tuning Recipes Notices and Disclaimers
Methodologies x
Analyzing Uncore Perfmon Events for Use of Intel® Data Direct I/O Technology in Intel® Xeon® Processors (NEW) Top-down Microarchitecture Analysis Method OpenMP* Code Analysis Method Custom Data Collection for Performance Analysis (NEW) Software Optimization for Intel® GPUs (NEW) Core Utilization in DPDK Apps PCIe Traffic in DPDK Apps DPDK Event Device Profiling Effective Utilization of Intel® Data Direct I/O Technology Compile a Portable Optimized Binary with the Latest Instruction Set
Configuration Recipes x
Profiling Large Language Models on Intel® Core™ Ultra 200V (NEW) Profiling Applications in Performance Monitoring Unit (PMU)-Enabled Google Cloud* Virtual Machines (NEW) Profiling OpenVINO™ Applications (NEW) Analyzing Uncore Perfmon Events for Use of Intel® Data Direct I/O Technology in Intel® Xeon® Processors (NEW) Profiling High Bandwidth Memory Performance on Intel® Xeon® CPU Max Series (NEW) Profiling Windows* Applications for Hybrid CPU Platforms (NEW) Viewing Analysis Results on a Web Browser (NEW) Profiling Data Parallel Python* Applications (NEW) Profiling Single-Node Kubernetes* Applications (NEW) Analyzing Hot Code Paths Using Flame Graphs (NEW) Improving Hotspot Observability in a C++ Application Using Flame Graphs Profiling Games built with Unity* (NEW) Profiling Games built with Unreal Engine* (NEW) Profiling Java Applications as a Remote User (NEW) Profiling JavaScript* Code in Node.js* Analyzing CPU and FPGA (Intel® Arria® 10 GX) Interaction Profiling a .NET* Core Application Profiling Applications in Amazon Web Services* (AWS) EC2 Instances Enabling Performance Profiling in GitLab* CI Configuring a Hyper-V* Virtual Machine for Hardware-Based Hotspots Analysis Profiling an Application for Performance Anomalies (NEW) Profiling an OpenMP* Offload Application running on a GPU Profiling a SYCL* Application running on a GPU Profiling an FPGA-driven SYCL* Application Profiling Hardware Without Intel Sampling Drivers Profiling MPI Applications Profiling Docker* Containers Profiling a Remote Target Through a Proxy Server (NEW) Profiling in an Apptainer* Container Profiling Linux*, Android*, and QNX* System Boot Time Using Intel® VTune™ Profiler Server with Visual Studio Code and Intel® DevCloud for oneAPI (NEW) Using Intel® VTune™ Profiler Server in HPC Clusters Using the Command-Line Interface to Analyze the Performance of a SYCL* Application running on a GPU (NEW)
Tuning Recipes x
Cache-Related Latency Issues in Segmented Cache Environment False Sharing Frequent DRAM Accesses Poor Port Utilization Ingredients Create Baseline Run Microarchitecture Exploration Analysis Understand Poor Port Utilization Explore Options for Vectorization Compile with the Latest Instruction Set See Also Page Faults Instruction Cache Misses OS Thread Migration OpenMP* Imbalance and Scheduling Overhead Processor Cores Underutilization: OpenMP* Serial Time Scheduling Overhead in an Intel® oneAPI Threading Building Blocks Application PMDK Application Overhead
Cookbook

Poor Port Utilization

Profile a core-bound matrix application using the Microarchitecture Exploration analysis in Intel® VTune™ Profiler. Understand the cause for poor port utilization and use Intel® Advisor to benefit from compiler vectorization.

Ingredients

This section lists the hardware and software tools used for the performance analysis scenario.

  • Application: The matrix multiplication sample that multiplies 2 matrices of 2048x2048 size, matrix elements have the double type. Find the matrix sample package in the VTune Profiler package in the <install-dir>/samples/en/C++ directory or download it from the GitHub samples repository.

  • Performance analysis tools:

  • Operating system: Linux*, Ubuntu 22.04.2 LTS

  • CPU: Intel® Core™ i7-6700K processor code named SkyLake (6th generation)

Create Baseline

Optimize the initial version of the matrix code with a naïve multiplication algorithm. See the Frequent DRAM Accesses recipe), the execution time has reduced from 22 seconds to 1.3 seconds. This is a new performance baseline for further optimizations.

Run Microarchitecture Exploration Analysis

Next, run the Microarchitecture Exploration analysis to get a high-level understanding of potential performance bottlenecks in the sample application:

  1. Click the New Project button on the toolbar and specify a name for the new project, for example: matrix.

  2. In the Configure Analysis window, make these selections:

    • In the WHERE pane, select the Local Host target system type.

    • In the WHAT pane, select the Launch Application target type and specify an application for analysis.

    • In the HOW pane, select the Microarchitecture Exploration analysis type.

    NOTE:
    For short duration workloads(~under 5 seconds) like the optimized version of the matrix application, you may get more accurate values by reducing the sampling interval to 0.5 seconds.

  3. Click Start to run the analysis.

    Once VTune Profiler collects data and finalizes results (after resolving symbol information for successful source analysis), you are ready to examine the causes for poor port utilization.

Understand Poor Port Utilization

Start with the Summary view that shows high-level statistics for the application performance per hardware metrics:

You see that the dominant bottleneck has moved to Core Bound > Port Utilization. More than 3 execution ports were utilized simultaneously for the majority of the time. The Vector Capacity Usage metric value is also flagged as critical, which means that the code was either not vectorized or vectorized poorly. To confirm this, switch to the Assembly view of the kernel as follows:

  1. Click the Vector Capacity Usage (FPU) metric to switch to the Bottom-up view sorted by this metric.

  2. Double-click the hot multiply1 function to open its Source view.

  3. Click the Assembly button on the toolbar to view the disassembly code:

You see that scalar instructions are used. The code is not vectorized.

Explore Options for Vectorization

To understand what prevents the code from being vectorized, use the Vectorization Advisor tool in Intel® Advisor.

In the graphic, we see that the loop was not vectorized due to assumed dependencies. For further details, mark the loop and run the Dependencies analysis in Intel Advisor:

The Dependencies report informs us that there are no actual dependencies found. There is a recommendation to use #pragma to make the compiler ignore the assumed dependencies:

With the #pragma added, the matrix code looks as follows: 

void multiply2_vec(inte msize, int tidx, int numt, TYPE a[][NUM],
    TYPE b[][NUM], TYPE c[][NUM], TYPE t[][NUM]
{
    int i,j,k;

    for(i=tidx; i<msize; i=i+numt) {
        for(k=0; k<msize; k++) {
#pragma ivdep
            for(j=0; j<msize; j++) {
                c[i][j] = c[i][j] + a[i][j] * b[i][j];
            }
        }
    }
}

Compiling and running the updated code results in 0.7 second speed-up in the execution time.

Compile with the Latest Instruction Set

Repeat the Microarchitecture Exploration analysis in VTune Profiler on the updated code to see the following result:

The Vector Capacity Usage has improved but is still only 50% and has been flagged. Look into the Assembly view once again:

Here, we see that the code uses SSE instructions while the CPU in this use case supports the AVX2 instruction set.

To apply it, re-compile the code with the -xCORE-AVX2 option and run the Microarchitecture Exploration analysis once more.

For the recompiled code, the execution time has dropped to 0.6 seconds. Repeat the Microarchitecture Exploration analysis to verify the optimization. The Vector Capacity Usage metric value is now 100%:

Parent topic: Tuning Recipes
Level Two Title