Delphi 64 Bit langsamer als 32 Bit

[Bernhard Geyer]

Zitat:

Zitat von Delphi-Laie (Beitrag 1223904)

Auch bei Cardinal scheint es keine "Aufbohrung" gegeben zu haben.

Wurde mit Einführung des 32-Bit-Delphis noch großspurig von "generisch" gesprochen, so daß man sich über das "automatische Mitwachsen" der (passend gewählten, also generischen) integren Datentypen bei Bitanzahlvergrößerung des Compilates freuen konnte, ist dieser gute Vorsatz keine 20 Jahre (!) später schon wieder passé und obsolet. Schade.

Ein glück das hier Delphi kein eigenbrötlerischen Weg geht und genau das macht wie 98% der andereen Programiersprachen auch. Ich fände es schlechter wenn Delphie hier den falschen Wef des Mitwachsens gehen würde.

[Union]

Zitat:

Zitat von Smut (Beitrag 1223917)

Meine konkrete Frage: Warum wird von M$ auf einen 64bit System 32bit Software per Default installiert?

Weil die ganzen existierenden AddOns nicht 64-bit fähig sind. Z.B. das ganze Mail API.

[Bernhard Geyer]

Zitat:

Zitat von Union (Beitrag 1223918)

Z.B. das ganze Mail API.

Kann ich nicht bestätigen. Nachdem die in der JCL die Anpassungen/Fixes vorgenommen wurden funktioniert der Simple-MAPI-Zugriff auch mit 64-Bit Outlook

[Union]

Es ging darum warum Microsoft 32bit auf 64bit Systemen standardmäíg installiert. Es ging nicht um JVCL Kompatibilität.

[jaenicke]

Zitat:

Zitat von mkinzler (Beitrag 1223902)

Oder man ersetzt INTEGER durch NativeInt

Bzw. deklariert NativeInt als Integer für ältere Delphiversionen, da es NativeInt halt noch nicht so lange in Delphi gibt.
Aber von diesen Typersetzungen halte ich nicht viel, da sie im Quelltext an einer konkreten Stelle (abgesehen von Mouseover-Hints) nicht direkt ersichtlich sind. Da schreibe ich es lieber dort hin wo es wirklich gebraucht wird und nehme das IFDEF in Kauf...

Beruflich habe ich das Problem ohnehin nicht, da wir Wartungsverträge haben und die Projekte nicht viele Delphiversionen zurückliegen, wenn überhaupt. Aber bei Open Source sieht das halt anders aus...

[Daniel]

Microsoft hat sich das mit der Frage, wo welches Office installiert werden sollte, schon überlegt. Es gibt reichlich Dokumente dazu, z.B. Folgendes:

http://office.microsoft.com/en-us/wo...010369476.aspx

Kurzfassung ist wohl, dass die überwiegende Mehrheit der Anwender keinen Vorteil aus den weiteren 32bit ziehen kann.



Und die Entscheidung, den Datentyp "int" bei 32-Bit zu belassen ist ja nicht aus der Hüfte heraus getroffen worden. Und schon gar nicht von Embarcadero. Wir dürfen dabei nicht vergessen, dass wir mit Delphi für ein Betriebssystem bzw. Framework - hier: Windows - programmieren und gut damit beraten sind, uns dessen Datenmodels zu bedienen. Alles andere würde unnötige Komplikationen mit sich bringen.

Also könnte man auf Microsoft einprügeln - das geht im Allgemeinen ganz gut, man ist ja in Übung. *g* Aber ... auch bei C unter Linux ist der Datentyp "int" 32-Bit. Und bei Mac OS X ebenfalls. Es steht uns natürlich frei, dies weiterhin als skandalös zu empfinden, aber so langsam drängt sich die Frage nach dem "warum" auf.

Als das Thema "64 Bit" akut wurde, lag damit natürlich auch die Frage auf dem Tisch, wie man mit den Datentypen umgehen möge. In der Sprache C beispielsweise ist der Datentyp "int" der Meist-Genutzte. Die Entscheidung, wie mit ihm zu verfahren sei, wollte also wohl überlegt werden.

Was haben sie getan? Die Entwickler von Microsoft und auch die der Unix-Gemeinde haben unabhängig voneinander Analysearbeit betrieben und einfach eine Art Bestandsaufnahme gemacht. Wo wird der Datentyp "int" genutzt und was bringt es jeweils, diesen um weitere 32 Bit zu ergänzen. Alle Beteiligten kamen zu dem Schluss, dass es in der überwiegenden Mehrheit an Fällen eben gerade keinen Vorteil brächte, weitere 32 Bit zu spendieren oder zu vergeuden.

Dies führte zu der bewussten Entscheidung für das Datenmodell "LLP64" (Windows) bzw. "LP64" (Unix / Linux), bei dem der Datentyp "int" eben bei seinen alten 32 Bit verblieb. (Datenmodelle: http://en.wikipedia.org/wiki/64-bit_...it_data_models)

Bei Windows kam noch ein weiterer Aspekt hinzu: Die Interoperabilität von Win32 und Win64. http://blogs.msdn.com/b/oldnewthing/...31/363790.aspx So sind z.B. die Header von Bitmap-Dateien recht klar strukturiert und hätten allesamt neu angepasst werden müssen. Ein Mords-Aufwand für Null Ertrag.

[jaenicke]

Zitat:

Zitat von Daniel (Beitrag 1223927)

So sind z.B. die Header von Bitmap-Dateien recht klar strukturiert und hätten allesamt neu angepasst werden müssen. Ein Mords-Aufwand für Null Ertrag.

Laut der Definition des Integer-Typs vor der Umdefinition durch Embarcadero waren dort ja gar keine Integer-Werte involviert. Das sind dort LongInts usw. (und so steht es auch in der Doku).
Deshalb hätte es dort keinerlei Anpassungsbedarf gegeben.

Dass Integer an vielen Stellen benutzt wurde, wo eigentlich eher ein anderer Typ gepasst hätte, mag ja sein, aber letztlich wurde so die falsche Verwendung statt LongInt nachträglich als korrekt erklärt zu Lasten all derjenigen, die den Typ seiner Definition entsprechend genutzt haben.
Das finde ich nun einmal nicht gut.

Für 32-Bit gab und gibt es LongInt und dessen Name ist ja nicht umsonst entsprechend gewählt worden, eigentlich mit einer klaren Abgrenzung zum Typ Integer, der eine solche Größenangabe gerade nicht enthielt.

Nichtsdestotrotz hilft die nachträgliche Diskussion auch nicht weiter. Diejenigen, die sich an die Dokumentation gehalten haben, müssen ihren Quelltext anpassen, die, die es nicht getan haben, können lachen und weitermachen. Aber das ist nun eben so, ändern lässt es sich nicht mehr.

[Insider2004]

Alles ganz einfach:

1. 64 bit müssen einfach langsamer sein als 32 bit, weil die Pipelines im Prozessor mehr Füllung haben, um das mal so auszudrücken.

2. Floats unter 64 bit sind schneller, weil Delphi da die neuen SSE-Befehle nutzt. In 32 bit wird der uralte FPU-Codegenerator von Turbo Pascal anno 1988 benutzt.

[danielmagin]

In diesem Blog geht es zwar um die Problematik MSSQL 64bit ist teilweise langsamer als 32bit.

Jedoch die Ansatzpunkte sind nicht schlecht (in der zweiten Hälfte).

http://blogs.msdn.com/b/sqlprogramma...edirected=true

[JamesTKirk]

Um mal noch kurz einzustreuen, wie das bei Free Pascal ist:

Da die FPU nur unter Windows 64-Bit als "deprecated" deklariert ist, nicht aber unter Linux, Mac OS X und Co verwenden wir nur unter Win64 per default die SSE Unit (Standard ist hier SSE Version 1) mit maximal Double-Precision, aber unter den anderen x86_64-Systemen verwenden wir weiterhin per Default die FPU mit Extended-Precision. Es gibt übrigens ein Define für den Compiler, welches es erlaubt auch die FPU für Win64 zu verwenden, dieses ist aber standardmäßig deaktiviert (und wahrscheinlich auch nicht wirklich getestet). Dies funktioniert aber deswegen, weil Windows trotzdem die FPU Register sichern muss, damit 32-Bit Anwendungen (welche ja die FPU erwarten) weiterhin korrekt laufen. Die Verwendung von SSE bedeutet aber nicht automatisch, dass der Compiler auch Vectorizing oder ähnliche Späße macht. In dem Zusammenhang wird SSE einfach nicht als SIMD, sondern als SISD (Single Instruction Single Data) verwendet...
Das es manchmal sinnvoll sein kann von SSE auf SSE2 oder SSE3 zu wechseln zeigt dieser Bugreport in dem die Laufzeit eines Algorithmus unter x86_64 von 125ms auf 64ms gedrückt werden konnte (und noch ein paar Millisekunden mehr nach einer weiteren Optimierung).

Ein anderer Fall ist "reine Pascalcode" vs. "Assemblercode". Da hatten wir das Beispiel von

Delphi-Quellcode:

Move

und

Delphi-Quellcode:

FillChar

. Die Einführung von Assemblerroutinen für diese beiden Basisfunktionen hat bei einem Nutzer den Code von etwa 4 Sekunden auf etwa 500ms beschleunigt. :mrgreen:

Nebenbei erwähnt: FPC erlaubt es auch für x86_64 die Verwendung von inline Assembler Abschnitten (es muss also nicht die gesamte Routine Assembler sein). :)

Gruß,
Sven