Which processor to encode x265 4K ?

[excellentswordfight]

Originally Posted by benwaggoner

I'm not sure. Perhaps because avx512 needs to be explicitly turned on?

I've got my dual Xeon 6140 workstation coming next week (basically a physical EC2 c5.16xlarge), and I can do some benchmarks when it arrives.

And I've got some 8K test sources too, so I can benchmark those with/without. I would expect that the value may go up with resolution, as avx512 is only supposed to become useful at 2160p.

I’ve done some tests at 2160p with a few skylake-sp platforms. Even at 2160p i had a hard time getting the same utilization as without avx512, and even without that it’s hard to see any big gains cause of the ~500Mhz clockspeed penalty.

[RanmaCanada]

Originally Posted by Atak_Snajpera

Oh boy! You and your questions...
Dude! Those results come from my benchmark
http://forum.pclab.pl/topic/1184884-x265-FHD-Benchmark/

It's obvious some people don't do their "research" before they post

I did something similar to The Stilt, when he was wrong and just called him a random haha.

Thanks for posting everything in one place! It will make things far more easier to compare once we get some runs from Ryzen 2!

[nevcairiel]

Originally Posted by RanmaCanada

some runs from Ryzen 2!

Since we're liking to be accurate:

Its either Zen 2, or Ryzen 3000. Ryzen 2 is misleading, and not a term used by AMD, since Ryzen 3/5/7/9 are model-classes in their lineup, so it could easily be mistaken for a lower-end model - and next generation there would be even more real confusion.

[Asilurr]

Originally Posted by Atak_Snajpera

Dude! Those results come from my benchmark
http://forum.pclab.pl/topic/1184884-x265-FHD-Benchmark/

The link you've provided redirects to Mediafire, where one can download the presumably latest version (?) of the benchmark. Id est the package uploaded on July 26th, 2018. Inside the package, one can find:
1. An old version of x265 [2.2+15-a18ab7656c30].
2. An old version of FFmpeg [N-82889-g54931fd].
3. The five test sources, which are all 8-bit, all 4:2:0, all 16:9 1080p.

As for the benchmark itself:
1. As one can't test a given CPU in vacuo, one actually tests an ensemble of CPU+MB+RAM+IO. Rephrasing: one adds degrees of freedom to the system, together those serve the purpose of propagating the uncertainty.
2. As one doesn't test x265 on its own, due to the way the benchmark is designed, one actually tests the pair of FFmpeg+x265. Another degree of freedom, another potential path for the propagation of uncertainty.
3. As the benchmark uses an old version of x265, all the results which are obtained are actually "watermarked" by the common reference frame of a 2.2 x265 encoder. One can't extrapolate the results to a 3.1 x265 encoder, and assume them to hold true by default.
4. As the benchmark tests the default configuration of parameters for x265 (i.e. --preset medium), all the results which are obtained are actually "watermarked" by the common reference frame of that particular preset. One can't extrapolate the results to another preset (or another parameter configuration), and assume them to hold true by default.
5. The benchmark doesn't test a single low complexity source, or a single 10-bit source, or a single non-4:2:0 source, or a single non-FHD source. All the results are again "watermarked" by a highly specific encoding scenario. One can't extrapolate them to another encoding scenario, and assume them to hold true by default.

Do you understand what is the actual result of the benchmark you are providing? It enables one to say: I am encoding this particular source of this particular complexity (at this particular resolution, this particular bit depth, this particular chroma subsampling), within this particular software environment (OS, x265, FFmpeg), on this particular machine (CPU, MB, RAM, IO). It certainly does not enable one to say: CPU MMM achieves an average of abc% better FPS than CPU NNN, across all possible/conceivable encoding scenarios.

At this point, I'd simply reiterate my initial statement: I would advise a healthy dose of skepticism whenever you see results without extensive coverage of the testing methodology.

[Atak_Snajpera]

Originally Posted by Asilurr

The link you've provided redirects to Mediafire, where one can download the presumably latest version (?) of the benchmark. Id est the package uploaded on July 26th, 2018. Inside the package, one can find:
1. An old version of x265 [2.2+15-a18ab7656c30].
2. An old version of FFmpeg [N-82889-g54931fd].
3. The five test sources, which are all 8-bit, all 4:2:0, all 16:9 1080p.

As for the benchmark itself:
1. As one can't test a given CPU in vacuo, one actually tests an ensemble of CPU+MB+RAM+IO. Rephrasing: one adds degrees of freedom to the system, together those serve the purpose of propagating the uncertainty.
2. As one doesn't test x265 on its own, due to the way the benchmark is designed, one actually tests the pair of FFmpeg+x265. Another degree of freedom, another potential path for the propagation of uncertainty.
3. As the benchmark uses an old version of x265, all the results which are obtained are actually "watermarked" by the common reference frame of a 2.2 x265 encoder. One can't extrapolate the results to a 3.1 x265 encoder, and assume them to hold true by default.
4. As the benchmark tests the default configuration of parameters for x265 (i.e. --preset medium), all the results which are obtained are actually "watermarked" by the common reference frame of that particular preset. One can't extrapolate the results to another preset (or another parameter configuration), and assume them to hold true by default.
5. The benchmark doesn't test a single low complexity source, or a single 10-bit source, or a single non-4:2:0 source, or a single non-FHD source. All the results are again "watermarked" by a highly specific encoding scenario. One can't extrapolate them to another encoding scenario, and assume them to hold true by default.

Do you understand what is the actual result of the benchmark you are providing? It enables one to say: I am encoding this particular source of this particular complexity (at this particular resolution, this particular bit depth, this particular chroma subsampling), within this particular software environment (OS, x265, FFmpeg), on this particular machine (CPU, MB, RAM, IO). It certainly does not enable one to say: CPU MMM achieves an average of abc% better FPS than CPU NNN, across all possible/conceivable encoding scenarios.

At this point, I'd simply reiterate my initial statement: I would advise a healthy dose of skepticism whenever you see results without extensive coverage of the testing methodology.

Are you trying to convince me that AMD's AVX128 in Zen1 is able to compete with full fat Intel's AVX256. x256 is highly optimized for AVX2 and that's why ZEN1 sucks in this encoder. Period! Luckily Zen2 finally has AVX256 so I'm expecting 3600 to have similar performance as stock 8700k.

BTW. Your requirements for "proper" benchmark are just insane and totally unrealistic! I advise you to stop using any software because there are countless variables affecting performance of your machine (including phases of the moon).

[Asilurr]

You're being deliberately obtuse, I suppose I can attempt a simplistic analogy by referring to a system with only two degrees of freedom.

I want to investigate what happens to water when I heat it up. To be rigorous, that's the so-called "pure water" which is known today as UPW. At a pressure of 1 atm, I observe that water is gaseous at 400 K. Conducting a second experiment, I observe that water is gaseous at 500 K too. At this point I ask myself: can I consider the previous results a good predictor of what would happen to water when it's heated to 600 K instead? Can I simply assume that it would be gaseous, thus not having to actually perform a test? The answer to that is no, a proper phase diagram shows what happens to water heated at 600 K and highlights the critical importance of the other parameter of this simplistic system.

To return to the discussion of benchmarking encoding times, we're now looking at a system with dozens of degrees of freedom: the parametric space of the hardware, the parametric space of the software, the parametric space of the source to be encoded, the parametric space of the encoding process itself. This entire thread was initiated by explicitly mentioning UHD/4K encoding scenarios. It's right in front of your eyes, mentioned both in the title and the leading post. To which you've replied (here) by implicitly assuming that the results of FHD benchmarking scenarios (highly specific FHD encoding scenarios, as already pointed out) will simply hold true even if one particular parameter varies drastically, claiming that increasing the resolution four times doesn't alter the expected result. To which I replied that an implicit assumption is not sound, as there is an explicit need of additional testing to account for the variable parameter(s).

[NikosD]

Originally Posted by Asilurr

To return to the discussion of benchmarking encoding times, we're now looking at a system with dozens of degrees of freedom: the parametric space of the hardware, the parametric space of the software, the parametric space of the source to be encoded, the parametric space of the encoding process itself. This entire thread was initiated by explicitly mentioning UHD/4K encoding scenarios. It's right in front of your eyes, mentioned both in the title and the leading post. To which you've replied (here) by implicitly assuming that the results of FHD benchmarking scenarios (highly specific FHD encoding scenarios, as already pointed out) will simply hold true even if one particular parameter varies drastically, claiming that increasing the resolution four times doesn't alter the expected result. To which I replied that an implicit assumption is not sound, as there is an explicit need of additional testing to account for the variable parameter(s).

Hello.
Could you propose an existent benchmark, covering your needs of proper x265 encoding benchmarking procedure for multithreaded CPUs ?

Or do you have a suggestion how to build one ?

[Atak_Snajpera]

Originally Posted by Asilurr

You're being deliberately obtuse, I suppose I can attempt a simplistic analogy by referring to a system with only two degrees of freedom.

I want to investigate what happens to water when I heat it up. To be rigorous, that's the so-called "pure water" which is known today as UPW. At a pressure of 1 atm, I observe that water is gaseous at 400 K. Conducting a second experiment, I observe that water is gaseous at 500 K too. At this point I ask myself: can I consider the previous results a good predictor of what would happen to water when it's heated to 600 K instead? Can I simply assume that it would be gaseous, thus not having to actually perform a test? The answer to that is no, a proper phase diagram shows what happens to water heated at 600 K and highlights the critical importance of the other parameter of this simplistic system.

To return to the discussion of benchmarking encoding times, we're now looking at a system with dozens of degrees of freedom: the parametric space of the hardware, the parametric space of the software, the parametric space of the source to be encoded, the parametric space of the encoding process itself. This entire thread was initiated by explicitly mentioning UHD/4K encoding scenarios. It's right in front of your eyes, mentioned both in the title and the leading post. To which you've replied (here) by implicitly assuming that the results of FHD benchmarking scenarios (highly specific FHD encoding scenarios, as already pointed out) will simply hold true even if one particular parameter varies drastically, claiming that increasing the resolution four times doesn't alter the expected result. To which I replied that an implicit assumption is not sound, as there is an explicit need of additional testing to account for the variable parameter(s).

Yes! You can easily extrapolate results from 1920x1080 to 3840x2160. Encoding speed will drop 4 times. 4x more pixels to examine means 4 times more cpu cycles has to be used. End of story. I'm done with you!

[RanmaCanada]

Originally Posted by nevcairiel

Since we're liking to be accurate:

Its either Zen 2, or Ryzen 3000. Ryzen 2 is misleading, and not a term used by AMD, since Ryzen 3/5/7/9 are model-classes in their lineup, so it could easily be mistaken for a lower-end model - and next generation there would be even more real confusion.

Ya got me there! and thank you.

Now hopefully someone will leak out something other than stupid geekbench results. I seriously want to see how well this generation will do in encoding. I don't care about games..I want encoding benchmarks.

Sadly, I think we are going to have to wait till one of the forum members gets one as we know review sites don't exactly know how to benchmark when it's not games.

[benwaggoner]

Originally Posted by Atak_Snajpera

Yes! You can easily extrapolate results from 1920x1080 to 3840x2160. Encoding speed will drop 4 times. 4x more pixels to examine means 4 times more cpu cycles has to be used. End of story.

Not entirely. CABAC can take up a decent chunk of CPU, and since bitrate isn't linear to pixel count, in the real world you get less than a 4x increase for 4x the pixels. Plus the more pixels there are, the less each one matters so some different encoding technique.

Changing resolution can also really impact threading; more pixels mean fewer frame threads are needed on smaller core counts, reducing overhead.

And of course, how well does encoding scale across multiple cores? Across the same or different NUMA nodes?

[mandarinka]

https://www.ptt.cc/bbs/PC_Shopping/M...742.A.61C.html

This has a (unconfirmed) results for x265 benchmark used on HWBot. I think it has an older binary so gains from AVX256 might be a bit subdued, but the same would be true for the Intel chip.

The benchmark tests and reports max single thread turbo clock at initialization so I think the screenshot means that these are scores for stock Ryzen 5 3600 and Core i7-8700K.

Basically looks nice for Ryzen 3000 and I would wait for it and not get anything else, if this is confirmed.

[Asmodian]

Very nice results, I hope they are true! It is looking like they probably are, with more leaks from other areas.

[Forteen88]

Originally Posted by mandarinka

https://www.ptt.cc/bbs/PC_Shopping/M...742.A.61C.html

Unfortunately, they don't give information about the speed of the RAM used.

[mandarinka]

https://imgur.com/a/YkoOCgM

Check that Handbrake result Pretty nice if correct.

[Nico8583]

Interesting
What is the difference between i9 9900K 95W and i9 9900K ? 95W is the stock TDP and both are 3,6Ghz. Perhaps the second is O/C ?

[sneaker_ger]

3.6 GHz is only the advertised base clock. The i9-9900K goes up to 5 GHz dynamically. If it's not limited to the default "95W" setting it can keep turbo clocks longer.

https://www.anandtech.com/show/13591...-power-for-sff

[benwaggoner]

Originally Posted by Asmodian

Very nice results, I hope they are true! It is looking like they probably are, with more leaks from other areas.

It's be helpful if they documented what parameters were actually being tested. "1080p" is obviously not a x265 --preset.

[hajj_3]

Originally Posted by benwaggoner

It's be helpful if they documented what parameters were actually being tested. "1080p" is obviously not a x265 --preset.

Zen2 chips and the reviews are out tomorrow so not long until we have some good x265 and x264 benchmarks for zen2 to compare with latest intel chips.

[hajj_3]

x265 and x264 benchmarks of the new Ryzen 3000 series chips:









handbrake v1.2.2:





staxrip x264 and x265 benchmarks: https://nl.hardware.info/reviews/939...4-x265-en-flac

[birdie]

The most relevant graph for encoding/rendering: