Ubuntu 18.10 Performance Is Looking Up, But Clear Linux Still Leads In Many Tests

[pldelisle26]

I would like to know too ! I have 2x RTX 2080 waiting to try Clear Linux.

I posted an issue on GitHub : https://github.com/clearlinux/distribution/issues/324

[skeetre]

Can anyone tell me how to get the NVIDIA driver installed on Clear Linux? I downloaded it to see how much of a difference it makes on my own system vs Mint 19. It says it can't find "make" to compile the dang thing. I can't figure out which clear software bundle is supposed to have make in it. I would think the developer bundle, but it says I already have that installed. Trying to get it to work with an RTX 2080.

Also... as some of you have pointed out, I've ran my own system against some of the latest ones posted like 1810044-SKEE-180801978: Various high-end desktop CPU benchmarks using Ubuntu 18.04 with upgrade to the Linux 4.18 kernel... Some random tests for a future article on Phoronix.com.
Some my system is WAY under performing while others it is way over performing.

[Grinch]

Could ClearLinux be using QSV (Quick Sync) for the tanscodes? If so, is QSV asic enough to give a 6x increase?

No, x265 does not make use of QSV, it also does not make use of external libraries which some have assumed could be the culprit. There is clearly something wrong with the way these binaries were configured and built on the Ubuntu systems.

[DanglingPointer]

Could ClearLinux be using QSV (Quick Sync) for the tanscodes? If so, is QSV asic enough to give a 6x increase?

[Spooktra]

There's definitely something wrong with the x265 results, I have a Ryzen 1600 with 8GB of DDR4 and 32 GB of swap on a spinning rust WD; I installed the latest PTS and ran the x265 test, with Firefox open and numerous tabs running, using nearly 6GB of ram. This system, in this test state, achieved encoding frame rates of 6.11, 5.88 and 6.02; this is on Ubuntu 18.04.1 LTS. Compare that against 6.73 for a 5960X, 10.94 for a 7980XE, 13.19 for a 2950X and 11.87 for a 2990WX.

Michael, are you really going to stand behind the results your software produces when the results show practically no scaling with frequency, IPC or core count? A 6C/12T system being used to the point where most of the available ram is used up manages to achieve results identical to an 8C/16T processor, close to an 18C/36T processor, and 50-60% of processors with 16C/32T to 32C/64T monster cpu's,

BTW, what is up with PTS, why does it download Bosphorous to /proc/some-randonly-numbered-folder and why can it not be copied or moved out of that folder? I wanted to try and encode it using a different program like Handbrake or ffmpeg to see what encoding speed that would result in.

Anyway, PTS needs fixing.

[Royi]

Why do you need to rebuild stuff on each system?
What should be done, in my opinion, is using the exact same binary on each in order to measure the OS itself.

As clearly all those tests mainly measure compiler configuration and not the OS itself.

Regarding x264, it might be the Math Library of Clear Linux which might be much faster?
Does x264 use FFTW for DCT? If not and it is done utilizing the system math library that could be it.

[Michael]

First of all, thanks for the x265 benchmarks, those are the most interesting encoding benchmarks to me at this point in time and second of all, what the hell is up with the x265 benchmarks? It's almost as if the x265 version tested on Ubuntu was built with a no-asm switch. A 6x faster encoding speed on one OS vs another should immediately tell you something is very wrong, I don't care what kind of "optimization" Clear Linux developers are doing, you're not going to speed up the execution of a program 6 fold just by switching to a different distro.

As is standard with PTS, all the same compiler flags are used each time, etc. And for each time the CPU/system changes, PTS automatically rebuilds the test so it's not like just one build happened to be super fast but was reproduced on each box.

[Grinch]

How is the x265/lame thing even possible? Especially x265 which is supposed to use mostly hand-tuned assembly.

I call shenanigans on both the x265 and LAME tests, Michael clearly must have botched the C/CXX flags for the Ubuntu tests. This is the reason why I find the Go tests to be the ones I can trust, since they use the same compiler with the same optimizations enabled across all systems, thus the result is actually that of 'system performance', not the (seemingly haphazard) C/CXXFLAGS Michael is passing to GCC / Clang when building the binaries to benchmark.

Like someone else stated, the x265 results for Ubuntu looked like assembly optimizations had been turned off, we're talking ~80% performance difference here, something is REALLY wrong with the way the Ubuntu builds were configured.

[zaphod_]

Oh brother, 18.10 looks terrible for data science. What's the deal on the R and scikit-learn benches??

These two order-of-magnitude regressions smack any small percentage improvements elsewhere into oblivion.

There has to be some BLAS library shenanigans going on.

yes, there must be something really strange happening with blas. Maybe openblas is used for ubuntu 18.04 and default fallback blas without avx/sse is used for 18.10.

However, these data science benchmarks are not really that meaningfull since you are just measuring blas, which can be changed easily by installing openblas or atlas and changing the dynamically linked blas.so with update-alternatives. Moreover, you can install the intel mkl really easy see Dirk Eddelbuettels tutorial https://github.com/eddelbuettel/mkl4deb

For example my [email protected] Ghz at work with ubuntu 18.04 and intel mkl gets 0.2388 in the R Benchmark and is thereby 27% faster than the i7 8086K using default ubuntu 18.04.

[carewolf]

How is the x265/lame thing even possible? Especially x265 which is supposed to use mostly hand-tuned assembly.

If it is testing the native x265 libraries, they can be completely different versions, or they could have different encoding defaults.