Performance Profiling 101

Performance Measurement Counter Events

MPKI: Misses per kilo instruction

STLB:L Second Translation Lookaside Buffer

Notes:

STLB metric being speculative refers to attempting to use the TLB before for an instruction that isn't guaranteed to retired

Caveats

1. ILP and MLP metrics do not represent theoretical maximums for an application; rather they measure the actual ILP and MLP of an application on a given machine. On an ideal machine with infinite resources, these numbers would be higher.
2. All metrics besides “DRAM BW Use” and “Load Miss Real Latency” are fractions; we can apply fairly straightforward reasoning to each of them to tell whether a specific metric is high or low. But to make sense of “DRAM BW Use” and “Load Miss Real Latency” metrics, we need to put them in context. For the former, we would like to know if a program saturates the memory bandwidth or not. The latter gives you an idea of the average cost of a cache miss, which is useless by itself unless you know the latencies of each component in the cache hierarchy.

MLC

$ sudo ./mlc --idle_latency -c0 -L -b10m
Intel(R) Memory Latency Checker - v3.10
Command line parameters: --idle_latency -c0 -L -b10m
Using buffer size of 10.000MiB
Each iteration took 31.1 base frequency clocks ( 12.5 ns)

idle-latency for idle simulation, load-latency to simulate there being other hungry processes, c0 to pin the measurement process to logical core 0. if you read the manual for this system, this is actually a Performance Core

$ sudo ./mlc --max_bandwidth -k0-15 -Y -L -u -b18m
Measuring Maximum Memory Bandwidths for the system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using traffic with the following read-write ratios
ALL Reads
:
349670.42

On most Intel chips (the ones MLC targets), the L3 cache is inclusive of L1 and L2. That means: whatever is sitting in L1 or L2 is also required to have a copy sitting in L3 at the same time. L3 isn't a separate 18 MB pool that's short-changed by however much lives "up" in L1/L2 — it's a superset. If a cache line is in L1, it's guaranteed to also be in L3.

So wehn you choose -b18m since L3 capacity is 18mb then you'd effectively be measuring the L3 cache latency

(-u ensured when you're saying all threads in total use 18mb. if excluded, you'd measure 18mb * 8)

Practice

Here's what i identified as abnormal

Here's what I should have identified as well, highlighted in green

Also take care to note that these readings are actually averages that may change over the course of the program's lifecycle. E.g. imagine IPC is shown to be 2, which is actually the average of 2 different average performance modes where in one you have 1 IPC and in the other 3 IPC.

Cool stuff

If you go with a P/E core design, you can have the P cores L2 cache be in-core and E cores L2 cache be shared between multiple cores.