CPU Performance: Encoding Tests

With the rise of streaming, vlogs, and video content as a whole, encoding and transcoding tests are becoming ever more important. Not only are more home users and gamers needing to convert video files into something more manageable, for streaming or archival purposes, but the servers that manage the output also manage around data and log files with compression and decompression. Our encoding tasks are focused around these important scenarios, with input from the community for the best implementation of real-world testing.

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

7-zip v1805: Popular Open-Source Encoding Engine

Out of our compression/decompression tool tests, 7-zip is the most requested and comes with a built-in benchmark. For our test suite, we’ve pulled the latest version of the software and we run the benchmark from the command line, reporting the compression, decompression, and a combined score.

It is noted in this benchmark that the latest multi-die processors have very bi-modal performance between compression and decompression, performing well in one and badly in the other. There are also discussions around how the Windows Scheduler is implementing every thread. As we get more results, it will be interesting to see how this plays out.

Please note, if you plan to share out the Compression graph, please include the Decompression one. Otherwise you’re only presenting half a picture.

7-Zip 1805 Compression7-Zip 1805 Decompression7-Zip 1805 Combined

WinRAR 5.60b3: Archiving Tool

My compression tool of choice is often WinRAR, having been one of the first tools a number of my generation used over two decades ago. The interface has not changed much, although the integration with Windows right click commands is always a plus. It has no in-built test, so we run a compression over a set directory containing over thirty 60-second video files and 2000 small web-based files at a normal compression rate.

WinRAR is variable threaded but also susceptible to caching, so in our test we run it 10 times and take the average of the last five, leaving the test purely for raw CPU compute performance.

WinRAR 5.60b3

AES Encryption: File Security

A number of platforms, particularly mobile devices, are now offering encryption by default with file systems in order to protect the contents. Windows based devices have these options as well, often applied by BitLocker or third-party software. In our AES encryption test, we used the discontinued TrueCrypt for its built-in benchmark, which tests several encryption algorithms directly in memory.

The data we take for this test is the combined AES encrypt/decrypt performance, measured in gigabytes per second. The software does use AES commands for processors that offer hardware selection, however not AVX-512.

AES Encoding

Handbrake 1.1.0: Streaming and Archival Video Transcoding

A popular open source tool, Handbrake is the anything-to-anything video conversion software that a number of people use as a reference point. The danger is always on version numbers and optimization, for example the latest versions of the software can take advantage of AVX-512 and OpenCL to accelerate certain types of transcoding and algorithms. The version we use here is a pure CPU play, with common transcoding variations.

We have split Handbrake up into several tests, using a Logitech C920 1080p60 native webcam recording (essentially a streamer recording), and convert them into two types of streaming formats and one for archival. The output settings used are:

  • 720p60 at 6000 kbps constant bit rate, fast setting, high profile
  • 1080p60 at 3500 kbps constant bit rate, faster setting, main profile
  • 1080p60 HEVC at 3500 kbps variable bit rate, fast setting, main profile

Handbrake 1.1.0 - 720p60 x264 6000 kbps FastHandbrake 1.1.0 - 1080p60 x264 3500 kbps FasterHandbrake 1.1.0 - 1080p60 HEVC 3500 kbps Fast

CPU Performance: Simulation Tests CPU Performance: Web and Legacy Tests
Comments Locked

220 Comments

View All Comments

  • catavalon21 - Wednesday, May 20, 2020 - link

    The ability to edit (or ^Z) would be most welcome, trust me.
  • eastcoast_pete - Wednesday, May 20, 2020 - link

    Isn't that Skylake running a bit dry by now? But, seriously, Intel really risks losing a lot of market share in future years by selling these "classics" at high prices, and that is if one can get one in the first place.
    Curious: how many commercial customers buy Intel desktops just because they have iGPUs, but want more CPU oomph than the 3200G has? Is that why Intel still dominates the OEM desktop market?
  • AnarchoPrimitiv - Wednesday, May 20, 2020 - link

    Intel dominates the OEM market through intimidation and threats of retribution... They were literally convicted of bribing OEMs to NOT use AMD CPUs all throughout the 2000s in several courts around the world. The trials uncovered emails between Intel executives that stated, and I quote, "Dell is the best friend money can buy".... The proof is in the fact that currently, the Ryzen 4000 mobile CPUs are the best mobile chips offered right now, but Dell only puts them in the low end laptops. Why? Because Intel is probably giving huge financial incentives to bar AMD from premium designs to perpetuate the myth that AMD isn't a premium brand
  • Retycint - Wednesday, May 20, 2020 - link

    Do keep in mind that these are baseless speculations, based on something that happened 2 decades ago. Both Intel and AMD have changed since then (new engineering team, new management etc) and there has been no evidence of Intel providing incentives to cripple AMD systems. Go take your conspiracy elsewhere.

    And before you inevitably accuse me of being an Intel shill, this isn't about Intel or AMD, it's about facts to support your claim, of which there have been none
  • Irata - Wednesday, May 20, 2020 - link

    Baseless speculation? Financial horsepower, MDF and meet the comp funds are current and no secret.

    Why do you think there are no Ryzen 4000 laptops with GPU above a 2060?
  • Spunjji - Tuesday, May 26, 2020 - link

    Not entirely baseless, as they made two distinct claims. I've been a party to how Intel's "Marketing Development Funds" work - and work it does, at all levels from OEM to reseller to retailer. These days they don't explicitly punish anyone for not buying AMD - they simply tie rebates that will improve the profit margins on a product to specific quantities of those products being sold. It's "nobody's fault" if those quantities happen to make the sale of an AMD product by a given retailer or reseller distinctly unlikely.

    As for incentivizing bad *builds* of AMD systems, though, I'm not so sure. Intel clearly do a lot of work building reference platforms, and the economics of doing integration testing for a new vendor is not trivial. Honestly though, it's hard to tell how we *would* know if this were going on, because it would absolutely be made to look innocent - just like last time.
  • brantron - Wednesday, May 20, 2020 - link

    "literally convicted of bribing"

    1) No. That's not what "literally" means.
    2) No. No one was even *charged* with a crime, much less convicted.
    3) No. It wasn't about bribery.

    The reason Athlon 64s weren't ubiquitous way back when is the same reason the 4000 APUs aren't today - there aren't enough to go around.

    If your post were to be rephrased without hyperbole, baseless accusations, and whataboutism unrelated to the topic of this article, it would read something like this:

    "6 months after AMD's announcement of Renoir, the number of 4000 APUs sold for desktops is literally zero (see how that works?) because TSMC is still slammed."
  • WaWaThreeFIVbroS - Thursday, May 21, 2020 - link

    Your ignorance is amusing
    It is technically a bribery

    https://www.extremetech.com/computing/184323-intel...
  • Spunjji - Tuesday, May 26, 2020 - link

    First 3 points: accurate, if not entirely on-topic. Nobody was charged with a crime, but Intel sure were fined a lot for collusion.

    Which gets to the 4th point: again, accurate, but not entirely relevant. AMD were definitely not able to match Intel for manufacturing, which is why they couldn't have beaten Intel out of the market entirely, but that was barely related to why they weren't getting into Dell systems. See the aforementioned proven-and-fined-for collusion.
  • drothgery - Friday, May 22, 2020 - link

    Or because premium designs take longer when the new chip isn't just another respin of the same thing, and AMD hadn't produced a viable high-end notebook chip in well over a decade so it made sense to wait and see if Ryzen 4000 was any good rather than designing in advance?

Log in

Don't have an account? Sign up now