[compilerdev]

The Chrome compilation looks really strange indeed, especially with having the results from Phoronix on Linux which show that it's the fastest compiling the Linux kernel. I wonder what kind of Chrome build it's doing - does it use Clang-cl or Visual C++? Does it have LTO (LTCG for VC++) enabled? If it's VC++ with LTCG, for example, the entire code generation and linking is limited to 4 cores by default.

[gsnedders]

It's Chromium 56 with the default Chromium build-chain.

At that point, Chromium required Visual Studio 2015 Update 3 or later. Anand use VS Community 2015.3. IIRC, by default it doesn't have LTCG enabled.

By default, release builds are almost entirely statically linked (with a few shared libraries, platform dependent), which makes linking time pretty significant. As a result, it ends up more as a linking benchmark than a compilation benchmark.

[compilerdev]

Ian Cutress replied on the article comments that LTCG is indeed used. With LTCG those strange results make sense - it's spending a lot of time on just 4 threads by default - actually majority of the time is on one thread for the Chromium case, it hits some current limitations of the VC++ compiler regarding CPU/memory usage that makes scaling worse for Chromium (but not for smaller programs or with non-LTCG builds). Increasing the number of threads from the default of 4 is possible, but will not help here. The frontend (parsing) work is well parallelized by Ninja, it's probably the reason why the Threadrippers do end up ahead of the faster single-core Intel CPUs.

[glandium]

There's a significant workload difference between compiling the Linux kernel (C code base) and Chromium (C++ code base). I'd very much like to see a Chromium build benchmark performed under Linux.

[compilerdev]

See my answer above, it's because the build was LTCG and in the best case at most 4 cores were used during optimization/code geneation/linking.

[glandium]

That's not what I'm talking about, though. Compiling large C++ code requires much more memory than compiling C, which, on a TR and its NUMA architecture, can make significant differences. And we do know that Linux tends to work better on NUMA than Windows, so comparing a C compile on Linux to a C++ compile on Windows, even if it didn't have the LTCG setup problem, would still be apples to oranges.

[gok]

That Phoronix says the opposite makes me think Anandtech is right....