flmr schrieb:
Nachdem der andere Thread geschlossen wurde möchte mal mit ein paar Unklarheiten aufräumen. Ich hoffe, dass das Niveau nicht direkt wieder derart abfällt. Dadurch dass es kein Artikel der Redaktion ist, zieht es vielleicht weniger nicht ernsthafte Interessenten als Leser an.
Q: Benachteiligt Clear Linux andere Hersteller?
A: Nein. Auch AMD Zen CPUs zeigen teils deutlich bessere Performance als unter anderen Distributionen.
Q: "Trickst" Intel, um die Performance [seiner Produkte] besser aussehen zu lassen?
A: Nein, die Änderungen sind transparent, für jeden einseh- und überprüfbar und darüber hinaus auch noch gut dokumentiert.
Q: Warum arbeitet Intel nicht an anderen Distributionen mit, und macht die x-te Distribution?
A: Das eine schließt das andere nicht aus. Die meisten Änderungen, etwa im Kernel, durchlaufen den ganz normalen Entwicklungszyklus und gehen upstream. Sie stehen nur in Clear z.T. früher bereit. Andere Dinge sind nicht 1:1 übertragbar und dienen in erster Linie dazu, zu zeigen, was machbar ist. Clear Linux ist eher als eine Art Forschungsprojekt gestartet. Der Fokus der meisten Distributionen ist halt nicht die reine Performance, sondern Dinge wie Portabilität oder Stabilität werden stärker gewichtet. Auch werden gerne Lösungen präferiert, die sich über lange Zeit bewährt haben und besser getestet sind.
Darüberhinaus ist Intel seit langer Zeit einer der größten Beteiligten in der Linux Entwicklung, nicht nur im Kernel. Intel hat ein starkes Interesse daran, dass ihre Produkte (neben CPUs und GPUs und weiterem auch Storage-, Netzwerklösungen) überall möglichst gut funktionieren und möglichst gut performen. Es ergibt überhaupt keinen Sinn, zu behaupten, Intel würde nur in Clear Linux für bessere Resultate sorgen und sonst nicht.
Q: Warum ist Clear Linux schneller als andere Distributionen?
A: Hier steckt der Fehler eigentlich schon in der Frage. Unter Clear Linux wird nämlich schlicht andere Software ausgeführt als anderswo.
Hier muss man etwas ausholen. Software wird größtenteils in Hochsprachen geschrieben, wie z.B. in C. Ein Compiler übersetzt den Programmcode dann in Maschinensprache, je nach CPU Architektur (z.B. x86, POWER oder ARM) kommt ein anderes, ausführbares Objekt heraus. Die gängigen Toolchains haben sehr viele Optimierungsmöglichkeiten eingebaut und noch viel mehr Stellschrauben, die das Resultat beeinflussen. Oft sind das einfache time-memory tradeoffs, d.h. man übersetzt Code so, dass er z.B. etwas mehr Speicher belegt, dafür aber weniger Rechenzyklen braucht (oder andersherum). Compiler haben für viele Architekturen Profile, die die Codegenerierung beeinflussen. Die Profile beinhalten dann z.B. Informationen über Cachegrößen und -hierarchien, ob die CPU SMT unterstützt, wie ein Kern intern aufgebaut ist, usw. Das sind "Tuning"-Parameter, die die Performance anderer CPUs beeinträchtigen kann, der Code dort aber zunächst mal lauffähig bleibt. Es gibt aber auch "Architekturparameter", die dann beschreiben welche Befehlssatzerweiterungen durch die CPU unterstützt werden usw. Bei deren Verwendung kann dann Code erzeugt werden, der eben nicht mehr auf allen x86-64 CPUs läuft, sondern z.B. nur noch auf den allerneusten, die AVX-512 können.
Jetzt ist es natürlich so, dass die meisten Distributionen Softwarepakete als binaries ausliefern, also nicht den Quellcode der Programme, sonder das Ergebnis der Übersetzung in Maschinencode. Und damit man möglichst kompatibel bleibt, baut man hier generische binaries, die idR. sinnvolle defaults haben und auf allen x86-64 CPUs lauffähig sind, aber eben nicht alle möglichen Optimierungen beinhalten.
Man kann auch nicht einfach zig Versionen von binaries ausliefern, denn dann würden die Programme (und Repos) riesig werden (und ggf. Paketmanager komplexer). Würde man aber als User für seine eigene Distribution einmal alle Pakete nachbauen, mit der speziell verwendeten CPU Architektur und aktivierten Optimierungen, dann hätte man schon den Großteil des Performancegewinns, der Clear Linux bringt, erreicht. Aber das ist natürlich sehr aufwendig und bei jedem Update muss man die Pakete erneut bauen.
Was jetzt auch klar wird, ist dass Code, der bereits (durch die Programmierer) hochoptimiert geschrieben wurde (fast) nicht mehr schneller wird. Hier wäre der Unterschied zwischen Clear und anderen Distributionen sehr gering. Aber das ist natürlich für den Programmierer viel aufwendiger und er muss sich z.B. darum kümmern, falls er Befehlssatzerweiterungen benutzt, dass zur Laufzeit auch alternative Implementierung zur Verfügung steht, damit die Software auf älteren Prozessoren lauffähig bleibt. Oder er sagt einfach "mein Programm läuft nur ab Haswell aufwärts", wenn er auf die anderen Nutzer/Kunden verzichten kann/will. Und da Performance oft nicht das wichtigste und vor allem nicht das einzige Problem bei Softwareprojekten ist, wird das oft nicht gemacht. Andererseits werden aber dadurch natürlich auch oft Features neuer CPUs nicht genutzt. Intel hat daran maßgeblichen Anteil, weil sie ihre billigen CPUs oft beschneiden. Hätten z.B. auf einen Schlag alle neuen Intel CPUs AVX bekommen, hätten wir heute sehr wahrscheinlich deutlich mehr AVX Code in Anwendungen.
Wie schafft es Clear Linux aber, von diesen Optimierungen Gebrauch zu machen und trotzdem kompatibel zu bleiben?
Hier wird ein besonderes Feature benutzt, das Compiler noch nicht allzulange haben: Function Multiversioning (FMV). D.h. für eine (besonders relevante, da zeitaufwendige) Funktion werden jeweils mehrere Versionen erzeugt, z.B. eine generische, eine für AVX, eine für AVX2. Zur Laufzeit wird dann die passende Version der Funktion verwendet. Problem dabei: auch hier muss der Programmcode schon vor dem Übersetzen spezielle Annotationen für den Compiler aufweisen. Und genau das ist der knackende Punkt, denn das hat Intel z.T. automatisiert und patcht viele Softwarepakete genau mit dieser Änderung.
Ich mache mal noch ein Beispiel, damit klarer wird, wie Software, die nicht durch den Entwickler optimiert wurde, z.B. durch AVX profitieren kann.
Code:
int a[256], b[256], c[256];
void foo()
{
for (int i=0; i<256; i++){
a[i] = b[i] + c[i];
}
}
int main()
{
foo();
return 0;
}Das simple Programm nimmt drei Arrays, jeweils bestehend aus 256 Zahlen. Am Ende soll im ersten Array (a) an der i-ten Stelle die Summer der i-ten Zahl in b und der i-ten Zahl in c stehen. Die einfache Lösung ist, alle Werte einzeln nacheinander durchzugehen und jeweils die Addition vorzunehmen. So wurde es hier auch programmiert und genauso würde die CPU es auch ausführen. Sie braucht also 256 Schleifendurchläufe, in jedem davon macht sie eine Addition und geht dann einen Schritt weiter.
Eine CPU mit AVX2 ist aber in der Lage, einen Befehl wie die Addition auf mehrere Zahlen gleichzeitig auszuführen. Man verrechnet dann nicht mehr einzelne Zahlen (Skalare), sondern Gruppen von Zahlen (Vektoren). Z.B. bei AVX2 mit 256 Bit gehen 8 32-bittige Zahlen gleichzeitig. Man kann das ganze also herunterbrechen auf nur noch 32 Schleifendurchläufe, in denen jeweils eine Vektor-Addition (8 Zahlen gleichzeitig) stattfindet.
Diese sogenannte auto-vectorization ist natürlich nur ein eine von sehr vielen Möglichkeiten, aber eine mMn. auch für Laien leicht verständliche.
Und durch FMV kann der Compiler jetzt eben eine deutlich schnellere Variante der Funktion "foo" für AVX-CPUs erstellen und eine generische. Und da AMD durch AVX genauso profitiert wie Intel (ggf. sogar noch mehr, da es keine separaten, niedrigeren "AVX-Taktraten" gibt), funktioniert diese Optimierung dort automatisch ganz genauso gut.
Q: Bist du involviert?
A: Nein, ich bin nicht im Clear Linux Projekt und auch sonst nicht an einem Intel Projekt beteiligt. Persönlich benutze ich Arch Linux.
Q: Bist du ein Intel-Fanboy?
A: Nein. Mein letzter CPU Tausch war der von Zen1 auf Zen3.
Zuletzt bearbeitet:
