x265 HEVC Encoder

[nevcairiel]

Originally Posted by aymanalz

Isn't that the relevant metric? By what percent one is faster than the other?

Its the same metric, just a different way to express it.
Declaring GCC to be the reference at 100%, then this gives you the numbers above for VS2017 - easy enough to read the increases out of.

[pingfr]

Originally Posted by nevcairiel

Its the same metric, just a different way to express it.
Declaring GCC to be the reference at 100%, then this gives you the numbers above for VS2017 - easy enough to read the increases out of.

Regardless a 5.91% speed increase is nothing to be "ashamed of".

[nakTT]

Originally Posted by LigH

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.



With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.

I agree on this. Generally MSVC builds is consistently better. I have been comparing the performance for every new release of x265 and found this to be true.

[LigH]

I decided to keep building with GCC still, I believe that an advantage of <2% is no reason to abandon it, and furthermore, installing Visual Studio seens to be much more elaborate than using an MSYS environment, just for this small task and nothing else...

But I don't mind other people publishing MSVC builds. More choice!

[CruNcher]

Please dont freaking forget the compiler is Windows only GCC has to be Multiplatform that is a different bread to crunch entirely, in balancing and overall performance on every Posix OS and different ARCHs running on them.

[Ma]

The speed comparison of different x265 builds is not so simple.
Let's say that we want compare speed of encoding file "Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m" at preset medium to 8-bit hevc (like in pingfr test, but only for preset medium).

There are many CPUs on the world, so we compare encoding speed with different '--asm' levels (from false [= --no-asm] to AVX).
gcc63s2 means GCC 6.3 build that works on SSE2 CPU (which is 'none' for Win64)
gcc70s3 means GCC 7.0 build for SSSE3 CPUs and better
gcc70s4 means GCC 7.0 build for SSE4.1 CPUs and better
vs2017a1 means VS 2017 build for AVX CPUs and better.
(There are no AVX2 builds -- my CPU is only with AVX.)

Relative encoding speed on Win7 64-bit, i5 3450S, RAM DDR3 1600:

 --asm= | false .|. SSE2 .| SSSE3 .| SSE4.1 | AVX
--------|--------|----------------------------------
gcc63s2 |100.00% |100.00% |100.00% |100.00% |100.00%
gcc70s2	| +4.63% | +4.12% | +4.81% | +0.56% | +0.61%
gcc70s3	| +8.47% | +5.14% | +5.74% | +0.04% | +0.14%
gcc70s4	|+11.57% | +8.06% | +6.90% | +0.16% | -0.42%
vs2017s2|-19.66% |-21.68% |-30.75% | +1.07% | +0.87%
vs2017a1|-18.77% |-20.90% |-29.68% | +2.48% | +2.45%

Some remarks:
1) gcc70s4 build is the fastest with '--no-asm' option but is the slowest with '--asm=avx' option.

2) VS 2017 builds are very slow on CPUs <= SSSE3, the switch is on SSE4.1 level.

3) GCC 7.0 builds are a little bit faster than GCC 6.3 builds.

4) My i5 3450S is surprisingly slower than pingfr's i7 6700 -- 12.34 fps to 23.17 fps.

5) The speed difference from '--asm=sse4' to '--asm=avx' is minimal (12.30 fps to 12.34 fps; full data in attachment).

[Midzuki]

Originally Posted by LigH

I decided to keep building with GCC still, I believe that an advantage of <2% is no reason to abandon it, and furthermore, installing Visual Studio seens to be much more elaborate than using an MSYS environment, just for this small task and nothing else...

But I don't mind other people publishing MSVC builds. More choice!

I second that. Visual Studio is a nightmare, tons of bloat in the registry and needless services. It's okay and a must-have for professional programmers, but I am not a professional programmer, I'm just a not-so-advanced ordinary user.

@Ma:
many thanks for the useful post

That's exactly what I was thinking, but I didn't have any empirical evidence

[pingfr]

Originally Posted by Ma

4) My i5 3450S is surprisingly slower than pingfr's i7 6700 -- 12.34 fps to 23.17 fps.

And why would this be "surprising" at any rates? You're comparing an i7 against an i5 and furthermore a CPU from the 6th generation against one from the 3rd generation which furthermore is an "S" CPU targeted at semi-embedded low-power users?

Unless I missed something here...

Even though, the point I was trying to make a few days ago regarding these tests was that for "some obscure" reasons --preset veryslow was giving us the biggest increase when switching from a GCC build to a VS2017 build compared to a supposedly much faster (but therefore having less optimized settings) preset such as --preset medium and that is where things needed further investigations.

[shinchiro]

@Ma thanks for the detailed test. btw the gcc is built with posix or win32 threads?

[Ma]

Originally Posted by pingfr

And why would this be "surprising" at any rates? You're comparing an i7 against an i5 and furthermore a CPU from the 6th generation against one from the 3rd generation which furthermore is an "S" CPU targeted at semi-embedded low-power users?

There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

@shinchiro: win32 threads

[pingfr]

Originally Posted by Ma

There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

Okay I see.

Also some benchmarks have been somewhat leaked regarding a 3.6GHz upcoming AMD Ryzen with... 16 cores. So you might want to hold your breath a little longer before buying a newer CPU.

[CruNcher]

Originally Posted by Ma

There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

@shinchiro: win32 threads

More impressive it becomes if you look @ it Realtime doing the Decoding instead of the Encoding which is harder to grasp visually

[pingfr]

Originally Posted by CruNcher

More impressive it becomes if you look @ it Realtime doing the Decoding instead of the Encoding which is harder to grasp visually

Me no understanderino you.

[easyfab]

@Ma could you test this build https://www.sendspace.com/file/biunt6

GCC 6.3 but fprofile with my i2600k

[LigH]

@ easyfab:

Look how to avoid an unnecessary full-quote...

[Ma]

Originally Posted by easyfab

@Ma could you test this build https://www.sendspace.com/file/biunt6

GCC 6.3 but fprofile with my i2600k

normal GCC 6.3 = 100%

 --asm=	|SSSE3	|SSE4.1	|AVX
gcc63s2	|100.00%|100.00%|100.00%
gcc70s2	| +5.00%| +0.54%| +0.83%
gcc63pr	|-36.29%| +1.89%| +1.46%
vs2017s2|-30.60%| +0.99%| +0.87%

At SSSE3 level your profiled version is very slow but it is OK -- when you profile the functions that are not executed are compiled for minimize size.

At SSE4.1 level you speed-up +1.89% to normal GCC 6.3 build -- it is better than VS 2017 build (but a bit slower than VS 2017 AVX build). So it is the fastest version that you can execute.

[easyfab]

@Ma Thanks for the report

I will try with GCC 7 to see if it better.

[Boulder]

Does x265 have framerate-aware ratecontrol like x264 does?

http://git.videolan.org/gitweb.cgi?p...f05ad1f861a855

I was just wondering if I should run into material that needs to be encoded at double framerate. Many concerts are encoded as interlaced and I use QTGMC on them to get high quality progressive output at double framerate.

[sneaker_ger]

Yes. (But I don't think you can supply timecodes to the CLI for VFR.)

[Romario]

Is there any news for Ryzen optimizations?

Gesendet von meinem GT-I9295 mit Tapatalk