Clear Linux Continues To Maintain Slight Graphics Lead Over Ubuntu 16.10

[Imerion]

How come XFCE gets lower results in some of the tests?

[Linuxhippy]

Does PGO/LTO matter as an intermediate step if in the long-term it is going to converge into some kind of a cool C/C++ JIT compiler?

Are there any indications things are developing this way?
JITs with integrated profiling are great for achieving peak-performance of single applications, for system libraries / services I doubt they are a good idea - separate profiles for each application would mean a lot less code-sharing and latency issues. This is also something which hurts java quite a bit - each java process keeps the compilation results of the same library classes in its private memory space - because the genrated code is dependent on application specific behaviour. Great for performance, not that great for memory consumption. Just imagine each native linux application would copy libc, libstdc++, glib, zlib libxml ... into its private memory space.

If you care about the performance, why do you care about those distros?

Because I prefer a mainstream distribution. However, there is nothing preventing mainstream distributions to invest a bit in performance.
Actually, with RedHat depending bussiness-wise on RHEL, I can't actually see the reason why they are not using PGO/LTO to differentiate themself from all the available clones / other enterprose distributions - On average 10% more performance isn't that uninteresting when you have to pay per CPU/h in the cloud.

Br

[Linuxhippy]

Does PGO/LTO matter as an intermediate step if in the long-term it is going to converge into some kind of a cool C/C++ JIT compiler?

Are there any indications things are developing this way?
JITs with integrated profiling are great for achieving peak-performance of single applications, for system libraries / services I doubt they are a good idea - separate profiles for each application would mean a lot less code-sharing and latency issues. This is also something which hurts java quite a bit - each java process keeps the compilation results of the same library classes in its private memory space - because the genrated code is dependent on application specific behaviour. Great for performance, not that great for memory consumption. Just imagine each native linux application would copy libc, libstdc++, glib, zlib libxml ... into its private memory space.

If you care about the performance, why do you care about those distros?

Because I prefer mainstream distributions. However, there is nothing preventing mainstream distributions to invest a bit in performance.
Actually, with RedHat depending bussiness-wise on RHEL, I can't actually see the reason why they are not using PGO/LTO to differentiate themself from all the available clones / other enterprose distributions - On average 10% more performance isn't that uninteresting when you have to pay per CPU/h in the cloud.

Br

[edwaleni]

What's up with the Caffe result? Is Clear Linux using the GPU?

I noticed that too. I know Intel has been trying to expose more functionality in their instruction set to improve its use in analytics, but I didn't think it was that efficient compared to bone stock Ubuntu. I am assuming that it is taking some of those parallel tasks and running them across the GMA 530. Caffe requires a flag be set to run across a GPU. Perhaps the flag is set to "on" in PTS, and Clear Linux exposes the GMA GPU correctly whereas Ubuntu doesn't.

[damg]

I noticed that too. I know Intel has been trying to expose more functionality in their instruction set to improve its use in analytics, but I didn't think it was that efficient compared to bone stock Ubuntu. I am assuming that it is taking some of those parallel tasks and running them across the GMA 530. Caffe requires a flag be set to run across a GPU. Perhaps the flag is set to "on" in PTS, and Clear Linux exposes the GMA GPU correctly whereas Ubuntu doesn't.

From the compiler flags, it seems they are using different BLAS library implementations. OpenBLAS appears to be much faster than CBLAS in this case.

[edwaleni]

From the compiler flags, it seems they are using different BLAS library implementations. OpenBLAS appears to be much faster than CBLAS in this case.

Good catch. OpenBLAS is supposed to match or exceed Intel MKL performance in SIMD based ops. If Intel is using that lib, that says something for OpenBLAS. Of course while Intel MKL is free, it is not open source.