Benchmarking Performance: SPECwpc v2.1

Anyone can run wPrime (why would you?) or Geekbench, but more often than not these pre-built synthetic tests are not representative of any user’s workload. This applies even more to professional environments or prosumer workloads, where time is money: if someone interested in hardware cannot pinpoint exactly how the new hardware is going to benefit them, that is $20 of billable time down the drain.

One of the difficulties of a benchmark reviewer is finding relevant benchmarks for the audience at hand. I’ve discussed what AnandTech is and our audience to several high profile software vendors who are in the business of supplying professional grade, critical programs that top technology companies use to produce the next $700 smartphone. These engineers are our readers, and it only seems best that we benchmark something that can assist them in accelerating our workflow. Unfortunately, the almost blanket response from these ISVs is negative, even if the request is for a limited software license in exchange for repeated discussion of the software on AnandTech (and third party benchmark data to assist their customers in hardware purchasing). My last discussions with two major ISVs led to a ‘interesting but we don’t see the value’ response and a ‘we’re doing our own in-house thing’ response respectively. No-one wants to know. Unless you work at one of these companies and want to get in touch.

The fall-back position in this case is to call on SPEC for their Workstation benchmark series. SPECwpc has existed in one form or another for several years, using pre-compiled binaries for a mix of medical, oil-and-gas, engineering, visualization and system level benchmarks. There are over 30 benchmarks, some running multiple copies to keep all the cores busy, and repeated runs offer very good consistency. A full run can take over six hours, making a sizeable increase to even our CPU workflow.

We’re reporting almost all of the subset scores in our benchmarking. Some tests require a GPU, and so we maintain the same RX 460 graphics card on each processor we test, along with the same screen resolution and driver. Ideally we would use professional graphics cards, like AMD’s FirePro range or NVIDIA’s Quadro range, however we currently use four identical RX 460 cards to keep the benchmarks on our test beds continually flowing, and sourcing four of the same pro card on long-term loan is actually fairly difficult.

Because SPECwpc takes so long and is fairly new, we only have results for a few processors so far. This should expand as we continue using this test. We’re likely to limit this test to HEDT processors and above, along with one or two mainstream processors (i7-K, Ryzen 7). For this review, out of the two Intel processors in the title, we only had time to run it on the Core i9-7980XE.

SpecWPC v2.1 - Part 1, Media-2: HandBrake

SpecWPC v2.1 - Part 1, Media-3: LuxRender

SpecWPC v2.1 - Part 1, Media-4: Maya

SpecWPC v2.1 - Part 2, Development-1: Rodinia

SpecWPC v2.1 - Part 2, Development-2: CalculiX

SpecWPC v2.1 - Part 2, Development-3: WPCcfd

SpecWPC v2.1 - Part 2, Development-4: Catia

SpecWPC v2.1 - Part 2, Development-5: Creo

SpecWPC v2.1 - Part 2, Development-6: Showcase

SpecWPC v2.1 - Part 2, Development-7: SNX

SpecWPC v2.1 - Part 2, Development-8: SW

SpecWPC v2.1 - Part 3, Life Sciences-1: Lammps

SpecWPC v2.1 - Part 3, Life Sciences-2: namd

SpecWPC v2.1 - Part 3, Life Sciences-3: Medical

SpecWPC v2.1 - Part 4, Financial-1: Monte Carlo

SpecWPC v2.1 - Part 4, Financial-2: Black Scholes

SpecWPC v2.1 - Part 4, Financial-3: Binomial

SpecWPC v2.1 - Part 5, Energy-1: FFTW

SpecWPC v2.1 - Part 5, Energy-2: Convolution

SpecWPC v2.1 - Part 5, Energy-3: Energy-03

SpecWPC v2.1 - Part 5, Energy-4: srmp

SpecWPC v2.1 - Part 5, Energy-5: Kirchhoff Migration

SpecWPC v2.1 - Part 5, Energy-6: Poisson

SpecWPC v2.1 - Part 6, General-1: 7-Zip

SpecWPC v2.1 - Part 6, General-2: Python

SpecWPC v2.1 - Part 6, General-3: Octave

Benchmark Overview Benchmarking Performance: PCMark 10
Comments Locked

152 Comments

View All Comments

  • mapesdhs - Monday, September 25, 2017 - link

    Just curious mmrezaie, why do you say "unofficially"? ECC support is included on specs pages for X399 boards.
  • frowertr - Tuesday, September 26, 2017 - link

    Run Unbound on a Pi or other Linux VM and block all thise adverts at the DNS level for all the devices on your LAN. I havent seen a site add anywhere in years from my home.
  • Notmyusualid - Thursday, September 28, 2017 - link

    @frowertr

    Interesting - But that won't work for me - I'm a frequent traveller, and thus on different LANs all the time.

    But what works for me, is PeerBlock, then iblocklist.com for the Ad-server & Malicious lists and others, add Microsoft and any other entity I don't want my packets broadcast to (my Antivirus alerts me when I need updates anyway - and thus I temporarily allow http through the firewall for that type of occasion).
  • realistz - Monday, September 25, 2017 - link

    This is why the "core wars" won't be a good thing for consumers. Focus on better single thread perf instead quantity.
  • sonichedgehog360@yahoo.com - Monday, September 25, 2017 - link

    On the contrary, single-threaded performance is largely a dead end until we hit quantum computing due to instability inherent to extremely high clock speeds. The core wars is exactly what we need to incentivize developers to improve multi-core scaling and performance: it represents the future of computing.
  • extide - Monday, September 25, 2017 - link

    Some things just can't be split up into multiple threads -- it's not a developer skill level or laziness issue, it's just the way it is. Single threaded speed will always be important.
  • PixyMisa - Monday, September 25, 2017 - link

    Maybe, but it's still a dead end. It's not going to improve much, ever.
  • HStewart - Monday, September 25, 2017 - link

    As a developer for 30 years this is absolutely correct - especially with the user interface logic which includes graphics. Until technology is a truly able to multi-thread the display logic and display hardware - it very important to have single thread performance. I would think this is critically important for games since they deal a lot with screen. Intel has also done something very wise and I believe they realize this important - by allowing some cores to go faster than others. Multi-core is basically hardware assisted multi-threaded applications which is very dependent on application design - most of time threads are used for background tasks. Another critical error is database logic - unless the database core logic is designed to be multithread, you will need single point of entry and in some cases - they database must be on screen thread. Of course with advancement is possible hardware to handle threading and such, it might be possible to over come these limitations. But in NO WAY this is laziness of developer - keep in mind a lot of software has years of development and to completely rewrite the technology is a major and costly effort.
  • lilmoe - Monday, September 25, 2017 - link

    There are lots of instances where I'd need summation and other complex algorithm results from millions of records in certain tables. If I'm going the traditional sql route, it would take ages for the computation to return the desired values. I instead divide the load one multiple threads to get a smaller set in which I would perform some cleanup and final arithmetic. Lots of extra work? Yup. More ram per transaction total? Oh yea. Faster? Yes, dramatically faster.

    WPF was the first attempt by Microsoft to distribute UI load across multiple cores in addition to the gpu, it was so slow in its early days due to lots out inefficiencies and premature multi-core hardware. It's alot better now, but much more work than WinForms as you'd guess. UWP UI is also completely multithreaded.

    Android is inching closer to completely have it's UI multithreaded and separate from the main worker thread. We're getting there.

    Both you and sonich are correct, but it's also a fact that developers are taking their sweet time to get familiar with and/or use these technologies. Some don't want to that route simply because of technology bias and lock-in.
  • HStewart - Monday, September 25, 2017 - link

    "Both you and sonich are correct, but it's also a fact that developers are taking their sweet time to get familiar with and/or use these technologies. Some don't want to that route simply because of technology bias and lock-in."

    That is not exactly what I was saying - it completely understandable to use threads to handle calculation - but I am saying that the designed of hardware with a single screen element makes it hard for true multi-threading. Often the critical sections must be lock - especially in a multi-processor system.

    The best use of multi-threading and mult-cpu systems is actually in 3D rendering, this is where multiple threads can be use to distribute the load. In been a while since I work with Lightwave 3D and Vue, but in those days I would create a render farm - one of reason, I purchase a Dual Xeon 5160 ten years ago. But now a days processors like these processors here could do the work or 10 or normal machines on my farm ( Xeon was significantly more power then the P4's - pretty much could do the work of 4 or more P4's back then )

Log in

Don't have an account? Sign up now