Intel's Clear Linux Outpacing Ubuntu 22.04 LTS, Fedora 36 & Other H1'2022 Distros

[kef71]

CachyOS is more-or-less an optimized vanilla Arch distro. They build x86-64-v3 packages, and also host some performance-related modifications.


ALHP.GO is a drop-in x86-64-v3/LTO replacement for the vanilla Arch repos.


I use both, and so far they're great projects.

Thanks, I'll check them out. I'm new to arch.

[SungHwan]

Why didn't you use intel_pstate on arch linux?
does it have a bug or problem on arch linux?

[NotMine999]

Please don't help me. I prefer to deal with something which is tested using proper methodology and the scientific method. Nothing in your reply contains even a modicum of it.

birdie
I see that you have a website...such that it is.

Nothing and nobody is stopping YOU from doing the investigations that YOU are WHINING ABOUT.

So if YOU really want to contribute something to the World of Linux, try doing some actual work yourself instead of looking for cheese in response to your WHINE.

[yoshi314]

The 1001th comparison of distros performance without getting to the root of it and thus making it impossible to understand what could be done for your distro:

• GCC flags? (I guess the most important)
• Kernels' CONFIG_HZ/CONFIG_PREEMPT settings?
• Kernels' debugging options?
• Default schedulers and their options?
• Something else?

What about documenting all of that for the betterment of Linux?

What about running distro_X with the kernel from distro_Y? What if that's enough to make it equally fast?

all the documentation is on clear linux source code. there are too many optimizations to count, maybe LWN could tackle it someday.

[iyanmv]

birdie thanks for reminding me why I don't usually read the comments... Could you be more rude? My god...

[HD7950]

I'm confused. Doesn't arch already compile their packages with -march=x86-64-v3 already? https://gitlab.archlinux.org/archlin...0002-march.rst

NO. That was only an unsuccessful attempt.

[BHZeto]

I love these performance comparisons. I did something similar myself at the beginning of this year, not the same benchmarks, slightly older distros (Fedora 35, Ubuntu 21...) anyway the rankings make sense to me.
I agree with the out-of-the-box sentiment: if I were to do tinkering, for performance or otherwise, I wouldn't be installing Fedora in the first place.

[Danielsan]

Looks like RH has started grabbing Clear Linux aggressive settings... The title is misleading this is clearly a showcase article pro CentOS Stream...

Anyway the point here is Ubuntu... Canonical pays engineers to improve Ubuntu against Debian but ends up having worst performances, I won't never understand it...

[oibaf]

Bug report for apache slowness:

• Debian: bug 1012358
• Ubuntu: bug 1977687

[oibaf]

We got an interesting reply about Ubuntu apache performance from Christian Ehrhardt, an Ubuntu developer:

Hi Oibaf,
we (myself any many other Ubuntu developers I know) have seen the results. And as you said they were interesting but not always entirely clear how they got created.
The majority of the differences I've seen where on things like:
1. Install&run less other services - you could do that just as well on Ubuntu, we just come with a more comfortable default
2. Enable less optional features - they might stall other things
3. Compile things with more processor optimizations
4. Enable speedup features that only work on some platforms/systems
5. Tunables optimized for one, but negative for other workloads
For example tunables - quite often one can tune a system with tremendous results if you happen to know the particular workload. But most of the time such settings would degrade just as many other users as they would help others - or worse.
Many HW features will - if enabled - exclude certain types of hardware entirely. There are many case by case decisions.
We generally do these decisions on every feature, tunable and optimization as they come up. And each time we ask ourselves like "does it bring enough value to a majority of our users". We neither bluntly "enable all we can find" nor "disable all that we can".
Ubuntu is designed to to work out of the box on a wide variety of Hardware and for a wide variety of user groups - hence we can't always use all the same config options used by others.
There is always work ongoing, evaluating features and optimizations (gladly in recent years many optimizations are written in a way to dynamically load and not add overhead otherwise) and tunables.
So you can be reassured that this test as well as feature/performance discussion in general wasn't missed. But this bug isn't about any particular change that one can fix/not-fix - or at least discuss about.
Therefore I'll mark it as "opinion" to reflect that since - as of right now - no one can really act on it.
If you - or anyone else - have individual "how about this feature/optimization/tunable" thought, by all means file a bug about it. There one can have a per case discussion.
But as I mentioned above "just helping a few while degrading others" is unlikely to become the default, that kind will always stay per user config with their workloads in mind.

I agree with him, also adding that the low performance on Debian/Ubuntu looks really strange to me, having some doubt the test was performed properly.
Unfortunately, while I am really interested in these results, I don't' have time to look at it myself.
If someone is willing to devote some time, I think it would be interesting to find out what's happened in the test.
Practically:

• is this performance problem reproducible by others?
• is something related to the test-built apache or the distro provided package apache2 has the same performance problem?
• is there some test related issue?
• anything else that may be responsible of the slowness?