Delphi 64 Bit langsamer als 32 Bit

[jobo]

Zitat von BigAl:

Hat irgendjemand eine Idee, warum die 64 Bit Anwendungen langsamer sind als die 32 Bit Anwendungen?

Auch wenn es um ein sehr spezifisches Problem (Routine/Integer) geht, ich wunder mich etwas über die Diskussion.
Ich selbst bin nie in die Verlegenheit gekommen, an der Stelle um Millisekunden kämpfen zu müssen, aber ich dachte, es sei allgemein bekannt, dass 64 bit Compiler bei weitem nicht so ausgereift sind, wie 32-bit compiler.
Konkret habe ich da Aussagen zu IE64 versus 32 von MS himself im Kopf. Sie geben nicht nur unumwunden zu, dass die 64bit Version langsamer ist, sie sagen gleich dazu, dass es keine Tuning Maßnahmen geben wird.
Eine Quelle dazu kenne ich leider nicht.

Unabhängig vom Optimierungsgrad des Compilers:
Theoretisch kann ein System, das größere Datenmengen (hier größere Zahlen) in einem Befehl verarbeiten kann, diesen Vorteil erst ausspielen, wenn tatsächlich Zahlen verarbeitet werden, die größer sind, als das Vergleichsystem in "einer Operation" beherrscht. Das kleinere System müsste diese Ops ja in mehrere Schritte splitten.
Das Float-Beispiel von Jaenicke passt da ganz gut ins Bild.

Für Performancevergleiche im Bereich CPU finde ich nebenbei gesagt noch die Tests mittels Datenbank realtiv unglücklich. Eine DB ist mit dem Festplattenzugriff um Faktoren langsamer als die CPU. Sortieroperation drehen sich da bspw. eigentlich nur um die Frage, ob sie klein genug fürs RAM sind oder auf der Festplatte vorgenommen werden müssen. Erst wenn man auf der gesamten Strecke von der Festplattenblockgröße, über Treiber bis in die DB Zugriffsroutinen optimierten 64 bit Code hat, kann man sich vermutlich wirklich über ein 64bit (Datenbank-)System freuen.

Eine naheliegende Optimierung hat Robotiker ja gerade genannt. Ich glaube Intel treibt da einen relativ großen Aufwand, um seine Mehrkern Optimierungen "an den Mann" zu bringen.

[Robotiker]

Zitat von jobo:

Konkret habe ich da Aussagen zu IE64 versus 32 von MS himself im Kopf. Sie geben nicht nur unumwunden zu, dass die 64bit Version langsamer ist, sie sagen gleich dazu, dass es keine Tuning Maßnahmen geben wird.
Eine Quelle dazu kenne ich leider nicht.

Na, dann fangen wir mal mit dieser an, gleich noch mit einem Vergleich zu C#
http://www.codeproject.com/Articles/...-Csharp-vs-NET
Die 32- und 64-Bit VC++ Compiler nehmen sich nicht viel bei der Optimierung.

[jobo]

Zitat von Robotiker:

Na, dann fangen wir mal mit dieser an, gleich noch mit einem Vergleich zu C#
Die 32- und 64-Bit VC++ Compiler nehmen sich nicht viel bei der Optimierung.

Interessant! Ich hab's erstmal überflogen. Vielleicht vertiefe ich mein Halbwissen bald noch weiter

1. Wie weit sind solche number crunching Geschichten übertragbar auf ein "komplexes" Programm (IE, usw), meinetwegen eingeschränkt auf CPU/Grafik?
2. Berücksichtigen solche Tests eine potentiell höhere "Payload" eines 64 bit Systems?
3. Die Testergebnisse überraschen mich auf den ersten Blick nicht so sehr.

2 kleine Beispiele
Nehme ich einen 4 bit microcontroller und lasse in im Zahlenraum 1 bis 16 addieren ist er mit Sicherheit genauso schnell wie ein "baugleicher" 8 bit microcontroller mit der gleichen Aufgabe. Compileroptimierung ist hier nicht möglich.
Nehme ich einen herkömmlichen Großraum LKW und einen neuen Mega Trailer (oder wie die heißen), packe sie mit der gleichen Menge Styroporblöcken voll, werden sie auf gleicher Strecke, mit gleicher Ladung die gleiche Zeit benötigen und damit die gleiche Leistung bringen. Der große LKW war im Test dann allerdings nur halbvoll.

Die verlinkten Tests sind sicher recht nahe an der spezifischen Situation des TE, andererseits wird hier im Thread allgemein von 64bit Compilern geschrieben. Äpfel und Birnen..?

[mkinzler]

AMD64 aka IA32_64 aka EMT unterscheiden sich von IA32 aber um mehr als die Breite des Buses der Register.
Unter 64Bit gibt es (wie schon kurz erwähnt) keine FPU mehr, es gibt "nur" noch die Entsprechenden Vektorerweiterungen ( SSE, AVX, ...), die aber grundsätzlich mächtiger sind; es kann aber u.U. Optimierung des Codes notwendig sein.
Zudem ist der 64Bit Delphi-Compiler eine Neuentwicklung (basiert nicht auf dem 32-Bit-Compiler), was bei VC nicht so sein wird. Zudem belegen 64-Bit Programme mehr Speichern. Beim Kopieren von Speicherbereichen muss u.U. auch mehr kopiert werden. Es wird eine andere RTL, VCL und andere Funktionen der Windows-API verwendet.

[mentaltec]

Hi,

gibt es dafür

Zitat von mkinzler:

Unter 64Bit gibt es (wie schon kurz erwähnt) keine FPU mehr

einen Beleg?
ich persönlich glaube :: wer ein A20 Gate bis zur 48 bit Adressierung durchschleppt, kappt keine noch so crazy FPU.

evtl. ist es ja nur eine Empfehlung für zukünftige Entwicklungen

mfg

[Patito]

Zitat von mentaltec:

gibt es dafür

Zitat von mkinzler:

Unter 64Bit gibt es (wie schon kurz erwähnt) keine FPU mehr

einen Beleg?
ich persönlich glaube :: wer ein A20 Gate bis zur 48 bit Adressierung durchschleppt, kappt keine noch so crazy FPU.

evtl. ist es ja nur eine Empfehlung für zukünftige Entwicklungen

mfg

Also in der Hardware ist es wohl noch drin. Die Unterstützung von Microsoft aus
war wohl ein wenig am wackeln.

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

"In 64-bit versions of Windows, the operating system preserves the MMX/x87 registers across thread (and process) switches. However, there is no explicit calling convention for the MMX/x87 registers. Code that is produced by the 64-bit compiler for x64 processors does not use these registers and does not preserve them across function calls."

Technisch könnte der Delphi-Compiler vermutlich weiter die alte FPU-Präzision behalten.

Ich interpretiere dieses "does not preserve them across function calls." jetzt mal so,
dass die Gefahr besteht, dass ein Aufruf einer Microsoft C++ dll eventuell den FPU-Status zerschießt.

[OlafSt]

Nicht ganz "does not use" sagt aus, dsa keine MMX/x87-Register benutzt werden. Daher ist es reine Zeitverschwendung, die MMX/x87-Register zu sichern, ergo "does not preserve". Die FPU-Register bleiben also völlig unangetastet.

[Amateurprofi]

Zitat von mkinzler:

AMD64 aka IA32_64 aka EMT unterscheiden sich von IA32 aber um mehr als die Breite des Buses der Register.
Unter 64Bit gibt es (wie schon kurz erwähnt) keine FPU mehr, es gibt "nur" noch die Entsprechenden Vektorerweiterungen ( SSE, AVX, ...), die aber grundsätzlich mächtiger sind; es kann aber u.U. Optimierung des Codes notwendig sein.
Zudem ist der 64Bit Delphi-Compiler eine Neuentwicklung (basiert nicht auf dem 32-Bit-Compiler), was bei VC nicht so sein wird. Zudem belegen 64-Bit Programme mehr Speichern. Beim Kopieren von Speicherbereichen muss u.U. auch mehr kopiert werden. Es wird eine andere RTL, VCL und andere Funktionen der Windows-API verwendet.

Na klar gibt es die noch!
Sie wird nur von Delphi nicht mehr benutzt.
Man kann sie aber mit ASM-Prozeduren weiterhin nutzen.

[mkinzler]

Das mag für die aktuellen Prozessoren gelten, aber ich würde mich nicht darauf verlassen

Zitat von http://support.amd.com/us/Processor_TechDocs/26569_APM_v5.pdf:

The x87 instructions can be used in legacy mode or
long mode. Their use in long mode is available if
the following feature bit is set:
•
Long Mode, as indicated by CPUID Fn8000_0001_EDX[LM] = 1.

[Robotiker]

[QUOTE=jobo;1223793]

Zitat von Robotiker:

1. Wie weit sind solche number crunching Geschichten übertragbar auf ein "komplexes" Programm (IE, usw), meinetwegen eingeschränkt auf CPU/Grafik?

Das ist wirklich schwer zu sagen, "komplexe Programme" sind alle sehr unterschiedlich.

Vielleicht mal ein konkretes Beispiel
http://www.innovmetric.com/polyworks...d.aspx?lang=en
Das ist in VC++ geschrieben, es gibt eine 32- und 64-Bit Version. Man braucht die 64-Bit Version schon, wegen der großen Datenmenge, deshalb verwendet man selten auf Rechnern mit 64-Bit Betriebssystem noch die 32-Bit Variante. Ob die dann noch etwas schneller wäre, müsste man mal testen, gefühlt ist sie es nicht.


Ansonsten kann ich von einigen eigenen Libs berichten, die sich mit dem C++ Builder, VC++ und Intel C++ übersetzen lassen, alles 32 Bit.

Derselbe Code mit VC++ oder Intel übersetzt ist schon mal deutlich (30 - 70 %) schneller, als mit dem zugegeben uralten 32-Bit Borland Compiler (in XE2, was neueres habe ich nicht).

Bei wirklich numeriklastigen Sachen ist Intel schneller als MS, aber bei anderen Dingen können kann auch MS vorne liegen oder beide gleichauf. Da der Intel Compiler unter Windows quasi ein Zusatzpaket zu Visual Studio ist, lohnt er sich meist nur, wenn man einen "Nachbrenner" braucht, wenn VC++ nicht mehr hergibt. Das ist bei uns aber eher selten der Fall.