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

  • Hifihedgehog - Tuesday, April 6, 2021 - link

    Correction: Maybe if it was released over two years ago...
  • amootpoint - Wednesday, April 7, 2021 - link

    Not really. Just look at the perf numbers vs AMD. Intel is broadly winning.
  • Bagheera - Thursday, April 8, 2021 - link

    which review article did you read? didn't sound like you read the same one I did.
  • Unashamed_unoriginal_username_x86 - Tuesday, April 6, 2021 - link

    the 8280 core to core bounce latency image is 404ing
  • Ryan Smith - Tuesday, April 6, 2021 - link

    This has been fixed. Thanks!
  • JayNor - Tuesday, April 6, 2021 - link

    News release says "The platform supports up to 6 terabytes of system memory per socket".
    This story says 4TB. Is Intel wrong?
  • ParalLOL - Tuesday, April 6, 2021 - link

    Depends on whether you agree to say that Optane is "system memory". It is mapped onto address space and is directly attached to CPU so it probably can be said to be system memory.
  • DigitalFreak - Tuesday, April 6, 2021 - link

    It's like when Intel says their desktop processors have 40 PCIe lanes. It's actually 16 CPU and 32 chipset. Well 20 CPU with Rocket Lake, but still...
  • brucethemoose - Tuesday, April 6, 2021 - link

    Y'all are measuring power from the socket sensors, not the wall, right?

    I think the later would be more interesting, even with the apples-to-oranges factor of different hardware surrounding the platform. After all, whole system power consumption is what one gets charged for.
  • Jorgp2 - Tuesday, April 6, 2021 - link

    That would vary massively between systems.

Log in

Don't have an account? Sign up now