Clear Linux Offering Performance Advantages Even With Low-Power IoT/Edge Hardware

[phoronix]

Phoronix: Clear Linux Offering Performance Advantages Even With Low-Power IoT/Edge Hardware

While we are often testing Intel's Clear Linux on high-end desktop and server hardware, it turns out even on the opposite end of the spectrum that their performance-optimized distribution can offer meaningful performance advantages on low-end SoCs for IoT-type devices. When testing Clear Linux with an Apollolake platform, it came out to being about 20% faster than the likes of Fedora and Ubuntu Linux.

http://www.phoronix.com/vr.php?view=28203

[willmore]

That LAME result seems very strange. Most of LAME on x86 is already hand coded ASM. Short of the other two distros disabling it, I'm shocked that there's that much improvement to be had. Unless they're using unsafe compiler settings that are leaving out important chunks of code. Which vendors have done in the past for a number of SPEC codes.

[AndyChow]

That LAME result seems very strange. Most of LAME on x86 is already hand coded ASM. Short of the other two distros disabling it, I'm shocked that there's that much improvement to be had. Unless they're using unsafe compiler settings that are leaving out important chunks of code. Which vendors have done in the past for a number of SPEC codes.

It's consistent with the benchmarks that ran the last few years. Clear linux was always 3.5-4x faster at LAME wav to mp3 than other distros.

It's hard to see the compiler settings, but they are in the image:

-O3 -pipe -fexceptions -fstack-protector -m64 -ffat-lto-objects -fno-signed-zeros -fno-trapping-math -fassociative-math -mtune=skylake -lncurses

Now why this is so, I don't know.

[S.Pam]

Is the resulting MP3 identical on Clear as the others? If so it seems very impressive.

[ferry]

I am not that surprised. I would expect on Goldmont (Atom) there are more opportunities for compile time improvement then on Core.

[paulcarroty]

I've used this distro couple for weeks and can share my experience.

pros:
- very fast, it feels like after upgrade to fresh i7.
- active community: you'll get help on their forum from CL Team
- compiler/most devtools already patched


cons:
- small number of available packages. Chromium? VS Code? VirtualBox? Go install/compile them yourself.
- no ffmpeg/gstreamer/proprietary codecs and no way to install them easily
- all workflow is highly patched/customised. RPM, but not fully compatible with Fedora/SUSE, some macros doesn't works.
- stateless, many apps configured to use /usr/share/etc instead /etc.

Conclusion: not ready yet, good only if you're fan of coding/compilation/patching or doesn't use nothing except browser and text editor.

[ms178]

I hope we will get to see a shootout between Ryzen 3000 and Intel on Clear Linux before the new Threadripper comes out. The RDRAND issues should be gone by now which were holding back that testing earlier... I'd love to see if we see even more profound performance from the new Ryzen due to their better AVX2 support with that generation. It seems Clear Linux could leverage it better than other distros.

[sunnyflunk]

That LAME result seems very strange. Most of LAME on x86 is already hand coded ASM. Short of the other two distros disabling it, I'm shocked that there's that much improvement to be had. Unless they're using unsafe compiler settings that are leaving out important chunks of code. Which vendors have done in the past for a number of SPEC codes.

I believe it's building lame without optimizations on other platforms due to not exporting CFLAGS to the environment (and it not having some -O1/2 default). CL does export CFLAGS to the environment and those are used in the build.

A quick test with different CFLAGS:
-O0 29.5s
-O1 10.9s
-O2 10.4s
-O3 9.8s
CL FLAGS 9.6s

This has no bearing on the performance of what each distribution ships with as many PTS tests don't even use the distribution packages. So you're essentially comparing a -O0 build of lame on other distros (which isn't what they ship) with a CFLAG heavy build on CL (which then significant impact on the geometric mean of tests difference).

It's very difficult to determine performance of distro's using the PTS as you have to understand every test to draw any conclusion. This goes both ways and often understates the performance of CL. For example, the flac test likely compiles a '-O2 -march=native' optimized build of flac for other distros. In CL that is similar to the distro build with AVX2/AVX512 optimized builds included. However, the performance of Ubuntu and others would be overstated with the distro package performing worse.

[coder]

I hope we will get to see a shootout between Ryzen 3000 and Intel on Clear Linux before the new Threadripper comes out. The RDRAND issues should be gone by now which were holding back that testing earlier... I'd love to see if we see even more profound performance from the new Ryzen due to their better AVX2 support with that generation. It seems Clear Linux could leverage it better than other distros.

Better apply this, first. Intel is still cheating.

https://github.com/tpn/agner/blob/master/asmlib/inteldispatchpatch/dispatchpatch.txt

[coder]

I hope we will get to see a shootout between Ryzen 3000 and Intel on Clear Linux before the new Threadripper comes out. The RDRAND issues should be gone by now which were holding back that testing earlier... I'd love to see if we see even more profound performance from the new Ryzen due to their better AVX2 support with that generation. It seems Clear Linux could leverage it better than other distros.

Ugh. My first reply is awaiting moderation, but anyway consider:

The MKL (Math Kernel Library) has both a discriminating and a non-discriminating CPU dispatcher (__intel_mkl_features_init and __intel_mkl_features_init_x, respectively).

The "discriminating" one will only run optimized code on Genuine Intel CPUs. This needs to be patched, for AMD hardware to have a fair shot on Clear Linux. Or to run MKL on it, anywhere.

Source: https://www.agner.org/optimize/blog/read.php?i=979&v=t