AMD Ryzen 5 2600X + Ryzen 7 2700X Linux Benchmarks

[Michael_S]

Last I checked, Handbrake couldn't be fully-automated.

HandBrakeCLI? Is there something wrong with that? https://handbrake.fr/docs/en/latest/...i-options.html

[leipero]

Last I checked, Handbrake couldn't be fully-automated.

That's pitty, it would be really interesting to compare results Windows vs. GNU/Linux for that specific test (because Vegas and Handbrake were the only tests where 2600x came ahead of 8700k). And as Michael_S mentioned, there mught be the way using CLI, I don't know, never really tried it tbh.

[Michael]

HandBrakeCLI? Is there something wrong with that? https://handbrake.fr/docs/en/latest/...i-options.html

I looked at it a few weeks ago when working on the rewritten PTS windows support, but didn't end up panning out unless I overlooked something completely.... Will try taking a look again when I am over the flu to see if fresh mind helps things.

[Brisse]

Why is Handbrake interesting when we already have x264? It's just more of the same. Handbrake is relying on libraries such as x264 for encoding.

[nomadewolf]

Did it freeze mid sentence while you were writing ? ^_^

No!
I swear that never happ

[leipero]

Why is Handbrake interesting when we already have x264? It's just more of the same. Handbrake is relying on libraries such as x264 for encoding.

It's interesting because that is one of the 2 tests only where 2600x actually performs faster than 8700k, by testing on 2 different platforms we can see if and where is the actual problem on GNU/Linux platform if it is big difference compared to Windows platform. From that perspective it is very important for GNU/Linux itself, not for one CPU or the other.

For example, if difference is very big in all cross platform tests in favor of Windows (regardless of the CPU, but especially if one architecture is hit far more than the other) we should seek answers in GNU/Linux itself for potential problem, if however the difference is only in specific tests on x264 for example, including handbrake, than we should seek potential problem there (it could be in other software tho...). From that perspective it is very important to have as much cross platform tests as possible, because it is not just curious people who read those articles, but also people involved in contributions to GNU software and Linux kernel itself.

Without (universal = meaning covering as much aspects as possible) cross platform tests we can't say for sure if some numbers are not on pair of what hardware should do or not, or if one platform or another gets benefits/disadvantages to how it could actually work. This methodology would partially help solving that problem IMO.

[k1e0x]

Were the Intel chips tested with the new microcode and spectre/meltdown patches? That seems to be the root of variance on testing out there..

[MaxToTheMax]

These are some of the most consistent results I've ever seen.

[char]

Were the Intel chips tested with the new microcode and spectre/meltdown patches? That seems to be the root of variance on testing out there..

Yep, you're right. Anandtech's Ian Cutress tested with patches (negative impact on Intel's)

[angrypie]

Yep, you're right. Anandtech's Ian Cutress tested with patches (negative impact on Intel's)

Ian is now an AMD shill, at least until Cascade Lake/Coffee Lake-S is released. When 7nm Zen is released he will be an AMD shill again.