Quote:
Originally Posted by Ma
At the beginning of GCC 6 release if you compile x265 without -march=pentium4 the resulting exe was not working. Now it is special workaround in cmake that adds -mpreferred-stack-boundary=2 if it detect GCC 6 and 32-bit mode. Now it is not necessary to specify -march=pentium4.
You can consider difference in speed. I've made test of encoding with command line:
x265_32 -D10 -f130 ../ducks_take_off_1080p50.y4m w.hevc
The result was:
LigH 2.3+17 version with -march=pentium4 -mtune generic
encoded 130 frames in 100.31s (1.30 fps), 8566.20 kb/s, Avg QP:38.35
Barough 2.3+23 version
encoded 130 frames in 133.73s (0.97 fps), 8562.60 kb/s, Avg QP:38.35
2.3+23 version GCC 7.0 SSE4.1
encoded 130 frames in 84.20s (1.54 fps), 8566.20 kb/s, Avg QP:38.35
2.3+23 version GCC 7.0 SSSE3
encoded 130 frames in 92.38s (1.41 fps), 8566.20 kb/s, Avg QP:38.35
If you do not specify -march=pentium4 -mtune=generic for 32-bit x265, the encoding time in 10-bit mode will be longer about 33%. Computers with Pentium 3 are very slow and with tiny memory so anyway there are not for x265 encoding.
|
So which build toolchain would you recommend to use on modern architectures? (and by modern I mean anything newer than Ivy Bridge, Sandy Bridge, Haswell, Skylake, Kaby Lake even) running a modern OS consumer oriented such as Windows 7, 8 or Windows 10.