Delphi 64 Bit langsamer als 32 Bit

[Delphi-Laie]

Zitat von mkinzler:

In der 64-Bit Implementierung aber auch nur 32Bit.

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.

[Bernhard Geyer]

Zitat von Delphi-Laie:

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 von Smut:

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 von Union:

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.

[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 von Daniel:

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.