OpenSUSE's Spectre Mitigation Approach Is One Of The Reasons For Its Slower Performance

[LinAGKar]

And no one who spent real money and wanted better performance would be stupid enough to stick with the defaults.

Show me a guide on how to make it fast then. For example, how do you switch to retpolines?

[andyprough]

In any case, if you need to use your machine for heavy single-core workloads, a 20% performance is not acceptable. I did not buy a powerful 2018 laptop to have 2014 grade performance. And it's not "Intel fault" because there is an adequate alternate mitigation (retpoline) with negligible impact.

The IBRS vs retpoline geekbench results are mine and I could directly correlate that 20% single-core performance loss to my workload (I have benchmarked it) which consist of heavy compilation of Android apps (very single-thread heavy).

Also If you look at the above geekbench results, some individual tests results are appalling: AES is 3x slower. SQLite, HTML5 Parse & DOM are 2x slower. Etc.

IBRS is not enabled by default on other distros. Their users do not seem to lose sleep over it (because "think of the security!") and enjoy normal performance.
I don't expect openSUSE to change anything about it though. At best we may have a well hidden option in the installer to disable IBRS and users
not in the know will have their performance crippled. And openSUSE will continue to rank dead last in benchmarks.

So, don't use it. I'm not using it right now, but not because I fear I can't get it to perform despite its default settings, or that I fear it will somehow harm the value of my shiny new laptop. I know I can get it to perform.

[bobbie424242]

In any case, if you need to use your machine for heavy single-core workloads, a 20% performance is not acceptable. I did not buy a powerful 2018 laptop to have 2014 grade performance. And it's not "Intel fault" because there is an adequate alternate mitigation (retpoline) with negligible impact.

The IBRS vs retpoline geekbench results are mine and I could directly correlate that 20% single-core performance loss to my workload (I have benchmarked it) which consist of heavy compilation of Android apps (very single-thread heavy).

Also If you look at the above geekbench results, some individual tests results are appalling: AES is 3x slower. SQLite, HTML5 Parse & DOM are 2x slower. Etc.

IBRS is not enabled by default on other distros. Their users do not seem to lose sleep over it (because "think of the security!") and enjoy normal performance.
I don't expect openSUSE to change anything about it though. At best we may have a well hidden option in the installer to disable IBRS and users
not in the know will have their performance crippled. And openSUSE will continue to rank dead last in benchmarks.

[StefanBruens]

There's a difference between slightly winning/losing, and being up to 5x slower than the next slowest distro. At that point, you have to ask, who would use this in production? Because buying 5x the hardware to compensate gets expensive real fast. Most people won't care about a +/- 20% delta between distros. 500% is a different ballpark.

There is a difference between being 5 times slower in a synthetic benchmark and being slower in a real workload.

There is one subtest in the MotionMark1.1 which is responsible for the difference. With FF 0.64, I get a score of ~100 for the "Multiply" test, with FF 0.66 I get 1.00 +- 100% (+-100%. go figure ...), while Chromium scores 300+. While browsing the web, all 3 show the same performance.

[StefanBruens]

I would argue that even if the OpenSuSE benchmarks are made on the "safe (but slow)" defaults, they do represent the out-of-box experience.

If anything, this implies that OpenSuSE is simply not targeted at the desktop per se.

It is targeted at the desktop. If you have to use a stopwatch to tell the difference between two systems, you better save the time to fetch the stopwatch, and be productive instead.

Performance has to be 20% lower for the difference to be noticeable.

Obviously, that does not mean that it can't be made to run decently as a desktop, but it seems to require skills that are normally reserved for the people who tinker with source-based distributions such as Gentoo and Exherbo (and Arch to some extent).

It does run decently. For e.g. scientific workload which run on cluster and have to squeeze out the last 1%, there is a reason to optimize as much as possible (and often by trial and error, e.g. build, test, rinse, repeat). For regular desktops, there is none. While gentoo may be able to be faster on the last mile, while the Gentoo'er is still compiling, I will have installed a regular package and be done with the job.

[andyprough]

There's a difference between slightly winning/losing, and being up to 5x slower than the next slowest distro. At that point, you have to ask, who would use this in production? Because buying 5x the hardware to compensate gets expensive real fast. Most people won't care about a +/- 20% delta between distros. 500% is a different ballpark.

And no one who spent real money and wanted better performance would be stupid enough to stick with the defaults. Thus you get right back to the circular reasoning that started this discussion.

[Linuxxx]

openSUSE dropped the ball with the release of Linux kernel 5.0!
Without even mentioning it anywhere, they disabled kernel preemption (PREEMPT), which led to significantly higher maximum latency-times!
For desktop-class workloads (like gaming), this is simply unacceptable!

These Distributions have saner defaults (i.e. PREEMPT enabled):

- Solus
- Arch Linux (Manjaro included)
- Unfortunately, that's IT!

These distros are doing it wrong(TM):

- Debian
- Ubuntu (at least low_latency is an option there...)
- Fedora / RHEL
- PCLinuxOS
- SteamOS
- Clear Linux
- openSuSE since Linux 5.0

[xorbe]

Whether or not certain distros "win" in benchmark speed tests is only one small point of relevance regarding whether or not to use that distro. It shouldn't be benchmarked because it's pointless - no one who uses it and wants performance is going to go with the default settings.

There's a difference between slightly winning/losing, and being up to 5x slower than the next slowest distro. At that point, you have to ask, who would use this in production? Because buying 5x the hardware to compensate gets expensive real fast. Most people won't care about a +/- 20% delta between distros. 500% is a different ballpark.

[andyprough]

lol.

How about letting users make an informed decision about using a distro or not? If they don't care about performance, fine, then they ignore the benchmark. Sweeping it under the rug sounds like a case of being afraid some users will see how awful it is and reconsider.

You know what they say about being scared of facts.

Users who decide to "take openSUSE for a ride" without knowing anything about how it is set up and runs are going to be in for a lot of headaches. It is not Ubuntu or Mint - it doesn't hold your hand or try to give you a gaming platform or multimedia streaming platform by default. I used SuSE or openSUSE from about 1999 until just recently, so nearly 20 years, and it was a constant learning experience.

I think we have a lot of Linux users today who came up using Windows and then switched to Ubuntu, and so think that the only value in a system is a constant quest for more speed and to turn their machine into a video game console. However, huge OS's like Debian and SuSE with mammoth repositories have completely different objectives.

[andyprough]

I would argue that even if the OpenSuSE's benchmark are made on the "safe (but slow)" defaults, they do represent the out-of-box experience.

If anything, this implies that OpenSuSE is simply not targeted at the desktop per se.

You are right openSUSE does not seem to be targeted as a Ubuntu or Windows replacement desktop. It is designed as a proving ground for certain technologies. In order to get those technologies to play well together with a minimum of risk of data loss, the community has clearly decided to use conservative defaults. And again, anyone who uses it and wants better performance is going to need to strike out on their own and find performance tweaks.