Your Guide to Understanding System Performance

Read Time:6 Minute, 55 Second
Your Guide to Understanding System Performance

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™
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
  • 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

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


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

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.


You might also like this video