64 Bit

[MacMark]

Wie Du zum ungewöhnlichen Schluß kommst, 32Bit Software würde auf einem 32/64Bit Prozessor langsamer laufen als 64Bit Software für die gleiche ISA.

Von gleicher ISA habe ich nie gesprochen. Das ist Deine Annahme.

Ich muß noch ergänzen, daß auch der G5 Instruktionen hat, die nur für 64-Bit-Programme und nicht für 32er zur Verfügung stehen. Beispielsweise load-word-algebraic, load-word-algebraic-indexed und double-word-Versionen von diversen Instruktionen. Dann noch 64-Bit-Integer- und 64-Bit-Logik-Operationen, die _weniger_ Instruktionen benötigen, um 64-bittig zu laden und zu speichern. Mit 32 Bit bräuchte man mehr Register und mehr Load/Store-Instruktionen.

Daher, neben den in meinen anderen Posts genannten Gründen, folgt auch hieraus: 64-Bit-Programme können auf dem G5 schneller als 32er sein, allein aus dem Grund, daß sie 64-bittig sind.

Ferner erscheint nun Deine Annahme, es wäre die gleiche ISA, als inkorrekt.

 

[MacMark]

Nichts, aber eine 32Bit App mit Paging aufzubohren ist Frickelei.
…

Ja. Ich wollte Dir zeigen, daß man mit 32-Apps langsamer ist als mit 64ern.

 

[MacMark]

… Deshalb wundert es mich, weshalb Du den Unterschied x86 x86-64 anführst. Das sind zwei verschieden ISAs.

Weil auch dort 64-Apps schneller sind als 32-Apps. Du hattest das in Frage gestellt. Ich führe daher den Beweis für meine Aussage.

 

[tjp]

Von gleicher ISA habe ich nie gesprochen.

Aber ich tat das! Alles andere fällt unter Trivilität, und bei bedarf meiner Meinung nach gar keiner Klärung.

 

[MacMark]

Wie soll denn ein Befehlssatz gleichzeitig 32- und 64-bittig sein können? Wenn er nur 32er Befehle enthält ist er nicht 64-bittig. Wenn er auch 64er Befehle enthält, können die nicht von 32er-Programmen benutzt werden. Bei einem 64er ISA sind zwangsläufig immer Befehle dabei, die von 32er Programmen nicht genutzt werden können.

Beim PPC ist es beispielsweise so, daß er eine 64-bittige Architektur ist, aber ein 32er-Subset enthält.

Mit Deinem letzten Posting verstehe ich nicht, was überhaupt Dein Einwand für einen Sinn hatte. Auch Dein "wenn die CPU dieselbe ISA für 32bit und 64Bit Modus verwendet" ergibt in meinen Augen keinerlei Sinn.

 

[tjp]

Wie soll denn ein Befehlssatz gleichzeitig 32- und 64-bittig sein können?

Da sich bei einigen CPUs der 64Bit Modus vom 32bit Modus nur davon unterscheidet, daß die GPRs 64Bit statt 32Bit breit sind und einige wenige zusätzliche Befehle für 64Bit zur Verfügung stehen spricht man von derselben ISA. Siehe Dokumentation von IRIX, Solaris oder AIX. Bei einigen anderen CPUs z.B. HP-PA, x86-64 unterscheiden sich der 64Bit Modus deutlich vom 32Bit Modus. Bei HP-PA ist die letzte 32bit ISA 1.1e und die 64Bit ISA 2.0. Infos gibt's bei HP. Beim AMD64 wurde auch eine deutliche Änderung der IA32 ISA zu IA32-64 ISA vorgenommen. Alpha und IA64 waren immer exklusiv als 64Bit CPUs designed. Der IA64 hat noch einen angeflanschten IA32 Hardware Emulator, der zu nichts taugt. Mittlerweile wird IA32 Code nur noch mittels Recompiler auf IA64 ausgeführt, daß ist deutlich schneller.

Die Sprechweise die Dir vorschwebt wird allgemein nicht genutzt: Ich kenne niemanden der je behauptet hätte 32bit Software der gleichen ISA liefe im 32Bit Modus langsamer als die 64Bit Version für die gleiche ISA der identsichen Software.

Der Grund dafür ist relativ einfach. Wenn man richtig UNIX konforme Software schreibt, dann compiliert diese ohne Sourcecodeanpassung sowohl als 32Bit wie auch als 64Bit Software. Das schließt irgendwelche Memory Mapping Geschichten eh aus, aber wie gesagt solche Nichtlösungen waren auf UNIX Rechner nie ein Thema, da es frühzeitig 64Bit Laufzeitumgebungen gab. (OSF/1 1.2, IRIX 6.4, AIX 4.3, Solaris 7, HP-UX 11.00). Der einzige Prozessor, der es erlaubte mehr als 32Bit RAM zu adressieren ohne ein 64Bit Prozessor zu sein, war der auf dem Pentium 4 basierende Xeon von Intel. Dieser erlaubte 36Bit Adreßraum. Intel Frickelei wie man sie seit langen Jahren kennt.

Mit Deinem letzten Posting verstehe ich nicht, was überhaupt Dein Einwand für einen Sinn hatte. Auch Dein "wenn die CPU dieselbe ISA für 32bit und 64Bit Modus verwendet" ergibt in meinen Augen keinerlei Sinn.

Das ist die übliche Sprachregelung. Siehe Doku von IBM, SUN, SGI.

 

[MacMark]

Wenn Du mit einem 32-Bit-Programm mehr als 4 GB Daten im Speicher zeitgleich zugreifbar halten willst, dann ist das auch bei "richtig UNIX-konformer Software" nicht möglich ohne programmeigene Speicherfrickelei.

Die Spitzfindigkeiten bzgl. ISA hast Du eingeführt in die Diskussion. Meine Aussage war, daß 32-Bitsoftware langsamer läuft als 64-Bitsoftware, weil
• sie (die 64er-Software) mehr Daten zeitgleich zugreifbar halten kann im Speicher
• sie mit weniger Aufrufen Daten laden und speichern kann
• sie spezielle Operationen zur Verfügung hat, die den Job schneller erledigen als die entsprechende Lösung über 32 Bit
• sie spezielle zusätzliche Register nutzen kann

Nach Deiner Definition nutzen 32/64-Apps auf dem G5 die gleiche ISA. Gemäß diesem und Beitrag #121 gilt daher: 64er Apps laufen auf der gleichen ISA des G5 schneller als 32er Apps.

Bei Core 2 Duo laufen 64er ebenfalls schneller als 32er, allein schon aus dem oben in #113 genanntem Grund, daß sie mehr Register nutzen können.

Deine ursprüngliche Aussage, 32er-Apps wären schneller als 64er, ist daher mindestens in den beiden Mac-relevanten Fällen, G5 und Core 2 Duo, unzutreffend; und zwar sowohl für "gleiche ISA" als auch "verschiedene ISAs".

 

[tjp]

Wenn Du mit einem 32-Bit-Programm mehr als 4 GB Daten im Speicher zeitgleich zugreifbar halten willst

DAS ist eine technische Unmöglichkeit, man kann nur über spezielle Algorithmen aus dem 32bit Adreßraum Daten ausblenden und temporär wieder in den Adreßraum einblenden. Man hat aber niemals Zugriff auf mehr als den 32Bit Adreßraum.

Für mich ist es hier zu Ende, da es keinen Sinn hat über unterschiedlichen Auffassungen zu streiten.

 

[MacMark]

Das wollte ich hören Dann sind wir uns ja einig, daß 32-Bit-Programme, sogar wenn sie "richtig UNIX-konforme Software" sind, dafür auf programmeigene Speicherfrickelei angewiesen wären.

Du wirst nun wohl auch zustimmen, daß eine 64-Bit-Version des Programmes die Aufgabe flotter erledigen würde, weil es diese Speicherfrickelei nicht nötig hat.

Einer von den vielen Punkten, die es 64-bittigen Programmen erlauben, schneller als 32-bittige zu sein. Quod erat demonstrandum.

 

[MacMark]

ich meine eigentlich da os x nun nicht mehr bei 4GB Ram fertig ist pro App.

Pro Prozess. Jede App darf aus beliebig vielen bestehen.…

Da paßt etwas nicht, denn ein laufendes OS X-Programm ist ein BSD process. Die für den BSD-Prozeß zuständige Mach-Task enthält neben bestimmten anderen Resourcen auch den Adreßraum des Programms. Ein Prozeß mit mehreren Threads ist implementiert durch eine Mach-Task, die mehrere Mach-Threads enthält. Alle Threads der Task nutzen den Adreßraum der Task.

 

[Olliprise]

also kann man sich die 129€ für Leopard sparen?

 

[MacMark]

also kann man sich die 129€ für Leopard sparen?

Nein.

 

[Elmar0903]

Ach ist der Thread schön Das erinnert mich an Assembler-Programmierung auf dem guten 68000.
Lieber ein move.l statt move.w und dann mit einem Schiebebefehlen wie shl oder shr die Daten an die richtige Position schieben. Oberes Wort, unteres Wort oder vielleicht doch auf Nibble-breite. Und ein clr.w ist immer noch schneller als ein move.w #00,d0. Jetzt beginnt das Clockcycling wieder.