Initial Benchmarks Of Endeavour OS - The New Linux Distro Based On Arch

[phoronix]

Phoronix: Initial Benchmarks Of Endeavour OS - The New Linux Distro Based On Arch

Following the Antergos Linux distribution being discontinued one of the new projects stemming from that decision is Endeavour OS as a new convenient to use Arch Linux distribution. Here are some early benchmarks of Endeavour OS compared to Ubuntu, Clear Linux, and other distributions on an Intel Core i9 system.

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

[AndyChow]

I wonder why x265 is so slow with openSUSE, when it seems it should be rather the same on all OSes. Clear linux probably uses AVX2, so I get why it would be faster.

[M@GOid]

Well, finished behind Ubuntu 18.04 LTS on the geometric mean graph. Looks like having up-to-date packages is not the secret for the highest performance after all.

[sarfarazahmad]

Well, finished behind Ubuntu 18.04 LTS on the geometric mean graph. Looks like having up-to-date packages is not the secret for the highest performance after all.

Another testament to that is LTO tumbleweed benchmark, Michael did a couple of days back. Debian appears quite performant. Those guys are definitely getting a lot of things right.
It just amazes me how much of a big win/free ride Debian is for commercial organizations not willing to go the RHEL route. They get performant software with relatively timely security updates for, well, free.

[GrayShade]

Well, finished behind Ubuntu 18.04 LTS on the geometric mean graph. Looks like having up-to-date packages is not the secret for the highest performance after all.

There was a theory that Arch is slower because it ships a `CONFIG_NO_HZ_FULL` kernel:

Omit scheduling-clock ticks on CPUs that are either idle or that have only one runnable task (CONFIG_NO_HZ_FULL=y). Unless you are running realtime applications or certain types of HPC workloads, you will normally -not- want this option.

I don't know if that's true, but I can see the kernel compilation options making a difference in the performance of a distro.

[Dedale]

Interesting tests and interesting comments. That said, i guess that kind of distro is not chosen first for their performance. Arch does not perform horribly on average and it is all the target audience needs to know.

[bug77]

Another testament to that is LTO tumbleweed benchmark, Michael did a couple of days back. Debian appears quite performant. Those guys are definitely getting a lot of things right.
It just amazes me how much of a big win/free ride Debian is for commercial organizations not willing to go the RHEL route. They get performant software with relatively timely security updates for, well, free.

It's easy to do that when other distros act as guinea pigs on your behalf. If everyone would eschew this role the whole ecosystem would probably die within a decade.

In other news, kudos to Michael for testing a distro, but not including its upstream, that gives us a clearer image. Do that again

[StefanBruens]

I wonder why x265 is so slow with openSUSE, when it seems it should be rather the same on all OSes. Clear linux probably uses AVX2, so I get why it would be faster.

The problem is, nobody can tell. The test is not reprocible with the given information:
1. The PTS compiles its own local version of x265 (v 3.0, current is 3.1.1)
2. There is no configure/cmake log available
3. The PTS thinks it needs yasm, while x265/cmake checks for nasm (optional dependency)
4. x265 can use libnuma, but again this is an optional dependency

I have run the encoding in three variants, once with the "download 3.0; cmake; make" approach, once compiled locally with nasm and libnuma-devel installed, and once by just installing the x265 (3.1.1) package from Packman:

• x265 [info]: HEVC encoder version 3.0
  x265 [info]: build info [Linux][GCC 9.1.1][64 bit][noasm] 8bit
  x265 [info]: using cpu capabilities: none!
  encoded 600 frames in 124.22s (4.83 fps), 1393.58 kb/s, Avg QP:33.55
• x265 [info]: HEVC encoder version 3.0
  x265 [info]: build info [Linux][GCC 9.1.1][64 bit] 8bit
  x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
  encoded 600 frames in 29.60s (20.27 fps), 1393.58 kb/s, Avg QP:33.55
• x265 [info]: HEVC encoder version 3.1.1+1-04b37fdfd2dc
  x265 [info]: build info [Linux][GCC 9.1.1][64 bit] 8bit+10bit+12bit
  x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
  encoded 600 frames in 22.04s (27.22 fps), 1273.22 kb/s, Avg QP:33.68

Tests were run on a Haswell Quadcore, i.e. with AVX2 support.

So, depending on what packages you already have installed you may get quite different results. Building/running x265 without nasm/libnuma will work, but it will be awfully slow.

Also, e.g. LTO is not part of the GCC default flags, for openSUSE/SLE these are set in the build service, but not in a plain GCC invocation. The up-to-date build chain is not leveraged.

[starshipeleven]

It just amazes me how much of a big win/free ride Debian is for commercial organizations not willing to go the RHEL route. They get performant software with relatively timely security updates for, well, free.

Canonical: I know right?

[tuxd3v]

Canonical: I know right?

In Fact Canonical have a very good operating system for servers, its a good option..