The AMD Ryzen 5 1600X vs Core i5 Review: Twelve Threads vs Four at $250
by Ian Cutress on April 11, 2017 9:00 AM ESTBenchmarking Performance: CPU Encoding Tests
One of the interesting elements on modern processors is encoding performance. This includes encryption/decryption, as well as video transcoding from one video format to another. In the encrypt/decrypt scenario, this remains pertinent to on-the-fly encryption of sensitive data - a process by which more modern devices are leaning to for software security. Video transcoding as a tool to adjust the quality, file size and resolution of a video file has boomed in recent years, such as providing the optimum video for devices before consumption, or for game streamers who are wanting to upload the output from their video camera in real-time. As we move into live 3D video, this task will only get more strenuous, and it turns out that the performance of certain algorithms is a function of the input/output of the content.
7-Zip
One of the freeware compression tools that offers good scaling performance between processors is 7-Zip. It runs under an open-source licence, is fast, and easy to use tool for power users. We run the benchmark mode via the command line for four loops and take the output score.
WinRAR 5.40
For the 2017 test suite, we move to the latest version of WinRAR in our compression test. WinRAR in some quarters is more user friendly that 7-Zip, hence its inclusion. Rather than use a benchmark mode as we did with 7-Zip, here we take a set of files representative of a generic stack (33 video files in 1.37 GB, 2834 smaller website files in 370 folders in 150 MB) of compressible and incompressible formats. The results shown are the time taken to encode the file. Due to DRAM caching, we run the test 10 times and take the average of the last five runs when the benchmark is in a steady state.
AES Encoding
Algorithms using AES coding have spread far and wide as a ubiquitous tool for encryption. Again, this is another CPU limited test, and modern CPUs have special AES pathways to accelerate their performance. We often see scaling in both frequency and cores with this benchmark. We use the latest version of TrueCrypt and run its benchmark mode over 1GB of in-DRAM data. Results shown are the GB/s average of encryption and decryption.
HandBrake H264 and HEVC
As mentioned above, video transcoding (both encode and decode) is a hot topic in performance metrics as more and more content is being created. First consideration is the standard in which the video is encoded, which can be lossless or lossy, trade performance for file-size, trade quality for file-size, or all of the above can increase encoding rates to help accelerate decoding rates. Alongside Google's favorite codec, VP9, there are two others that are taking hold: H264, the older codec, is practically everywhere and is designed to be optimized for 1080p video, and HEVC (or H265) that is aimed to provide the same quality as H264 but at a lower file-size (or better quality for the same size). HEVC is important as 4K is streamed over the air, meaning less bits need to be transferred for the same quality content.
Handbrake is a favored tool for transcoding, and so our test regime takes care of three areas.
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.
High Quality/Resolution H264: A similar test, but this time we take a ten-minute double 4K (3840x4320) file running at 60 Hz and transcode from Main to High, using the very-fast preset.
HEVC Test: Using the same video in HQ, we change the resolution and codec of the original video from 4K60 in H264 into 4Kp30 HEVC. This causes a dramatic reduction in filesize (this is a different test to the Ryzen 7 review).
Facebook
Twitter
RSS
254 Comments
View All Comments
Phiro69 - Tuesday, April 11, 2017 - link
Thank you Ian!Maybe at some point as part of your benchmark description you have a url to a page showing basic (e.g. exactly the level of information you provided above but not step by step hand holding) benchmark setup instructions. I know I wonder if I've configured my builds correctly when I put together new systems; I buy the parts based on benchmarks but I don't ever really validate they perform at that level/I have things set correctly.
qupada - Tuesday, April 11, 2017 - link
I was curious about this too. Obviously a direct comparison between your Windows test and my Linux one is going to be largely meaningless but I felt the need to try anyway. Since Linux is all I have, this is what we get.My Haswell-EP Xeon E5-1660v3 - approximately an i7-5960X with ECC RAM, and that CPU seems to be oft-compared to the 1800X you have put in your results - clocks in at 78:36 to compile Chromium (59.0.3063.4), or 18.31 compiles per day (hoorah for the pile of extra money I spent on it resulting in such a small performance margin). However that's for the entire process, from unpacking the tarball, compiling, then tarring and compressing the compiled result. My machine is running Gentoo, it was 'time emerge -OB chromium' (I didn't feel like doing it manually to get just the compile). Am I reading right you've used the result of timing the 'ninja' compile step only?
I only ask because there definitely could be other factors in play for this one - for the uninitiated reading this comment, Chromium is a fairly massive piece of software, the source tar.xz file for the version I tried is 496MB (decompressing to 2757MB), containing around 28,000 directories and a shade under 210,000 files. At that scale, filesystem cache is definitely going to come into play, I would probably expect a slightly different result for a freshly rebooted machine versus one where the compile was timed immediately after unpacking the source code and it was still in RAM (obviously less of a difference on an SSD, but probably still not none).
It is an interesting test metric though, and again I haven't done this on WIndows, but there is a chunk in the middle of the process that seems to be single-threaded on a Linux compile (probably around 10% of the total wall clock time), so it is actually quite nice that it will benefit from both multi-core and single-core performance and boost clocks.
Also with a heavily multi-threaded process of that sort of duration, probably a great test of how long you get before thermal throttling starts to hurt you. I have to admit I'm cheating a bit by watercooling mine (not overclocked though) so it'll happily run 3.3GHz on a base clock of 3.0 across all eight cores for hours on end at around ~45°C/115°F.
rarson - Tuesday, April 11, 2017 - link
14393.969 was released March 20th, any reason you didn't use that build?Ian Cutress - Friday, April 14, 2017 - link
Because my OS is already locked down for the next 12-18 months of testing.Konobi - Tuesday, April 11, 2017 - link
I don't know what's up with those FPS number in rocket league 1080p. I have ye olde FX-8350 @ 4.8GHz and a GTX 1070 @ 2.1GHz and I get 244fps max and 230FPS average at 1080p Ultra.Ian Cutress - Tuesday, April 11, 2017 - link
I'm running a 4x4 bot match on Aquadome. Automated inputs to mimic gameplay and camera switching / tricks, FRAPS over 4 minutes of a match.jfmonty2 - Wednesday, April 12, 2017 - link
Why Aquadome specifically? It's been criticized for performance issues compared to most of the other maps in the game, although the most recent update has improved that.Ian Cutress - Friday, April 14, 2017 - link
On the basis that it's the most strenuous map to test on. Lowest common denominator and all that.Adam Saint - Tuesday, April 11, 2017 - link
"Looking at the results, it’s hard to notice the effect that 12 threads has on multithreaded CPU tests"Perhaps you mean *not* hard to notice? :)
coder543 - Tuesday, April 11, 2017 - link
I agree. That was also confusing.