Benchmarking Performance: CPU Office Tests

The office programs we use for benchmarking aren't specific programs per-se, but industry standard tests that hold weight with professionals. The goal of these tests is to use an array of software and techniques that a typical office user might encounter, such as video conferencing, document editing, architectural modeling, and so on and so forth.

All of our benchmark results can also be found in our benchmark engine, Bench.

Chromium Compile (v56)

Our new compilation test uses Windows 10 Pro, VS Community 2015.3 with the Win10 SDK to compile a nightly build of Chromium. We've fixed the test for a build in late March 2017, and we run a fresh full compile in our test. Compilation is the typical example given of a variable threaded workload - some of the compile and linking is linear, whereas other parts are multithreaded.

Office: Chromium Compile (v56)

Our Chrome Compile test is a mix of load, but also loves L3 cache. We've seen before that the L3 victim cache on AMD can be a defecit here, but even then the Core i5 cannot overcome the 3:1 thread deficit to the Ryzen 5 CPUs. The Core i7-7740X hits the nail on the head for threads and single thread performance, although users that play in this space would look straight to the Core i7-7800X, and likely decide that +16.5% better performance is worth the +18.2% extra cost.

PCMark8: link

Despite originally coming out in 2008/2009, Futuremark has maintained PCMark8 to remain relevant in 2017. On the scale of complicated tasks, PCMark focuses more on the low-to-mid range of professional workloads, making it a good indicator for what people consider 'office' work. We run the benchmark from the commandline in 'conventional' mode, meaning C++ over OpenCL, to remove the graphics card from the equation and focus purely on the CPU. PCMark8 offers Home, Work and Creative workloads, with some software tests shared and others unique to each benchmark set.

Office: PCMark8 Creative (non-OpenCL)

Office: PCMark8 Home (non-OpenCL)

Office: PCMark8 Work (non-OpenCL)

SYSmark 2014 SE: link

SYSmark is developed by Bapco, a consortium of industry CPU companies. The goal of SYSmark is to take stripped down versions of popular software, such as Photoshop and Onenote, and measure how long it takes to process certain tasks within that software. The end result is a score for each of the three segments (Office, Media, Data) as well as an overall score. Here a reference system (Core i3-6100, 4GB DDR3, 256GB SSD, Integrated HD 530 graphics) is used to provide a baseline score of 1000 in each test.

A note on context for these numbers. AMD left Bapco in the last two years, due to differences of opinion on how the benchmarking suites were chosen and AMD believed the tests are angled towards Intel processors and had optimizations to show bigger differences than what AMD felt was present. The following benchmarks are provided as data, but the conflict of opinion between the two companies on the validity of the benchmark is provided as context for the following numbers.

Office: SYSMark 2014 SE (Office)Office: SYSMark 2014 SE (Media)Office: SYSMark 2014 SE (Data)Office: SYSMark 2014 SE (Responsiveness)

Office: SYSMark 2014 SE (Overall)

Benchmarking Performance: CPU Encoding Tests Benchmarking Performance: CPU Legacy Tests
Comments Locked

176 Comments

View All Comments

  • iwod - Monday, July 24, 2017 - link

    Intel has 10nm and 7nm by 2020 / 2021. Core Count is basically a solved problem, limited only by price.

    What we need is a substantial breakthrough in single thread performance. May be there are new material that could bring us 10+Ghz. But those aren't even on the 5 years roadmap.
  • mapesdhs - Monday, July 24, 2017 - link

    That's more down to better sw tech, which alas lags way behind. It needs skills that are largely not taught in current educational establishments.
  • wolfemane - Monday, July 24, 2017 - link

    Under Handbrake testing, just above the first graph you state:
    "Low Quality/Resolution H264: He we transcode a 640x266 H264 rip of a 2 hour film, and change the encoding from Main profile to High profile, using the very-fast preset."

    I think you mean to say "HERE we transcode..."

    Great article overall. Thank you!
  • Ian Cutress - Monday, July 24, 2017 - link

    Thanks, corrected :)
  • wolfemane - Monday, July 24, 2017 - link

    I wish your team would finally add in an edit button to comments! :)

    On the last graph ENCODING: Handbrake HEVC (4k) you don't list the 1800x, but it is present in the previous two graphs @ LQ and HQ. Was there an issue with the 1800x preventing 4k testing? Quite interested in it's results if you have them.
  • Ian Cutress - Monday, July 24, 2017 - link

    When I first did the HEVC testing for the Ryzen 7 review, there was a slight issue in it running and halfway through I had to change the script because the automation sometimes dropped a result (like the 1800X which I didn't notice until I was 2-3 CPUs down the line). I need to put the 1800X back on anyway for AGESA 1006, which will be in an upcoming article.
  • IanHagen - Monday, July 24, 2017 - link

    One thing that caught my eye for a while is how compile tests using GCC or clang show much better results on Ryzen compared to using Microsoft's VS compiler. Phoronix tests clearly shows that. Thus, I cannot really believe yet on Ian's recurring explanation of Ryzen suffering from its victim L3 cache. After all, the 1800X beats the 7700K by a sizable margin when compiling the Linux kernel.

    Isn't Ryzen relatively poor performance compiling Chromium due to idiosyncrasies of the VS compiler?
  • Ian Cutress - Monday, July 24, 2017 - link

    The VS compiler seems to love L3 cache, then. The 1800X does have 2x threads and 2x cores over the 7700K, accounting for the difference. We saw a -17% drop going from SKL-S with its fully inclusive L3 to SKL-SP with a victim L3, clock for clock.

    Chromium was the best candidate for a scripted, consistent compile workflow I could roll into our new suite (and runs on Windows). Always open for suggestions that come with an ELI5.
  • ddriver - Monday, July 24, 2017 - link

    So we are married to chromium, because it only compiles with msvc on windows?

    Or maybe because it is a shitty implementation that for some reason stacks well with intel's offerings?

    Pardon my ignorance, I've only been a multi-platform software developer for 8 years, but people who compile stuff a lot usually don't compile chromium all day.

    I'd say go GCC or Clang, because those are quality community drive open source compilers that target a variety of platforms, unlike msvc. I mean if you really want to illustrate the usefulness of CPUs for software developers, which at this point is rather doubtful...
  • Ian Cutress - Monday, July 24, 2017 - link

    Again, find me something I can rope into my benchmark suite with an ELI5 guide and I try and find time to look into it. The Chromium test took the best part of 2-3 days to get in a position where it was scripted and repeatable and fit with our workflow - any other options I examined weren't even close. I'm not a computer programmer by day either, hence the ELI5 - just years old knowledge of using Commodore BASIC, batch files, and some C/C++/CUDA in VS.

Log in

Don't have an account? Sign up now