Compiling Performance / LLVM

As we’re trying to rebuild our server test suite piece by piece – and there’s still a lot of work go ahead to get a good representative “real world” set of workloads, one more highly desired benchmark amongst readers was a more realistic compilation suite. Chrome and LLVM codebases being the most requested, I landed on LLVM as it’s fairly easy to set up and straightforward.

git clone https://github.com/llvm/llvm-project.git
cd llvm-project
git checkout release/11.x
mkdir ./build
cd ..
mkdir llvm-project-tmpfs
sudo mount -t tmpfs -o size=10G,mode=1777 tmpfs ./llvm-project-tmpfs
cp -r llvm-project/* llvm-project-tmpfs
cd ./llvm-project-tmpfs/build
cmake -G Ninja \
  -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;lldb;compiler-rt;lld" \
  -DCMAKE_BUILD_TYPE=Release ../llvm
time cmake --build .

We’re using the LLVM 11.0.0 release as the build target version, and we’re compiling Clang, libc++abi, LLDB, Compiler-RT and LLD using GCC 10.2 (self-compiled). To avoid any concerns about I/O we’re building things on a ramdisk – on a 4KB page system 5GB should be sufficient but on the Altra’s 64KB system it used up to 9.5GB, including the source directory. We’re measuring the actual build time and don’t include the configuration phase as usually in the real world that doesn’t happen repeatedly.

LLVM Suite Compile Time

The LLVM compile test results here are quite more special and demand more attention that what meets the eye at first.

Inherently, the biggest work slice of the test is massively parallel, able to take advantage of all cores in a system, 256 cores in the 2-socket results of the M128-30, however as it’s also a real-world test, the compilation also incurs linking phases where the chip is inherently just under a single-core load and all other cores are just sitting idle.

This behaviour results in some more complex behaviour in the different test scenarios of the M128-30, as the ratio between the parallel/MT and ST phases of the test changes.

In the single-socket results, the chip showcases a +14% performance boost over the Q80-33, while in the 2S results under quadrant mode, this actually transforms into a 16% performance regression. What’s happening here is that while the increased core count of the chip massively helps in improving the actual compilation of objects, the linking phase of the test is significantly slower and takes up a larger percentage of total test time than on the Q80-33, due to the lower CPU frequencies and smaller SLC of the new chip.

Running the M128-30 in monolithic mode actually results in a 24% reduction in compile time, mostly through a large speedup of the linking phase of the compilation as we’re giving that one active core access to the whole 16MB SLC rather than just a 4MB slice.

AMD’s EPYC 7763, even though it has only half the core count, still manages to outperform the M128-30 in the total test time because the linking phase is much sped up thanks to the much superior single-threaded performance of the cores when few threads are active on the SoC. The 34% advantage of the ST SPEC scores here comes more into play than the MT throughput of the chip.

These results are very interesting, and showcase that even in a more real-world scenario like this, the flock-of-chickens approach doesn’t work out as well even in what would consider a massively parallel workload, as some things just cannot be spread out over multiple cores well. It reminds me very much of the eMAG chip, which also suffered in real world code compilations due to the very same reasons.

SPECjbb MultiJVM - Java Performance Conclusion & End Remarks
POST A COMMENT

60 Comments

View All Comments

  • Unashamed_unoriginal_username_x86 - Thursday, October 7, 2021 - link

    M112-30 in the table on first page says 96 cores? Reply
  • Andrei Frumusanu - Friday, October 8, 2021 - link

    That was a typo. Reply
  • Unashamed_unoriginal_username_x86 - Friday, October 8, 2021 - link

    I'm glad we agree Reply
  • nandnandnand - Thursday, October 7, 2021 - link

    Let's all run out and buy the $800 32-core. Reply
  • mode_13h - Friday, October 8, 2021 - link

    Add in platform costs and it's not going to look like much of a bargain compared with a Threadripper or Xeon W-3300 system. Reply
  • mode_13h - Friday, October 8, 2021 - link

    Of course, if you happen to need specifically an ARM-based workstation, I'm not aware of any better option than Altra. Reply
  • Brutalizer - Sunday, October 10, 2021 - link

    The old SPARC T8 cpu with 32 cores, is still almost faster than all these cpus. Here in the SPECjbb2015, a single cpu achieves 153.500 max, and 90.000 crit.
    https://blogs.oracle.com/bestperf/specjbb2015:-spa...
    Reply
  • Wilco1 - Sunday, October 10, 2021 - link

    Those are results based on weeks/months of tuning, so not at all comparable with this review (the same is true for SPEC scores). In your link a 1S 8180 does 84100 max-jOPS, while the faster 8280 gets 81700 in this review. Similarly the best critical-jOPS is 62600 for the 8180 while the 8280 gets just 47900. Reply
  • Sudharshan Anbarasu - Sunday, October 17, 2021 - link

    How about Monero Mining performance...

    Since $(cache) plays major role in x86 platform, curious to know how it works in Arm architecture.
    Reply

Log in

Don't have an account? Sign up now