69716394f3
Summary:
Given an instruction `Opcode`, we can make benchmarks (measurements) of the
instruction characteristics/performance. Then, to facilitate further analysis
we group the benchmarks with *similar* characteristics into clusters.
Now, this is all not entirely deterministic. Some instructions have variable
characteristics, depending on their arguments. And thus, if we do several
benchmarks of the same instruction `Opcode`, we may end up with *different*
performance characteristics measurements. And when we then do clustering,
these several benchmarks of the same instruction `Opcode` may end up being
clustered into *different* clusters. This is not great for further analysis.
We shall find every `Opcode` with benchmarks not in just one cluster, and move
*all* the benchmarks of said `Opcode` into one new unstable cluster per `Opcode`.
I have solved this by making `ClusterId` a bit field, adding a `IsUnstable` bit,
and introducing `-analysis-display-unstable-clusters` switch to toggle between
displaying stable-only clusters and unstable-only clusters.
The reclusterization is deterministically stable, produces identical reports
between runs. (Or at least that is what i'm seeing, maybe it isn't)
Timings/comparisons:
old (current trunk/head) {F8303582}
```
$ perf stat -r 25 ./bin/llvm-exegesis -mode=analysis -analysis-epsilon=0.5 -benchmarks-file=/home/lebedevri/PileDriver-Sched/benchmarks-inverse_throughput.yaml -analysis-inconsistencies-output-file=/tmp/clusters-old.html
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 43970 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-old.html'
...
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 43970 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-old.html'
Performance counter stats for './bin/llvm-exegesis -mode=analysis -analysis-epsilon=0.5 -benchmarks-file=/home/lebedevri/PileDriver-Sched/benchmarks-inverse_throughput.yaml -analysis-inconsistencies-output-file=/tmp/clusters-old.html' (25 runs):
6624.73 msec task-clock # 0.999 CPUs utilized ( +- 0.53% )
172 context-switches # 25.965 M/sec ( +- 29.89% )
0 cpu-migrations # 0.042 M/sec ( +- 56.54% )
31073 page-faults # 4690.754 M/sec ( +- 0.08% )
26538711696 cycles # 4006230.292 GHz ( +- 0.53% ) (83.31%)
2017496807 stalled-cycles-frontend # 7.60% frontend cycles idle ( +- 0.93% ) (83.32%)
13403650062 stalled-cycles-backend # 50.51% backend cycles idle ( +- 0.33% ) (33.37%)
19770706799 instructions # 0.74 insn per cycle
# 0.68 stalled cycles per insn ( +- 0.04% ) (50.04%)
4419821812 branches # 667207369.714 M/sec ( +- 0.03% ) (66.69%)
121741669 branch-misses # 2.75% of all branches ( +- 0.28% ) (83.34%)
6.6283 +- 0.0358 seconds time elapsed ( +- 0.54% )
```
patch, with reclustering but without filtering (i.e. outputting all the stable *and* unstable clusters) {F8303586}
```
$ perf stat -r 25 ./bin/llvm-exegesis -mode=analysis -analysis-epsilon=0.5 -benchmarks-file=/home/lebedevri/PileDriver-Sched/benchmarks-inverse_throughput.yaml -analysis-inconsistencies-output-file=/tmp/clusters-new-all.html
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 43970 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-new-all.html'
...
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 43970 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-new-all.html'
Performance counter stats for './bin/llvm-exegesis -mode=analysis -analysis-epsilon=0.5 -benchmarks-file=/home/lebedevri/PileDriver-Sched/benchmarks-inverse_throughput.yaml -analysis-inconsistencies-output-file=/tmp/clusters-new-all.html' (25 runs):
6475.29 msec task-clock # 0.999 CPUs utilized ( +- 0.31% )
213 context-switches # 32.952 M/sec ( +- 23.81% )
1 cpu-migrations # 0.130 M/sec ( +- 43.84% )
31287 page-faults # 4832.057 M/sec ( +- 0.08% )
25939086577 cycles # 4006160.279 GHz ( +- 0.31% ) (83.31%)
1958812858 stalled-cycles-frontend # 7.55% frontend cycles idle ( +- 0.68% ) (83.32%)
13218961512 stalled-cycles-backend # 50.96% backend cycles idle ( +- 0.29% ) (33.37%)
19752995402 instructions # 0.76 insn per cycle
# 0.67 stalled cycles per insn ( +- 0.04% ) (50.04%)
4417079244 branches # 682195472.305 M/sec ( +- 0.03% ) (66.70%)
121510065 branch-misses # 2.75% of all branches ( +- 0.19% ) (83.34%)
6.4832 +- 0.0229 seconds time elapsed ( +- 0.35% )
```
Funnily, *this* measurement shows that said reclustering actually improved performance.
patch, with reclustering, only the stable clusters {F8303594}
```
$ perf stat -r 25 ./bin/llvm-exegesis -mode=analysis -analysis-epsilon=0.5 -benchmarks-file=/home/lebedevri/PileDriver-Sched/benchmarks-inverse_throughput.yaml -analysis-inconsistencies-output-file=/tmp/clusters-new-stable.html
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 43970 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-new-stable.html'
...
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 43970 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-new-stable.html'
Performance counter stats for './bin/llvm-exegesis -mode=analysis -analysis-epsilon=0.5 -benchmarks-file=/home/lebedevri/PileDriver-Sched/benchmarks-inverse_throughput.yaml -analysis-inconsistencies-output-file=/tmp/clusters-new-stable.html' (25 runs):
6387.71 msec task-clock # 0.999 CPUs utilized ( +- 0.13% )
133 context-switches # 20.792 M/sec ( +- 23.39% )
0 cpu-migrations # 0.063 M/sec ( +- 61.24% )
31318 page-faults # 4903.256 M/sec ( +- 0.08% )
25591984967 cycles # 4006786.266 GHz ( +- 0.13% ) (83.31%)
1881234904 stalled-cycles-frontend # 7.35% frontend cycles idle ( +- 0.25% ) (83.33%)
13209749965 stalled-cycles-backend # 51.62% backend cycles idle ( +- 0.16% ) (33.36%)
19767554347 instructions # 0.77 insn per cycle
# 0.67 stalled cycles per insn ( +- 0.04% ) (50.03%)
4417480305 branches # 691618858.046 M/sec ( +- 0.03% ) (66.68%)
118676358 branch-misses # 2.69% of all branches ( +- 0.07% ) (83.33%)
6.3954 +- 0.0118 seconds time elapsed ( +- 0.18% )
```
Performance improved even further?! Makes sense i guess, less clusters to print.
patch, with reclustering, only the unstable clusters {F8303601}
```
$ perf stat -r 25 ./bin/llvm-exegesis -mode=analysis -analysis-epsilon=0.5 -benchmarks-file=/home/lebedevri/PileDriver-Sched/benchmarks-inverse_throughput.yaml -analysis-inconsistencies-output-file=/tmp/clusters-new-unstable.html -analysis-display-unstable-clusters
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 43970 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-new-unstable.html'
...
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 43970 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-new-unstable.html'
Performance counter stats for './bin/llvm-exegesis -mode=analysis -analysis-epsilon=0.5 -benchmarks-file=/home/lebedevri/PileDriver-Sched/benchmarks-inverse_throughput.yaml -analysis-inconsistencies-output-file=/tmp/clusters-new-unstable.html -analysis-display-unstable-clusters' (25 runs):
6124.96 msec task-clock # 1.000 CPUs utilized ( +- 0.20% )
194 context-switches # 31.709 M/sec ( +- 20.46% )
0 cpu-migrations # 0.039 M/sec ( +- 49.77% )
31413 page-faults # 5129.261 M/sec ( +- 0.06% )
24536794267 cycles # 4006425.858 GHz ( +- 0.19% ) (83.31%)
1676085087 stalled-cycles-frontend # 6.83% frontend cycles idle ( +- 0.46% ) (83.32%)
13035595603 stalled-cycles-backend # 53.13% backend cycles idle ( +- 0.16% ) (33.36%)
18260877653 instructions # 0.74 insn per cycle
# 0.71 stalled cycles per insn ( +- 0.05% ) (50.03%)
4112411983 branches # 671484364.603 M/sec ( +- 0.03% ) (66.68%)
114066929 branch-misses # 2.77% of all branches ( +- 0.11% ) (83.32%)
6.1278 +- 0.0121 seconds time elapsed ( +- 0.20% )
```
This tells us that the actual `-analysis-inconsistencies-output-file=` outputting only takes ~0.4 sec for 43970 benchmark points (3 whole sweeps)
(Also, wow this is fast, it used to take several minutes originally)
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40715 | PR40715 ]].
Reviewers: courbet, gchatelet
Reviewed By: courbet
Subscribers: tschuett, jdoerfert, llvm-commits, RKSimon
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58355
llvm-svn: 354441
248 lines
8.4 KiB
ReStructuredText
248 lines
8.4 KiB
ReStructuredText
llvm-exegesis - LLVM Machine Instruction Benchmark
|
|
==================================================
|
|
|
|
SYNOPSIS
|
|
--------
|
|
|
|
:program:`llvm-exegesis` [*options*]
|
|
|
|
DESCRIPTION
|
|
-----------
|
|
|
|
:program:`llvm-exegesis` is a benchmarking tool that uses information available
|
|
in LLVM to measure host machine instruction characteristics like latency,
|
|
throughput, or port decomposition.
|
|
|
|
Given an LLVM opcode name and a benchmarking mode, :program:`llvm-exegesis`
|
|
generates a code snippet that makes execution as serial (resp. as parallel) as
|
|
possible so that we can measure the latency (resp. inverse throughput/uop decomposition)
|
|
of the instruction.
|
|
The code snippet is jitted and executed on the host subtarget. The time taken
|
|
(resp. resource usage) is measured using hardware performance counters. The
|
|
result is printed out as YAML to the standard output.
|
|
|
|
The main goal of this tool is to automatically (in)validate the LLVM's TableDef
|
|
scheduling models. To that end, we also provide analysis of the results.
|
|
|
|
:program:`llvm-exegesis` can also benchmark arbitrary user-provided code
|
|
snippets.
|
|
|
|
EXAMPLE 1: benchmarking instructions
|
|
------------------------------------
|
|
|
|
Assume you have an X86-64 machine. To measure the latency of a single
|
|
instruction, run:
|
|
|
|
.. code-block:: bash
|
|
|
|
$ llvm-exegesis -mode=latency -opcode-name=ADD64rr
|
|
|
|
Measuring the uop decomposition or inverse throughput of an instruction works similarly:
|
|
|
|
.. code-block:: bash
|
|
|
|
$ llvm-exegesis -mode=uops -opcode-name=ADD64rr
|
|
$ llvm-exegesis -mode=inverse_throughput -opcode-name=ADD64rr
|
|
|
|
|
|
The output is a YAML document (the default is to write to stdout, but you can
|
|
redirect the output to a file using `-benchmarks-file`):
|
|
|
|
.. code-block:: none
|
|
|
|
---
|
|
key:
|
|
opcode_name: ADD64rr
|
|
mode: latency
|
|
config: ''
|
|
cpu_name: haswell
|
|
llvm_triple: x86_64-unknown-linux-gnu
|
|
num_repetitions: 10000
|
|
measurements:
|
|
- { key: latency, value: 1.0058, debug_string: '' }
|
|
error: ''
|
|
info: 'explicit self cycles, selecting one aliasing configuration.
|
|
Snippet:
|
|
ADD64rr R8, R8, R10
|
|
'
|
|
...
|
|
|
|
To measure the latency of all instructions for the host architecture, run:
|
|
|
|
.. code-block:: bash
|
|
|
|
#!/bin/bash
|
|
readonly INSTRUCTIONS=$(($(grep INSTRUCTION_LIST_END build/lib/Target/X86/X86GenInstrInfo.inc | cut -f2 -d=) - 1))
|
|
for INSTRUCTION in $(seq 1 ${INSTRUCTIONS});
|
|
do
|
|
./build/bin/llvm-exegesis -mode=latency -opcode-index=${INSTRUCTION} | sed -n '/---/,$p'
|
|
done
|
|
|
|
FIXME: Provide an :program:`llvm-exegesis` option to test all instructions.
|
|
|
|
|
|
EXAMPLE 2: benchmarking a custom code snippet
|
|
---------------------------------------------
|
|
|
|
To measure the latency/uops of a custom piece of code, you can specify the
|
|
`snippets-file` option (`-` reads from standard input).
|
|
|
|
.. code-block:: bash
|
|
|
|
$ echo "vzeroupper" | llvm-exegesis -mode=uops -snippets-file=-
|
|
|
|
Real-life code snippets typically depend on registers or memory.
|
|
:program:`llvm-exegesis` checks the liveliness of registers (i.e. any register
|
|
use has a corresponding def or is a "live in"). If your code depends on the
|
|
value of some registers, you have two options:
|
|
|
|
- Mark the register as requiring a definition. :program:`llvm-exegesis` will
|
|
automatically assign a value to the register. This can be done using the
|
|
directive `LLVM-EXEGESIS-DEFREG <reg name> <hex_value>`, where `<hex_value>`
|
|
is a bit pattern used to fill `<reg_name>`. If `<hex_value>` is smaller than
|
|
the register width, it will be sign-extended.
|
|
- Mark the register as a "live in". :program:`llvm-exegesis` will benchmark
|
|
using whatever value was in this registers on entry. This can be done using
|
|
the directive `LLVM-EXEGESIS-LIVEIN <reg name>`.
|
|
|
|
For example, the following code snippet depends on the values of XMM1 (which
|
|
will be set by the tool) and the memory buffer passed in RDI (live in).
|
|
|
|
.. code-block:: none
|
|
|
|
# LLVM-EXEGESIS-LIVEIN RDI
|
|
# LLVM-EXEGESIS-DEFREG XMM1 42
|
|
vmulps (%rdi), %xmm1, %xmm2
|
|
vhaddps %xmm2, %xmm2, %xmm3
|
|
addq $0x10, %rdi
|
|
|
|
|
|
EXAMPLE 3: analysis
|
|
-------------------
|
|
|
|
Assuming you have a set of benchmarked instructions (either latency or uops) as
|
|
YAML in file `/tmp/benchmarks.yaml`, you can analyze the results using the
|
|
following command:
|
|
|
|
.. code-block:: bash
|
|
|
|
$ llvm-exegesis -mode=analysis \
|
|
-benchmarks-file=/tmp/benchmarks.yaml \
|
|
-analysis-clusters-output-file=/tmp/clusters.csv \
|
|
-analysis-inconsistencies-output-file=/tmp/inconsistencies.html
|
|
|
|
This will group the instructions into clusters with the same performance
|
|
characteristics. The clusters will be written out to `/tmp/clusters.csv` in the
|
|
following format:
|
|
|
|
.. code-block:: none
|
|
|
|
cluster_id,opcode_name,config,sched_class
|
|
...
|
|
2,ADD32ri8_DB,,WriteALU,1.00
|
|
2,ADD32ri_DB,,WriteALU,1.01
|
|
2,ADD32rr,,WriteALU,1.01
|
|
2,ADD32rr_DB,,WriteALU,1.00
|
|
2,ADD32rr_REV,,WriteALU,1.00
|
|
2,ADD64i32,,WriteALU,1.01
|
|
2,ADD64ri32,,WriteALU,1.01
|
|
2,MOVSX64rr32,,BSWAP32r_BSWAP64r_MOVSX64rr32,1.00
|
|
2,VPADDQYrr,,VPADDBYrr_VPADDDYrr_VPADDQYrr_VPADDWYrr_VPSUBBYrr_VPSUBDYrr_VPSUBQYrr_VPSUBWYrr,1.02
|
|
2,VPSUBQYrr,,VPADDBYrr_VPADDDYrr_VPADDQYrr_VPADDWYrr_VPSUBBYrr_VPSUBDYrr_VPSUBQYrr_VPSUBWYrr,1.01
|
|
2,ADD64ri8,,WriteALU,1.00
|
|
2,SETBr,,WriteSETCC,1.01
|
|
...
|
|
|
|
:program:`llvm-exegesis` will also analyze the clusters to point out
|
|
inconsistencies in the scheduling information. The output is an html file. For
|
|
example, `/tmp/inconsistencies.html` will contain messages like the following :
|
|
|
|
.. image:: llvm-exegesis-analysis.png
|
|
:align: center
|
|
|
|
Note that the scheduling class names will be resolved only when
|
|
:program:`llvm-exegesis` is compiled in debug mode, else only the class id will
|
|
be shown. This does not invalidate any of the analysis results though.
|
|
|
|
|
|
OPTIONS
|
|
-------
|
|
|
|
.. option:: -help
|
|
|
|
Print a summary of command line options.
|
|
|
|
.. option:: -opcode-index=<LLVM opcode index>
|
|
|
|
Specify the opcode to measure, by index. See example 1 for details.
|
|
Either `opcode-index`, `opcode-name` or `snippets-file` must be set.
|
|
|
|
.. option:: -opcode-name=<opcode name 1>,<opcode name 2>,...
|
|
|
|
Specify the opcode to measure, by name. Several opcodes can be specified as
|
|
a comma-separated list. See example 1 for details.
|
|
Either `opcode-index`, `opcode-name` or `snippets-file` must be set.
|
|
|
|
.. option:: -snippets-file=<filename>
|
|
|
|
Specify the custom code snippet to measure. See example 2 for details.
|
|
Either `opcode-index`, `opcode-name` or `snippets-file` must be set.
|
|
|
|
.. option:: -mode=[latency|uops|inverse_throughput|analysis]
|
|
|
|
Specify the run mode. Note that if you pick `analysis` mode, you also need
|
|
to specify at least one of the `-analysis-clusters-output-file=` and
|
|
`-analysis-inconsistencies-output-file=`.
|
|
|
|
.. option:: -num-repetitions=<Number of repetition>
|
|
|
|
Specify the number of repetitions of the asm snippet.
|
|
Higher values lead to more accurate measurements but lengthen the benchmark.
|
|
|
|
.. option:: -benchmarks-file=</path/to/file>
|
|
|
|
File to read (`analysis` mode) or write (`latency`/`uops`/`inverse_throughput`
|
|
modes) benchmark results. "-" uses stdin/stdout.
|
|
|
|
.. option:: -analysis-clusters-output-file=</path/to/file>
|
|
|
|
If provided, write the analysis clusters as CSV to this file. "-" prints to
|
|
stdout. By default, this analysis is not run.
|
|
|
|
.. option:: -analysis-inconsistencies-output-file=</path/to/file>
|
|
|
|
If non-empty, write inconsistencies found during analysis to this file. `-`
|
|
prints to stdout. By default, this analysis is not run.
|
|
|
|
.. option:: -analysis-numpoints=<dbscan numPoints parameter>
|
|
|
|
Specify the numPoints parameters to be used for DBSCAN clustering
|
|
(`analysis` mode).
|
|
|
|
.. option:: -analysis-epsilon=<dbscan epsilon parameter>
|
|
|
|
Specify the numPoints parameters to be used for DBSCAN clustering
|
|
(`analysis` mode).
|
|
|
|
.. option:: -analysis-display-unstable-clusters
|
|
|
|
If there is more than one benchmark for an opcode, said benchmarks may end up
|
|
not being clustered into the same cluster if the measured performance
|
|
characteristics are different. by default all such opcodes are filtered out.
|
|
This flag will instead show only such unstable opcodes.
|
|
|
|
.. option:: -ignore-invalid-sched-class=false
|
|
|
|
If set, ignore instructions that do not have a sched class (class idx = 0).
|
|
|
|
.. option:: -mcpu=<cpu name>
|
|
|
|
If set, measure the cpu characteristics using the counters for this CPU. This
|
|
is useful when creating new sched models (the host CPU is unknown to LLVM).
|
|
|
|
EXIT STATUS
|
|
-----------
|
|
|
|
:program:`llvm-exegesis` returns 0 on success. Otherwise, an error message is
|
|
printed to standard error, and the tool returns a non 0 value.
|