I ran some tests locally, and as a first order of approximation,
even without rpmalloc it seems Clang 10 is faster than Clang 9 for a whole build. Although locally when iterating on a single file, it could be slower like Neil suggests.
The test consists in compiling LLVM|Clang|LLD on release/10.x at HEAD using the compilers below. I built each compiler with Clang 10, except MSVC which is provided for reference. Median timings for
a clean build (`ninja all`).
Clang 9.0.1 6 min 48 sec (+/- 23 sec)
Clang 10.0 5 min 55 sec (+/- 5 sec)
Clang 10.0 optimal 5 min 20 sec (+/- 5 sec)
Clang 11 (994543ab) 6 min (+/- 5 sec)
VS2019 16.5.4 7 min 20 (+/- 15 sec)
Tested on Windows 10 build 1909, on a 36-core dual Xeon Gold 6140, with RAID-0 NVMe SSDs. I disabled Windows Defender for the test.
The greater variability in “Clang 9.0.1” is due to launching two processes for each clang-cl invocation, where as 10+ calls only one (like MSVC), see -fintegrated-cc1.
“Clang 10.0 optimal” is a two-stage build using ThinLTO and -O3 on the second stage and tailored for the 6140 (-march=skylake-avx512). It also has D71786 (rpmalloc) applied.
I can possibly take some profile traces, see if anything stands out between 9 and 10.
De : llvm-dev <[hidden email]>
De la part de Tobias Hieta via llvm-dev Envoyé : April 15, 2020 11:17 AM À : Neil Henning <[hidden email]> Cc : llvm-dev <[hidden email]> Objet : Re: [llvm-dev] 7-8% compile time slowdowns in LLVM 10
That's unfortunate - I am in the process of updating to clang 10 here and this slow down will impact our developers as well.
If I have some time this weekend I will try to profile clang and see if I can figure out if there is a single regression or just many smaller things.
On Tue, Apr 14, 2020, 10:26 Neil Henning via llvm-dev <[hidden email]> wrote:
TL;DR - LLVM 10 is around 7-8% slower than LLVM 9 when compiling the same inputs.
So here at Unity our Burst HPC# compiler uses LLVM to provide our users with some very optimal codegen. LLVM is used in two ways:
1. In the Unity editor we JIT compile user code.
2. We also have an AOT mode for when our users are building a full game.
Particularly for 1., compile time really matters for us. Anything we can do to improve compile time will increase our users' experience when editing their gameplay code and seeing what effect it has on the scene they are using. We keep
metrics of compile time as a result, and after hearing the concerns from the Rust folks about LLVM 10's slowdowns I had a look at our numbers with an upgraded LLVM 10 toolchain - you can see a snap from the spreadsheet here that shows an overall 7-8% slowdown
in the compiler
Also since we keep golden asm files for a huge range of important tests we need to preserve, I can also definitively say that the produced asm does not contain any significant improvements to warrant the extra compile time being used (some
changes in register selection and a slightly better placement of instructions).
I don't really have any answers to if or how this can be fixed, I just thought this was a useful data point to the community as a whole and I'd raise the visibility.