Education Ecosystem Blog

Meet Intel® VTune™ Amplifier’s Platform Profiler

Bhanu Shankar, Performance Tools Architect, and Munara Tolubaeva, Software Technical Consulting Engineer, Intel Corporation

Have you ever wondered how well your system is being utilized throughout a long stretch of application runs? Or whether your system was misconfigured, leading to a performance degradation? Or, most importantly, how to reconfigure it to get the best performance out of your code? State-of-the-art performance analysis tools, which allow users to collect performance data for longer runs, don’t always give detailed performance metrics. On the other hand, performance analysis tools suitable for shorter application runs can overwhelm you with a huge amount of data.

This article introduces you to Intel® VTune™ Amplifier’s Platform Profiler, which provides data to learn whether there are problems with your system configuration that can lead to low performance, or if there’s pressure on specific system components that can cause performance bottlenecks. It analyzes performance from either the system or hardware point of view, and helps you identify under- or over-utilized resources. Platform Profiler uses a progressive disclosure method, so you’re not overwhelmed with information. That means it can run for multiple hours, giving you the freedom to monitor and analyze long-running or always-running workloads in either development or production environments.

You can use Platform Profiler to:

• Identify common system configuration problems
• Analyze the performance of the underlying platform and find performance bottlenecks

First, the platform configuration charts Platform Profiler provides can help you easily see how the system is configured and identify potential problems with the configuration. Second, you get system performance metrics including:

• CPU and memory utilization
• Memory and socket interconnect bandwidth
• Cycles per instruction
• Cache miss rates
• Type of instructions executed
• Storage device access metrics

These metrics provide system-wide data to help you identify if the system―or a specific platform component such as CPU, memory, storage, or network―is under- or over-utilized, and whether you need to upgrade or reconfigure any of these components to improve overall performance.

Platform Profiler in Action

To see it in action, let’s look at some analysis results collected during a run of the open-source HPC Challenge (HPCC) benchmark suite and see how it uses our test system. HPCC consists of seven tests to measure performance of:

• Floating-point (FP) execution
• Memory access
• Network communication operations

Figure 1 shows system configuration view of the machine where we ran our tests. The two-socket machine contained Intel® Xeon® Platinum 8168 processors, with two memory controllers and six memory channels per socket, and two storage devices connected to Socket 0.

Figure 2 shows CPU utilization metrics and the cycles per Instruction (CPI) metric, which measures how much work the CPUs are performing. Figure 3 shows memory, socket interconnect, and I/O bandwidth metrics. Figure 4 shows the ratio of load, store, branch, and FP instructions being used per core. Figures 5 and 6 show memory bandwidth and latency chart for each memory channel. Figure 7 shows a rate of branch and FP instructions over all instructions. Figure 8 shows L1 and L2 cache miss rate per instruction. Figure 9 shows memory consumption chart. On average, only 51% of memory was consumed throughout the run. A larger test case can be run to increase memory consumption.

In Figures 5 and 6, we see that only two channels instead of six are being used. This clearly shows that there’s a problem with the memory DIMM configuration on our test system that’s preventing us from making full usage of memory channel capacity―leading to a performance degradation of HPCC.

The CPI (Figure 2), DDR memory bandwidth utilization, and instruction mix metrics in the figures show which specific type of test―either compute or FP operation- or memory-based―is being executed at a specific time during the HPCC run. For example, we can see that during 80-130 and 200-260 seconds of the run, both the memory bandwidth utilization and CPI rate increase―confirming that a memory-based test inside HPCC was executed during that period of time. Moreover, the Instruction Mix chart in Figure 7 shows that between 280-410 seconds, threads execute FP instructions in addition to some memory access operations during 275-360 seconds (Figure 3). This observation leads us to the idea that a test with a mixture of both compute and memory operations is executed during this period. Another observation is that we may be able to improve the performance of the compute part in this test by optimizing the execution of FP operations using code vectorization.

Figure 1 – System Configuration View

CPU Metrics

Figure 2 – CPU utilization metrics

Throughput Metrics

Figure 3 – Throughput metrics for memory, UPI and I/O

Operations Metrics

Figure 4 – Types of instructions used in throughout program execution

Memory Throughput

Figure 5 – Memory bandwidth chart at a memory channel level

Memory Latency

Figure 6 – Memory latency chart at a memory channel level

Instruction Mix

Figure 7 – Rate of branch and floating point instructions over all instructions

L1 and L2 Miss per Instruction

Figure 8 – L1 and L2 miss rate per instruction

Memory Utilization

Figure 9 – Memory consumption

HPCC doesn’t perform any tests that include I/O, so we’ll show Platform Profiler results specifically on disk access from a second test case, LS-Dyna*, a proprietary multiphysics simulation software developed by LSTC. Figure 10 shows disk I/O throughput for LS-Dyna. Figure 11 shows I/O per second (IOPS) and latency metrics for LS-Dyna application. The LS-Dyna implicit model periodically flushes the data to the disk, so we see periodic spikes in the I/O throughput chart (see read/write throughput in Figure 10). Since the amount of data to be written isn’t large, the I/O latency remains consistent during the whole run (see read/write latency in Figure 11).

Read/Write Throughput

Read/Write Operation Mix

Figure 10 – Disk I/O throughput for LS-Dyna

Read/Write Latency

IOPS

Figure 11 – IOPS and latency metrics for LS-Dyna

Understanding System Performance

In this article, we presented Platform Profiler, a tool that analyzes performance from the system or hardware point of view. It provides insights into where the system is bottlenecked and identifies whether there are any over- or under-utilized subsystems and platform-level imbalances. We also showed its usage and the results collected from the HPCC benchmark suite and the LS-Dyna application. Using the tool, we found that poor memory DIMM placement was limiting memory bandwidth. Also, we found a part of the test had a high FP execution, which we could optimize for better performance using code vectorization. Overall, we found that this specific test case for HPCC and LS-Dyna doesn’t put any pressure on our test system, and there’s more room for system resources―meaning we can run an even larger test case next time.

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark and MobileMark, are measured using specific computer systems, components, software, operations and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products. For more complete information visit http://www.intel.com/performance.

Intel’s compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.