Aimero schrieb:
Ja, aber warum gibt's nicht einfach die Option beim Install dafür?
"Do you wish to recompile to maximize performance? (Takes time)"
Compilerschalter so auszuwählen, dass sie mit einer bestimmten Software auf einem bestimmten Target eine signifikant bessere Performance erzeugen ist nicht trivial. Ein vereinfachtes Beispiel aus dem Bereich Memory vs. Laufzeit:
Häufig kann man einen Tradeoff machen, man spart Speicher und das Programm wird langsamer oder man "investiert" Speicher, dafür spart man Laufzeit. Abhängig von den vorhanden Cache-Größen kann aber auch kleinerer Code plötzlich schneller sein, wenn er eben komplett in den Cache passt. Bei der nächsten Anwendung, die insgesamt schon größer ist, verkehrt sich das aber ins Gegenteil.
Am Ende ist ein optimiertes Set von Compilerflags für eine große Anwendung wie Firefox deutlich abweichend zu einem kleinen Happen Code wie die Anwendung Cat. Auch braucht Lowlevelcode wie der Kernel andere Optimierungen als LibreOffice.
Auch ist die Frage wie viel ein Optimierung im Compiler überhaupt bringt. AVX oder SSE sind SIMD Instruktionen. Ich wende die gleiche Instruktion, z.B. Addition, nicht auf einen Wert, sondern z.B. auf 16 Werte gleichzeitig an. Wenn der Compiler also 16 unabhängige Additionen direkt in Reihe findet, kann er das vermutlich auf AVX optimieren. Performance von dem Code-Schnipsel hat sich versechzehnfacht. Sind die 16 Additionen irgendwo im Code verstreut findet die Heuristik im Compiler das aber häufig nicht. Der Schalter bleibt komplett wirkungslos. Bei Code wo es einfach keine 16 unabhängigen Additionen gibt sowieso.
Am Ende gibt es Code, der von solchen prozessorspezifischen Compileroptimierungen deutlich profitiert, anderer dagegen fast nicht.
Die Prozessorhersteller haben im übrigen auch in die CPUs Features eingebaut, die z.B. die AVX Einheiten nutzen, wenn sie passende Instruktionen finden, selbst wenn diese nicht für AVX ausgelegt sind.
Ein praktisches Beispiel: Ich habe, vor Jahren, mal eine FFMPEG Version selbst optimiert übersetzt. Damals hatten Grafikkarten noch keine Beschleuniger für sowas und die CPU hat dabei ordentlich gekocht. Meine selbst gebaute Version war auf meiner neuen CPU dann fast doppelt so schnell wie die Version in den Ubuntu Repos. Dabei wird die gleiche rechenintensive Operation immer und immer wieder ausgeführt. Für Stunden. Das lohnt sich. Wenn ich jetzt aber einen Abschnitt im Kernel, der nur alle paar Minuten ausgeführt wird von 10ns auf 5ns Ausführungszeit drücke ist das Ergebnis maximal in synthetischen Benchmarks spürbar.
tl;dr: Falls jemand einen speziellen Anwendungsfall hat, der zu langsam läuft und die Anwendung im Sourcecode vorliegt kann man das versuchen mit dem Compiler zu optimieren. Zu agressive Optimierungen können aber auch für Bugs sorgen. Ansonsten würde ich mich da auf vernünftig ausgelegte Pakete der Distributionsmaintainer verlassen. Mit CachyOS gibt es ja ein Arch Derivat was auf neuste CPUs optimiert ist. Wer compatibilität bis zum 386er will nimmt halt eine eher konservative Distro. Wer einfach nur Spielen will sollte eher darauf achten, dass Grafikkartentreiber zügig aktuallisiert werden und Steam mit Proton gut läuft.
