AlmaLinux 9, openSUSE Leap 15.4, Ubuntu 22.04, Debian 11.3 & Clear Linux Benchmarks

[Volta]

Linux is still awful in 2022 in many aspects such as page trashing in near OOM conditions or cpu scheduler latency for decent desktop experience, and subpar cpu freq scaling governors are being one of them.

You forgot to mention windows and macos are even more awful in this.

[Volta]

Forgot to toss it in the run queue.

Thanks for the benchmarks, but when can we expect Alder Lake tests?

[coder]

I think the high performance of Alma Linux is highly due to its defaulting to `x86_64-v2`.

Given Alma's stated goal of 1:1 binary compatibility with RHEL, can we treat it as a good proxy for RHEL performance?

[coder]

I'm 99% sure its due to the CPU scaling governor being set to "performance" on Alma.

The benchmarks overall are unfair, all distros should have been set their cpu freq scaling governors to "performance".

I agree with skeevy420 that it's better to test the default installation of these distros, as that's what most users will run.

I think a better way to account for the CPU scaling governor issue is to:

1. Specify what each distro is using, at the top of the article. It's a detail on the same level as which gcc, glibc, and kernel version they're using.
2. Perform a separate benchmark to see how much deficit can be recovered by simply changing it, if one of the lower-performing distros is using a lower-performing setting.

[skeevy420]

I agree with skeevy420 that it's better to test the default installation of these distros, as that's what most users will run.

I think a better way to account for the CPU scaling governor issue is to:

1. Specify what each distro is using, at the top of the article. It's a detail on the same level as which gcc, glibc, and kernel version they're using.
2. Perform a separate benchmark to see how much deficit can be recovered by simply changing it, if one of the lower-performing distros is using a lower-performing setting.

What I'd suggest would be to single out the best and worst distributions, test them again with different governors, and then compare them with their previous results. With these results it would be testing Clear with Powersave and SUSE with Performance.

[onlyLinuxLuvUBack]

Forgot to toss it in the run queue.

Michael,

maybe article part2, could you do clear linux running distrobox running the same ubuntu version to see what the performance impact is ?

[Charlie68]

openSUSE might be the slowest in the group, but I will take it every day of the week. The reliability of it has been fantastic for me, but the ease of configuration with yast is a winner as well.

Keep in mind that the benchmarks give an indicative value, which in daily use of the PC could be null.
I have a dual boot Leap - Tumbleweed and I don't see any difference, but I'm sure there are.
I have also tried other distributions and I have never perceived big differences, perhaps they are more evident with some games or with high workloads, something that with the daily use of a PC for office and multimedia use is not so evident.

[coder]

Keep in mind that the benchmarks give an indicative value, which in daily use of the PC could be null.
I have a dual boot Leap - Tumbleweed and I don't see any difference, but I'm sure there are.
I have also tried other distributions and I have never perceived big differences, perhaps they are more evident with some games or with high workloads, something that with the daily use of a PC for office and multimedia use is not so evident.

That's exactly right. For realtime or performance-critical work, these differences might matter a lot. Maybe if you're spending a lot of time waiting for builds to complete, you might also have an interest in minimizing that. But, in most of my day-to-day usage, I just need "fast enough".

[arQon]

Don't kill the messenger.

I think it's generally phrased as "Don't shoot the messenger".

The SVT numbers are interesting. Regardless of compile-time feature set, you'd expect the actual work to be done in runtime-chosen appropriate ASM, i.e. SSE4/SSSE3 or AVX, and that appears to not be the case.
The small deltas for most of the rest of the tests are likely a mixture of governor and/or trivial improvements from featureset, but not really large enough to be worth caring about.

[arQon]

Maybe if you're spending a lot of time waiting for builds to complete, you might also have an interest in minimizing that.

I once worked at a place where the "Build Engineer" who'd set things up was an absolute clown, so if you were building for one of the actual platforms it took over 2 hours. (He didn't know how to use configure (not "set up", just "use"!) to change build dirs, so he just wiped everything for each make and did full rebuilds every time).

When I suggested this might be a factor in why they were a year behind schedule and informed them I would be fixing it, one of the developers objected quite strenuously, because they'd all been using it as an excuse to screw around on the web etc... :P