CPU Tests: Office and Science

Our previous set of ‘office’ benchmarks have often been a mix of science and synthetics, so this time we wanted to keep our office section purely on real world performance.

Agisoft Photoscan 1.3.3: link

The concept of Photoscan is about translating many 2D images into a 3D model - so the more detailed the images, and the more you have, the better the final 3D model in both spatial accuracy and texturing accuracy. The algorithm has four stages, with some parts of the stages being single-threaded and others multi-threaded, along with some cache/memory dependency in there as well. For some of the more variable threaded workload, features such as Speed Shift and XFR will be able to take advantage of CPU stalls or downtime, giving sizeable speedups on newer microarchitectures.

For the update to version 1.3.3, the Agisoft software now supports command line operation. Agisoft provided us with a set of new images for this version of the test, and a python script to run it. We’ve modified the script slightly by changing some quality settings for the sake of the benchmark suite length, as well as adjusting how the final timing data is recorded. The python script dumps the results file in the format of our choosing. For our test we obtain the time for each stage of the benchmark, as well as the overall time.

(1-1) Agisoft Photoscan 1.3, Complex Test

Photoscan has variable thread scaling, so while in general we see better results with more threads, the frequency of the cores comes into play when 1-16 threads are needed in those portions of the calculation. As a result the 64C/64T versions are better here, and TR Pro has a slight advantage over TR due to memory bandwidth. Nonetheless, the consumer R9 5950X wins out.

 

Science

In this version of our test suite, all the science focused tests that aren’t ‘simulation’ work are now in our science section. This includes Brownian Motion, calculating digits of Pi, molecular dynamics, and for the first time, we’re trialing an artificial intelligence benchmark, both inference and training, that works under Windows using python and TensorFlow.  Where possible these benchmarks have been optimized with the latest in vector instructions, except for the AI test – we were told that while it uses Intel’s Math Kernel Libraries, they’re optimized more for Linux than for Windows, and so it gives an interesting result when unoptimized software is used.

3D Particle Movement v2.1: Non-AVX and AVX2/AVX512

This is the latest version of this benchmark designed to simulate semi-optimized scientific algorithms taken directly from my doctorate thesis. This involves randomly moving particles in a 3D space using a set of algorithms that define random movement. Version 2.1 improves over 2.0 by passing the main particle structs by reference rather than by value, and decreasing the amount of double->float->double recasts the compiler was adding in.

The initial version of v2.1 is a custom C++ binary of my own code, and flags are in place to allow for multiple loops of the code with a custom benchmark length. By default this version runs six times and outputs the average score to the console, which we capture with a redirection operator that writes to file.

For v2.1, we also have a fully optimized AVX2/AVX512 version, which uses intrinsics to get the best performance out of the software. This was done by a former Intel AVX-512 engineer who now works elsewhere. According to Jim Keller, there are only a couple dozen or so people who understand how to extract the best performance out of a CPU, and this guy is one of them. To keep things honest, AMD also has a copy of the code, but has not proposed any changes.

The 3DPM test is set to output millions of movements per second, rather than time to complete a fixed number of movements.

(2-1) 3D Particle Movement v2.1 (non-AVX)

In a non-AVX mode, having a full 128 threads works best here, and TR beats TR Pro because there is very little memory bandwidth required. 

(2-2) 3D Particle Movement v2.1 (Peak AVX)

When we move into peak performance mode, the Intel chips with AVX512 scream out ahead. The AMD processors still get a rough 2x performance increase with AVX2, but the order still remains.

y-Cruncher 0.78.9506: www.numberworld.org/y-cruncher

If you ask anyone what sort of computer holds the world record for calculating the most digits of pi, I can guarantee that a good portion of those answers might point to some colossus super computer built into a mountain by a super-villain. Fortunately nothing could be further from the truth – the computer with the record is a quad socket Ivy Bridge server with 300 TB of storage. The software that was run to get that was y-cruncher.

Built by Alex Yee over the last part of a decade and some more, y-Cruncher is the software of choice for calculating billions and trillions of digits of the most popular mathematical constants. The software has held the world record for Pi since August 2010, and has broken the record a total of 7 times since. It also holds records for e, the Golden Ratio, and others. According to Alex, the program runs around 500,000 lines of code, and he has multiple binaries each optimized for different families of processors, such as Zen, Ice Lake, Sky Lake, all the way back to Nehalem, using the latest SSE/AVX2/AVX512 instructions where they fit in, and then further optimized for how each core is built.

For our purposes, we’re calculating Pi, as it is more compute bound than memory bound. In single thread mode we calculate 250 million digits, while in multithreaded mode we go for 2.5 billion digits. That 2.5 billion digit value requires ~12 GB of DRAM, and so is limited to systems with at least 16 GB.

(2-4) yCruncher 0.78.9506 MT (2.5b Pi)

In full multithreaded mode, y-Cruncher eats memory bandwidth for breakfast. TR Pro is the clear winner here, but also bandwidth per core is important, and 64C/64T is preferred.

NAMD 2.13 (ApoA1): Molecular Dynamics

One of the popular science fields is modeling the dynamics of proteins. By looking at how the energy of active sites within a large protein structure over time, scientists behind the research can calculate required activation energies for potential interactions. This becomes very important in drug discovery. Molecular dynamics also plays a large role in protein folding, and in understanding what happens when proteins misfold, and what can be done to prevent it. Two of the most popular molecular dynamics packages in use today are NAMD and GROMACS.

NAMD, or Nanoscale Molecular Dynamics, has already been used in extensive Coronavirus research on the Frontier supercomputer. Typical simulations using the package are measured in how many nanoseconds per day can be calculated with the given hardware, and the ApoA1 protein (92,224 atoms) has been the standard model for molecular dynamics simulation.

Luckily the compute can home in on a typical ‘nanoseconds-per-day’ rate after only 60 seconds of simulation, however we stretch that out to 10 minutes to take a more sustained value, as by that time most turbo limits should be surpassed. The simulation itself works with 2 femtosecond timesteps. We use version 2.13 as this was the recommended version at the time of integrating this benchmark into our suite. The latest nightly builds we’re aware have started to enable support for AVX-512, however due to consistency in our benchmark suite, we are retaining with 2.13. Other software that we test with has AVX-512 acceleration.

(2-5) NAMD ApoA1 Simulation

NAMD can use all 128 threads, showcasing 64C/128T as being the better performer. Interestingly though the TR 3990X doesn't do so well here at 64C/64T, but the 3995WX does.

AI Benchmark 0.1.2 using TensorFlow: Link

Finding an appropriate artificial intelligence benchmark for Windows has been a holy grail of mine for quite a while. The problem is that AI is such a fast moving, fast paced word that whatever I compute this quarter will no longer be relevant in the next, and one of the key metrics in this benchmarking suite is being able to keep data over a long period of time. We’ve had AI benchmarks on smartphones for a while, given that smartphones are a better target for AI workloads, but it also makes some sense that everything on PC is geared towards Linux as well.

Thankfully however, the good folks over at ETH Zurich in Switzerland have converted their smartphone AI benchmark into something that’s useable in Windows. It uses TensorFlow, and for our benchmark purposes we’ve locked our testing down to TensorFlow 2.10, AI Benchmark 0.1.2, while using Python 3.7.6.

The benchmark runs through 19 different networks including MobileNet-V2, ResNet-V2, VGG-19 Super-Res, NVIDIA-SPADE, PSPNet, DeepLab, Pixel-RNN, and GNMT-Translation. All the tests probe both the inference and the training at various input sizes and batch sizes, except the translation that only does inference. It measures the time taken to do a given amount of work, and spits out a value at the end.

There is one big caveat for all of this, however. Speaking with the folks over at ETH, they use Intel’s Math Kernel Libraries (MKL) for Windows, and they’re seeing some incredible drawbacks. I was told that MKL for Windows doesn’t play well with multiple threads, and as a result any Windows results are going to perform a lot worse than Linux results. On top of that, after a given number of threads (~16), MKL kind of gives up and performance drops of quite substantially.

So why test it at all? Firstly, because we need an AI benchmark, and a bad one is still better than not having one at all. Secondly, if MKL on Windows is the problem, then by publicizing the test, it might just put a boot somewhere for MKL to get fixed. To that end, we’ll stay with the benchmark as long as it remains feasible.

(2-6) AI Benchmark 0.1.2 Total

This benchmark likes high IPC, and R9 has it in spades.

CPU Tests: Encoding CPU Tests: Simulation
Comments Locked

98 Comments

View All Comments

  • DesireeTR - Wednesday, July 14, 2021 - link

    OK, found the news too. IDK if I can link any other website here other than Anandtech, but look for "Lenovo is Using AMD PSB to Vendor Lock AMD CPUs" from servethehome, dated April 5th 2021. Lenovo P620 with Threadripper Pro was tested and found that they used the strict PSB lock-in like Dell do on their PowerEdge servers.
  • Threska - Wednesday, July 14, 2021 - link

    I think "permanently" is the biggest concern, otherwise it could be a great feature as part of a "root of trust" if the user could control it, especially via hardware modification. e.g. jumper.
  • DesireeTR - Wednesday, July 14, 2021 - link

    Yeah, and if this trend continues, the Ryzen PRO definitely is next on the line getting this PSB. Laptops might be OK, since they use soldered BGA processor anyway, but definitely a big no no for prebuild towers.
  • arashi - Saturday, July 17, 2021 - link

    If it can be overridden like that then it isn't a root of trust anymore.
  • Threska - Saturday, July 17, 2021 - link

    There's the presumption you trust yourself.
  • Mikewind Dale - Wednesday, July 14, 2021 - link

    Dear Anandtech: If you ever review the motherboards, I'll relate something a few things I discovered about the Supermicro M12SWA-TF:

    First, it cannot use sleep mode. If you put the computer to sleep, then when you wake it up, the fans will all spin at low RPM, and they will fail to adjust to temperature. HWiNFO64 reports two sets of sensors: one set is direct, and the other is indirect, via the IPMI. After waking from sleep, the direct sensor readings were still reported, but the indirect-via-IPMI sensors were all null. When I logged into the BMC/IPMI, all the sensors were null there too. And when I ran a CPU burn-in after waking from sleep, my CPU temperature quickly climbed higher than normal, and the fans did NOT ramp up their RPM. (I was prepared for this, so I was running only a single-threaded CPU benchmark.)

    Not only did rebooting the computer fix the problem, but so did Windows hibernate. The fact that Windows hibernate fixed the problem told me that the problem was hardware, not OS.

    I contacted Supermicro, and they said this behavior is normal (!!!!!!). They explained that the IPMI controls the fan RPM, but it only connects to the sensors during POST. If you put the computer to sleep, the IPMI loses its connection to the sensors, and it cannot resume that connection until the computer POSTs again.

    So if you review the motherboards, make sure to test the sleep behavior.

    Second, the Supermicro board is programmed with critical low fan RPM threshholds that are lower than Noctua's RPM. If you Google, you'll see a lot of people have problems with using Noctua fans with Supermicro boards. What happens is, the the Noctua fan's RPM will drop below the critical low RPM threshholds, so the Supermicro board will think the fan is failing, and it will quickly ramp the fan up to 100% PWM. Once the fan exceeds the critical low RPM threshold, the alert will end, and the fan will drop its RPM back down again, starting the cycle over. So the fans cycle back and forth between high and low RPM. When I logged into the IPMI, I saw that I every single fan was triggering the low RPM alert every few seconds.

    The solution is to reprogram the IPMI with new critical low RPM thresholds. Supermicro's own IPMI software does NOT allow this, because Supermicro explained to me that some people have overheated and fried their motherboards using insufficient cooling. So I had to use a third-party tool called "ipmitool".

    Usually, ipmitool is obtained via "sudo apt-get install ipmitool". However, I found that the Linux version was unable to establish a connection with my BMC, even though other IPMI tools had no problem with establishing that connection. But other IPMI tools did not have the ability to reprogram the fan thresholds.

    Luckily, the Windows version of ipmitool was able to establish a connection and alter my fan thresholds just fine. The Windows version is available at https://www.dannynieuwenhuis.nl/download-windows-i...

    If you Google, you'll find many, many different websites offering instructions for how to use ipmitool to modify your Supermicro board to be compatible with Noctua fans. I'll just give a few sample lines of code here, in case anyone needs them:

    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN1 lower 40 140 240
    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN1 upper 1650 1750 1850

    Where:
    --- FAN1 is the name of the fan header, as labeled in the motherboard manual. Options are FAN1-FAN6 and FANA-FAND.
    --- "lower" numbers are lower non-recoverable, lower critical, and lower non-critical, in that order.
    --- "upper" numbers are upper non-critical, upper critical, and upper non-recoverable, in that order.

    To calculate the thresholds, I did the following:
    First, I looked up Noctua's specs. FAN1 is my Noctua NH-U14S TR4-SP3. According to Noctua, its fan's RPM are 300 +/-20% to 1500 +/- 10% RPM.
    Second, I set the lower non-critical to 300*0.8 (i.e. -20%) and the upper non-critical to 1500*1.1 (i.e. +10%).
    Third, for the critical and non-recoverable thresholds, I just added or subtracted 100%.

    Do the same for every other fan in every other header. I wrote about every line in a .BAT file in Windows, which read like this:

    REM **************************************************************************************************
    REM **********
    REM FAN1 is Noctua NH-U14S TR4-SP3: 300 +/-20% to 1500 +/- 10% RPM
    REM **********

    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN1 lower 40 140 240
    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN1 upper 1650 1750 1850
    REM **************************************************************************************************

    REM **************************************************************************************************
    REM **********
    REM FAN2 is Noctua NF-A15: 300 +/- 20% to 1200 +/- 10%
    REM **********

    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN2 lower 40 140 240
    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN2 upper 1320 1420 1520
    REM **************************************************************************************************

    and so forth, for every fan header. This successfully solved the problem of the fans triggering the threshold alerts and cycling up and down.
  • Mikewind Dale - Wednesday, July 14, 2021 - link

    "Second, the Supermicro board is programmed with critical low fan RPM threshholds that are lower than Noctua's RPM."

    I meant *higher*. The Supermicro default critical low fan RPM thresholds are *higher* than Noctua's.
  • Mikewind Dale - Wednesday, July 14, 2021 - link

    Oh, and because sleep mode is dangerous, threatening to potentially fry your CPU (since the fans no longer respond to temperature), I not only set my computer never to sleep, but I removed sleep from the power options in the start menu. That way, I cannot accidentally put the computer to sleep.

    If you do ever put your Supermicro M12SWA-TF to sleep, you will not receive any alerts that every sensor is null. If you log into the BMC, you'll see every sensor is null, but there are no alerts. And the fans all spin at minimum RPM regardless of your fan setting, and regardless of temperature. So sleep mode appears to have the potential to fry your CPU.
  • Threska - Wednesday, July 14, 2021 - link

    You keep saying "fry" but haven't CPUs had thermal protection for ages at this point?
  • Mikewind Dale - Wednesday, July 14, 2021 - link

    Threska, possibly. But I didn't want to find out.

    At best, sleep mode would cause the computer to constantly downclock or shut down without any clear cause (unless the user realized it was because sleep mode deactivated the IPMI's reporting of the sensors while the sensors themselves were still reporting values to software such as HWiNFO).

Log in

Don't have an account? Sign up now