News CachyOS: Gaming-Distribution dominiert auch Workstation-PCs

[PCGH_Sven]

Auf der neuen System76 Thelio Major mit AMD Ryzen Threadripper 9980X setzt sich die Gaming-Distribution CachyOS in den jüngsten Phoronix-Benchmarks klar gegen Arch Linux, Ubuntu 26.04 LTS und Pop!_OS 24.04 durch.

Was sagt die PCGH-X-Community zu CachyOS: Gaming-Distribution dominiert auch Workstation-PCs

Bitte beachten: Thema dieses Kommentar-Threads ist der Inhalt der Meldung. Kritik und allgemeine Fragen zu Online-Artikeln von PC Games Hardware werden hier gemäß der Forenregeln ohne Nachfrage entfernt, sie sind im Feedback-Thread besser aufgehoben.

 

[tokenrider]

Die CachyOS-Benchmark-Ergebnisse sind m.E. mit Vorsicht zu genießen: Der Performancevorsprung kommt nicht nur aus Kernel-Tuning oder Scheduler-Patches, sondern Kernel und Userland sind nicht mit den Standard-CFLAGS, sondern mit höheren Optimierungsstufen gebaut. Das kann gut gehen, muss es aber nicht.

Ein fairer Vergleich wäre es nur, wenn alle Distributionen unter gleichen Compiler-Flags getestet würden. Phoronix testet die Distributionen jeweils in ihrer Default-Konfiguration, was die "Vergleichbarkeit" einschränkt.

Das Aktivieren höherer Optimierungsstufen beim GCC ist mit Vorsicht zu behandeln. Es war schon immer so, dass Kernel und Userland maximal mit -O2 übersetzt werden — nicht nur bei Linux, auch bei FreeBSD und anderen.
Und meines Erachtens hat sich das bis heute nicht geändert.

Alle anderen Linux-Distributionen setzen deshalb auch lieber auf Nummer sicher. Es nützt nichts, das letzte Quäntchen Performance herauspressen zu wollen, wenn dabei fehlerhafter Code entstehen kann. Sonst wären diese CFLAGS längst zum Default gemacht worden. Das ist der Unterschied zwischen Risikobereitschaft und konservativem, stabilem Betrieb.

 

[XT1024]

Es juckt mich nicht, was die machen.

 

[Penman]

Das Aktivieren höherer Optimierungsstufen beim GCC ist mit Vorsicht zu behandeln. Es war schon immer so, dass Kernel und Userland maximal mit -O2 übersetzt werden — nicht nur bei Linux, auch bei FreeBSD und anderen.
Und meines Erachtens hat sich das bis heute nicht geändert.

Ein fehlendes Vertrauen in diese Optimierungsstufe berechtigt durchaus ein solchen Zweifel. Aber ich bin kein Fan von "das haben wir immer so gemacht" (Bonus: "...und als wir es mal anders gemacht haben, war es schlecht"). Wenn es Gründe zur Annahme gibt, dass sich das Problem gebessert hat, kann man ruhig mal wieder einen Versuch wagen.
Dass man sich mit Arch-basierten Distros durchaus auf ein Abenteuer einlässt, sollte ja schon einleuchten. Der Arch Kernel scheint ja ohnehin schon einige gute Optimierungen bekommen zu haben, die noch etwas mehr Performance herauskitzeln. Wer einen _900 mit einem _950 Prozessor ersetzen würde, weil er die Performance will, könnte sich überlegen, ob Softwareoptimierung ein Quäntchen mehr Performance wert sind. Bei eventuellem Risiko, das durch O3 entsteht. Ich wäre jetzt natürlich an Berichten interessiert, die auf O3 zurückzuführen sind.

Aber andersherum: Phoronix hat die Benchmarks geliefert. O3 hat jetzt auch keine nennenswerten Gewinne gegenüber O2 geliefert. Gut, dass jemand diese Daten liefert. Und auch gut, dass CachyOS den Ruf von O3 eventuell aufbessert. Nicht, dass man das jetzt machen müsste, aber es ist eine nette Geste gegenüber den Entwicklern, die eventuell an den Problemen gearbeitet haben.

Aber so weltbewegend sind die Benchmark Ergebnisse auch wieder nicht. Wer es wirklich auf Performance anlegt, kommt ohnehin nicht drumherum, sich von der Idee des General Purpose wegzubewegen und spezialisierte Lösungen zu bauen - ob nun in Software oder so gar in Hardware.

 

[inhuman_nature]

Es juckt mich nicht, was die machen.

Aha, nun weiß ich Bescheid darüber, was Dich nicht juckt! Oder auf Deinem Niveau ausgedrückt: Mich juckt nicht, dass Dich die Nachricht nicht juckt.^^

 

[tokenrider]

Ein fehlendes Vertrauen in diese Optimierungsstufe berechtigt durchaus ein solchen Zweifel. Aber ich bin kein Fan von "das haben wir immer so gemacht" (Bonus: "...und als wir es mal anders gemacht haben, war es schlecht"). Wenn es Gründe zur Annahme gibt, dass sich das Problem gebessert hat, kann man ruhig mal wieder einen Versuch wagen.

Bei Betriebssystemen spielt man nicht einfach an den CFLAGS rum, da geht es in erster Linie um Stabilität.

Du hast nichts von ein paar Prozent mehr Performance, wenn Compiler und Assembler falschen Code generieren.

Im Übrigen: Bei der Größe und Komplexität eines Betriebssystems kannst du das Compilat nicht vollumfänglich testen. Darum setzt man hier auf Erfahrungswerte, und die besagen nun mal, dass man mit -O1/-O2 vielen möglichen Problemen aus dem Weg geht.

Ich mache Unix seit den späten 80ern und habe in über 25 Jahren eine Menge Code kompiliert.
Kernel, Userland, X-Window-System mit Roell-Patches für Tseng ET4000 , über 50 Open-Source-Programme gepackaged/maintained. Dabei habe ich für mich privat natürlich auch versucht, mit höheren Optimierungen mehr Performance herauszukitzeln.

Die Erfahrung lehrt: Man übertreibt es besser nicht mit höheren Optimierungsstufen des C-Compilers.
Soweit ich mich erinnere, wurde in den READMEs einiger Programme auch explizit davor gewarnt.

Es ist einfach nur vernünftig, das zu verwenden, was von vielen als stabil und funktionsfähig befunden wurde.

Wenn Du den wilden Maxen spielen willst, der meint, es besser zu wissen, bitte, mach es bei Dir zu Hause.
Aber wirf verantwortungsvollen Entwicklern nicht vor, sie würden es sich zu einfach machen, frei nach dem Motto
"das haben wir schon immer so gemacht".

 

[ToZo1]

Aha, nun weiß ich Bescheid darüber, was Dich nicht juckt! Oder auf Deinem Niveau ausgedrückt: Mich juckt nicht, dass Dich die Nachricht nicht juckt.^^

Es ging wohl eher um das Rumgejammer von Tokenrider wegen des Körneltunings, was ihn hingegen nicht juckt. So habe ich es zumindest verstanden.

 

[inhuman_nature]

Es ging wohl eher um das Rumgejammer von Tokenrider wegen des Körneltunings, was ihn hingegen nicht juckt. So habe ich es zumindest verstanden.

Ah, mag sein. Das wäre mir nicht klar gewesen.

 

[tokenrider]

Es ging wohl eher um das Rumgejammer von Tokenrider wegen des Körneltunings, was ihn hingegen nicht juckt. So habe ich es zumindest verstanden.

Rumgejammer? Das ist einfach so.
Wäre es völlig unkritisch, dann wäre das der Standard.
Überleg mal, da ist was dran ...

 

[BigYundol]

CachyOS läuft bei mir absolut stabil. Die Grafiktreiber können sogar das Tuning zuverlässig halten. Das Hauptproblem ist die Zu-viele-Köche-Wayland-Dauerbaustelle...

 

[EM_EN]

"Peter Jung: In den Phoronix-Benchmarks ist CachyOS derzeit tatsächlich die schnellste Distribution, nachdem Intel Clear Linux eingestellt hat. Aber es gibt nach wie vor großes Potenzial - vor allem bei den GPU-Treibern und im Proton-Stack fürs Gaming."

Aus einem Interview im März 2026 mit der PCGH. Damit hat Cachy den Vorsprung gehalten auf dieser Höllenmaschine. Nun ist die Frage aber was bringt das genau, außer einen ersten Platz in dieser ausgewählten Benchmark?

 

[_Oskar_]

Wie gesagt, persönlich bin ich der Meinung, CachyOS könnte es z.B so wie Artix machen, den Menschen bei der Installation die vollkommen freie Wahl zu lassen, welches Init System man benutzen möchte, dies wäre zweifelsohne positiv.

Beispielsweise: s6 /s6 rc oder runit oder dinit und das gute alte OpenRC etc.

 

[Andreas1975]

Wie gesagt, persönlich bin ich der Meinung, CachyOS könnte es z.B so wie Artix machen, den Menschen bei der Installation die vollkommen freie Wahl zu lassen, welches Init System man benutzen möchte, dies wäre zweifelsohne positiv.

Beispielsweise: s6 /s6 rc oder runit oder dinit und das gute alte OpenRC etc.

Na das schreit ja quasi nach einer weiteren Distro!

Bei einem OS darf es auch, insbesondere für Enthusiasten, um Geschwindigkeit gehen. Das da optimiert wird ist völlig in Ordnung. Auch das die unterschiedlichen Distros mit anderen Einstellungen an den Start gehen.

 

[Terence-Hill]

Ein fehlendes Vertrauen in diese Optimierungsstufe berechtigt durchaus ein solchen Zweifel. Aber ich bin kein Fan von "das haben wir immer so gemacht" (Bonus: "...und als wir es mal anders gemacht haben, war es schlecht"). Wenn es Gründe zur Annahme gibt, dass sich das Problem gebessert hat, kann man ruhig mal wieder einen Versuch wagen.
Dass man sich mit Arch-basierten Distros durchaus auf ein Abenteuer einlässt, sollte ja schon einleuchten. Der Arch Kernel scheint ja ohnehin schon einige gute Optimierungen bekommen zu haben, die noch etwas mehr Performance herauskitzeln. Wer einen _900 mit einem _950 Prozessor ersetzen würde, weil er die Performance will, könnte sich überlegen, ob Softwareoptimierung ein Quäntchen mehr Performance wert sind. Bei eventuellem Risiko, das durch O3 entsteht. Ich wäre jetzt natürlich an Berichten interessiert, die auf O3 zurückzuführen sind.

Aber andersherum: Phoronix hat die Benchmarks geliefert. O3 hat jetzt auch keine nennenswerten Gewinne gegenüber O2 geliefert. Gut, dass jemand diese Daten liefert. Und auch gut, dass CachyOS den Ruf von O3 eventuell aufbessert. Nicht, dass man das jetzt machen müsste, aber es ist eine nette Geste gegenüber den Entwicklern, die eventuell an den Problemen gearbeitet haben.

Aber so weltbewegend sind die Benchmark Ergebnisse auch wieder nicht. Wer es wirklich auf Performance anlegt, kommt ohnehin nicht drumherum, sich von der Idee des General Purpose wegzubewegen und spezialisierte Lösungen zu bauen - ob nun in Software oder so gar in Hardware.

Nur weil etwas seit vielen Jahren auf eine bestimmte Weise gemacht wird, bedeutet das nicht automatisch, dass es veraltet oder falsch ist. Es gibt so viele Standards die älter als 30-40 Jahren sind und bis heute ihre gültigkeit haben. Gerade bei einem Betriebssystem steht Stabilität und Zuverlässigkeit an erster Stelle, oder sollte es zumindestens.

Natürlich kann man Compiler-Optimierungen, Kernel-Parameter aggressiver einstellen, um die letzten Prozentpunkte an Leistung herauszuholen. Die entscheidende Frage ist aber immer, welchen Preis man dafür bezahlt.

Du kannst auch dein RAM-Timings bis an die Grenze treiben und sagen: „Wenn der Rechner dafür alle paar Tage einmal abstürzt, ist das eben so.“ Für manche Enthusiasten mag das akzeptabel sein. Für ein Betriebssystem, das möglichst zuverlässig funktionieren soll, ist Stabilität jedoch meist wichtiger als die letzten 0,1–1 % Performance.

 

[-nocturne-]

Ich sehe das ähnlich wie @tokenrider . Was nutzt einem fehlerhafter Code für ein paar Prozent mehr Leistung. Das ist iwie unnötig.

Was mich mehr stört ist die Aussage " im Auslieferungszustand " - Arch hat keinen Auslieferungszustand. Der Nutzer definiert den Auslieferungszustand bei seiner Installation und damit auch die Optimierung.

 

[empy]

Natürlich kann man Compiler-Optimierungen, Kernel-Parameter aggressiver einstellen, um die letzten Prozentpunkte an Leistung herauszuholen. Die entscheidende Frage ist aber immer, welchen Preis man dafür bezahlt.

Hauptsächlich wohl höhere Kompilierzeit, größere Binaries, keine Garantie, dass die Performance steigt oder nicht sogar sinkt und dass einem irgendwelche Hacks um die Ohren fliegen können, die außerhalb der Definition der Sprache liegen, mit weniger aggressiver Optimierung aber eventuell funktionieren. Letzteres dürfte einem aber auch aus allen möglichen anderen Gründen um die Ohren fliegen dürfen. Von genereller Instabilität lese ich nicht wirklich was.

Diese Informationen entnehme ich zumindest diesem mehr als zehn Jahre alten Stackover-Flow-Thread:
https://stackoverflow.com/questions/34246954/are-there-any-drawbacks-to-using-o3-in-gcc

Der Grund, aus dem das also nicht schon nicht längst standardmäßig genutzt wird, dürfte dementsprechend sein, dass die meisten Entwickler und Maintainer finden, dass der Performancegewinn die höhere Kompilierzeit, den höheren Platzbedarf und den Aufwand, zu testen, ob es wirklich was nutzt und nicht schadet, die möglichen Performancegewinne nicht rechtfertigen.

 

[inhuman_nature]

Wie gesagt, persönlich bin ich der Meinung, CachyOS könnte es z.B so wie Artix machen, den Menschen bei der Installation die vollkommen freie Wahl zu lassen, welches Init System man benutzen möchte, dies wäre zweifelsohne positiv.

Beispielsweise: s6 /s6 rc oder runit oder dinit und das gute alte OpenRC etc.

Wobei ich mal über den Umstand gestoßen bin, dass Programm (e) SystemD benötigen würden. Ich weiß allerdings nicht mehr welche(s) ...
Aber ja, an sich ist Wahlfreiheit eine gute Sache.

 

[_Oskar_]

Wobei ich mal über den Umstand gestoßen bin, dass Programm (e) SystemD benötigen würden. Ich weiß allerdings nicht mehr welche(s) ...
Aber ja, an sich ist Wahlfreiheit eine gute Sache.

Es gibt viele Wege nach Rom.

 

[tokenrider]

Zu der Sache noch mal was aus der Praxis. Ich hatte mal einen Fall bei einem Kunden mit CentOS – da lieferte ein GAWK-Script ein falsches Ergebnis. Probeweise habe ich die gleiche GAWK-Version unter FreeBSD frisch kompiliert, und unter FreeBSD lieferte das GAWK-Script die richtige Ausgabe. An diesem Beispiel ist deutlich erkennbar, dass das ansonsten laufende CentOS irgendwo eine Macke hatte. Wo genau, das habe ich nicht weiter verfolgt – entweder Compiler, Assembler oder irgendwelche Libraries. Das CentOS lief ansonsten unauffällig stabil, keine Core Dumps, keine Kernel Panics.

Fazit: Manche Fehlerbilder treten nicht offensichtlich durch Core Dump oder Kernel Panic zutage. An diesem Beispiel ist deutlich zu erkennen, dass Aussagen wie „Es läuft doch und liefert sogar super Benchmark-Ergebnisse" nichts über die Code-Qualität des gesamten Systems (Kernel, Userland) aussagen.

Die hervorragenden Benchmark-Ergebnisse, die man sich mit höheren Optimierungsstufen des C-Compilers „teuer erkauft", sagen letztendlich nichts über die resultierende Code-Qualität aus. Auch der GCC selbst könnte durch zu hohe Optimierungen "Macken" bekommen, die derartige Fehler eher noch begünstigen.

 

[empy]

Fazit: Manche Fehlerbilder treten nicht offensichtlich durch Core Dump oder Kernel Panic zutage.

Dass Code nicht zwangsweise tun muss, was er soll, nur weil er kompiliert und nicht abstürzt, lernt man eigentlich extrem früh, wenn man sich mit Softwareentwicklung beschäftigt. Da helfen nur Tests. Mein Fazit stand heute: Wenn der Quellcode die Optimierung nicht überlebt, dann hat jemand gepfuscht und je schneller man das bemerkt und behebt, desto besser.