Avatar von die kleine Himbeere
  • die kleine Himbeere

mehr als 1000 Beiträge seit 25.10.2012

Re: Ich ziehe eine Mischung vor

van Grunz schrieb am 13.01.2018 02:23:

Das halte ich für eine steile These.

Der x32-Artikel bezog sich auf Messungen, nicht auf Thesen.

Natürlich gibt es Fälle, wo 64 Bit tatsächlich einen Performance-Vorteil bringen, du hast einige davon genannt.

Aber das Groß der laufenden Prozesse gehört nicht zu dieser Kategorie.

Nahezu alle "kleinen Befehle" die in einem Shell-Script aufgerufen werde, gehören beispielsweise nicht in diese Kategorie.

Ein Programm wie Photoshop hingegen vermutlich schon.

Ein Punkt der *für* 64-Bit spricht und den ich noch zu erwähnen vergaß, ist Pre-Linking von Shared Libraries.

Dieses ist am effektivsten wenn jede Library unabhängig vom Prozess in dem sie läuft eine individueller Adressbereich zugewiesen werden kann, der in allen Prozessen für diese Library reserviert wird.

Dadurch braucht jede Library dann nur ein einziges Mal im Speicher gehalten zu werden da es keine Adress-Kollisionen gibt, und nicht einmal die Global Offset Table oder Procedure Linkage Table muss mittels Copy-On-Write verdoppelt werden, da auch deren Einträge in allen Adressräumen identisch sind. (Soweit diese Zusammenhänge nicht bekannt sind, empfehle ich das Studium des Artikels "How To Write Shared Libraries" von Ulrich Drepper - ein echter Klassiker.)

Dies spart RAM und erhöht die Mehrfachverwendung von Code im Speicher. Aber 32 Bit Adressraum ist zu wenig dass jede Library ihren eigenen reservierten Bereich zugewiesen bekommen könnte; hier müssen Kompromisse beim Prelinking eingegangen werden, die bei 64 Bit nicht nötig sind.

Zumindest unter Gentoo-Linux gibt es auch tatsächlich Support für Prelinking.

ALLERDINGS - seit ASLR Gang und Gäbe ist, welches quasi das Gegenteil von Prelinking darstellt, bringt dieser 64-Bit-Vorteil in der Praxis (leider) nichts mehr.

Caches sind überaus effektiv, egal ob bei x32 oder x64.

Ich sage nicht dass Caches ineffektiv sind, sondern nur dass ein Cache derselben Größe unter 64 Bit weniger effektiv sein muss als unter 32 Bit.

Denn unter 64 Bit müssen mehr Daten gecached werden um dieselbe Anzahl an Cache-Hits erreichen zu können, weil die einzelnen Datenelemente länger sind.

Eine 64-Bit Pointer-Variable oder ein 64-Bit size_t belegen im Speicher eben doppelt so viel Platz wie die 32-Bit Gegenstücke, und das gilt auch für den Cache.

Während es im RAM nicht so tragisch wäre - von dem hat man üblicherweise genug - tut es im Cache aber "weh" wenn man nun weniger Variablen eines Programms dort unterbringen kann weil diese länger sind.

Das bedeutet weniger Cache-Hits bzw. mehr Cache-Misses, und das schadet der Performance.

Und was die breiteren Register angeht: Das ist nicht notwendiger Weise an die Bitbreite des Datenbusses gekoppelt.

Betrachte dir beispielsweise die MC 68000, wie sie im AMIGA 500 zum Einsatz kam - die hatte durchgehend 32-Bit-Register, aber nur einen 16-Bit Datenbus und war daher eine reine 16-Bit-CPU.

Dennoch profitierte sie von den Vorteilen der breiteren Register, und verhielt sich solange man Berechnungen nur innerhalb der Register anstellte und diese nicht mit dem RAM auszutauschen brauchte, wie eine 32 Bit CPU.

Im Falle von x32 vs. x64 ist der Fall sogar noch eklatanter, da es sich dabei ja um DIESELBE CPU wandelt.

X32 läuft ja auf genau derselben 64-Bit CPU wie x64.

Und profitiert daher auch von genau denselben 64-Bit breiten Registern.

Der Unterschied spielt sich rein in der Software ab, indem kürzere Pointer und size_t-Variablen verwendet werden.

Der gemessene Performance-Vorteil für x32 spielte sich daher auf DERSELBEN Hardware ab.

Bei einer *echten* 32-Bit-CPU käme zu diesen Vorteilen noch der des geringeren Stromverbrauchs dazu (natürlich gleiche Fertigungs-Technik vorausgesetzt), da weniger Transistoren mit Strom versorgt werden müssen.

Ich habe damals jedenfalls tatsächlich versucht ein reines x32-System unter Gentoo aufzusetzen, aber scheiterte leider daran dass einige Programme - etwa Mozilla Firefox - damals einfach nicht in der Lage waren, sich für x32 übersetzen zu lassen.

Und, peinlicher Weise, auch der gcc selbst ließ sich damals nicht unter x32 bauen! Ständig stürzte der Build mit irgend einer Fehlermeldung ab dass eine interne Tabelle zu groß geworden wäre. Nur der vorinstallierte gcc funktionierte. Ich frage mich ernsthaft wie *der* gebaut worden war. Vielleicht mittels Cross-Compiling auf einem 64-Bit-System?

Jedenfalls, x32 ist damals an der Praxis gescheitert.

Trotzdem fand ich das traurig, denn mit Ausnahme von ein paar wenigen - aber wichtigen - Programmen ließ sich eigentlich alles andere als x32 übersetzen und funktionierte auch tadellos.

Meine Erfahrungen sind aber schon ein paar Jahre her und ich verwende Gentoo nicht mehr; vielleicht funktioniert x32 unter Gentoo inzwischen besser.

Bewerten
- +
Anzeige