Compiling LLVM, NAMD Performance

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. 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

Starting off with the Xeon 8380, we’re looking at large generational improvements for the new Ice Lake SP chip. A 33-35% improvement in compile time depending on whether we’re looking at 2S or 1S figures is enough to reposition Intel’s flagship CPU in the rankings by notable amounts, finally no longer lagging behind as drastically as some of the competition.

It’s definitely not sufficient to compete with AMD and Ampere, both showcasing figures that are still 25 and 15% ahead of the Xeon 8380.

The Xeon 6330 is falling in line with where we benchmarked it in previous tests, just slightly edging out the Xeon 8280 (6258R equivalent), meaning we’re seeing minor ISO-core ISO-power generational improvements (again I have to mention that the 6330 is half the price of a 6258R).

NAMD (Git-2020-12-09) - Apolipoprotein A1

NAMD is a problem-child benchmark due to its recent addition of AVX512: the code had been contributed by Intel engineers – which isn’t exactly an issue in my view. The problem is that this is a new algorithm which has no relation to the normal code-path, which remains not as hand-optimised for AVX2, and further eyebrow raising is that it’s solely compatible with Intel’s ICC and no other compiler. That’s one level too much in terms of questionable status as a benchmark: are we benchmarking it as a general HPC-representative workload, or are we benchmarking it solely for the sake of NAMD and only NAMD performance?

We understand Intel is putting a lot of focus on these kinds of workloads that are hyper-optimised to run well extremely on Intel-only hardware, and it’s a valid optimisation path for many use-cases. I’m just questioning how representative it is of the wider market and workloads.

In any case, the GCC binaries of the test on the ApoA1 protein showcase significant performance uplifts for the Xeon 8380, showcasing a +35.6% gain. Using this apples-to-apples code path, it’s still quite behind the competition which scales the performance much higher thanks to more cores.

SPECjbb MultiJVM - Java Performance Conclusion & End Remarks
Comments Locked

169 Comments

View All Comments

  • rahvin - Sunday, April 18, 2021 - link

    The bigger the silicon ingot the more expensive it is to produce. Though the problems with EUV may have delayed development my guess would be the additional cost of the larger ingots negates the cost savings on the other side, particularly with the EUV tools being 10X more expensive.
  • Lukasz Nowak - Thursday, April 8, 2021 - link

    There's another curious thing about the wafer. There are a lot of dies with just clipped corners. If they shifted the entire pattern to the left or right by a quarter of a die, they would get 6 more good ones. That's 7% more dies for free (90 instead of 84).

    Wouldn't that be worth doing?
  • Smell This - Thursday, April 8, 2021 - link


    Maybe Chipzillah can glue them together . . . HA!

    Speaking of which __ it this aN *MCM* multi-chip module ?
  • Chaitanya - Tuesday, April 6, 2021 - link

    Even that upgrade is falling short of catching up.
  • Hifihedgehog - Tuesday, April 6, 2021 - link

    Exactly. What's with these nonsense comments, anyway? It is like bragging about how I can now run a 10-minute mile instead of a 20-minute mile while the star players are breaking world records and running 4-minute miles. *facepalm*
  • Wilco1 - Tuesday, April 6, 2021 - link

    No kidding. It is not even matching Graviton 2! A $8k CPU beaten by an Arm CPU from 2019...
  • Hifihedgehog - Tuesday, April 6, 2021 - link

    and yet that's still a lot of falling short for Intel 🤷‍♂️
  • fallaha56 - Tuesday, April 6, 2021 - link

    not really, the 38 and 40 core parts won't be available in any amounts (see Semiaccurate)

    and as can be seen in the lower spec parts, suddenly Ice Lake is barely beating Cascake Lake never mind AMD
  • fallaha56 - Tuesday, April 6, 2021 - link

    https://semiaccurate.com/2021/04/06/intels-ice-lak...
  • Gondalf - Wednesday, April 7, 2021 - link

    LOL semi-accurate. 40-38 cores parts already for sale.

Log in

Don't have an account? Sign up now