Delphi 64 Bit langsamer als 32 Bit

[jaenicke]

Zitat von Perlsau:

Kann man das so interpretieren, daß eine 64-Bit-Anwendung, wenn man int64 statt Integer einsetzt, schneller wird?

Es ist so oder so ein Assemblerbefehl, ob man das halbe 64-Bit Register ausliest oder das ganze. Bei 64-Bit Werten ist es allerdings ein Assemblerbefehl mehr als mit Integer was z.B. bei einer Addition herauskommt.
Integer unter 64-Bit: der erste Wert wird aus dem Stack in ein Register geladen und der zweite mit add direkt aus dem Stack hinzuaddiert
Int64 uner 64-Bit: beide Werte werden aus dem Stack in Register geladen und dann addiert

Insgesamt generiert der 64-Bit Compiler eher mehr Assemblerbefehle als der 32-Bit Compiler. Was aber wirklich die Performance reduziert, ist, dass die aktuellen Planungen dazu führen, dass eher reines Object Pascal benutzt wird. Das heißt wo es für 32-Bit assembleroptimierte Routinen gab, ist das für 64-Bit in der Regel nicht mehr so, insbesondere bei Stringroutinen. Das kostet allerdings selbst bei Benchmark oft nur wenige Prozentpunkte, so viel langsamer ist das meistens nicht.
Schneller ist man bei 64-Bit, wenn es um viele Fließkommaoperationen geht. Solche Berechnungen sind durch die Multimedia-Befehle der CPU deutlich schneller.

Dass 64-Bit oft langsamer ist, ist aber nicht nur bei Delphi so, das sieht man auch bei Java oder C++ z.B., aber der Irrglaube, dass man unbedingt 64-Bit braucht und da alles besser ist, hält sich leider (auch bei manchen hier im Forum) hartnäckig. In der Realität ist es für den Großteil der Projekte aber eher ein Nachteil.

[Perlsau]

Zitat von jaenicke:

[Es ist so oder so ein Assemblerbefehl, ob man das halbe 64-Bit Register ausliest oder das ganze. Bei 64-Bit Werten ist es allerdings ein Assemblerbefehl mehr als mit Integer was z.B. bei einer Addition herauskommt.
Integer unter 64-Bit: der erste Wert wird aus dem Stack in ein Register geladen und der zweite mit add direkt aus dem Stack hinzuaddiert
Int64 uner 64-Bit: beide Werte werden aus dem Stack in Register geladen und dann addiert
Insgesamt generiert der 64-Bit Compiler eher mehr Assemblerbefehle als der 32-Bit Compiler. Was aber wirklich die Performance reduziert, ist, dass die aktuellen Planungen dazu führen, dass eher reines Object Pascal benutzt wird. Das heißt wo es für 32-Bit assembleroptimierte Routinen gab, ist das für 64-Bit in der Regel nicht mehr so, insbesondere bei Stringroutinen. Das kostet allerdings selbst bei Benchmark oft nur wenige Prozentpunkte, so viel langsamer ist das meistens nicht.
Schneller ist man bei 64-Bit, wenn es um viele Fließkommaoperationen geht. Solche Berechnungen sind durch die Multimedia-Befehle der CPU deutlich schneller.

Vielen Dank, Jaenicke, das war mal wieder sehr informativ ... wie man das halt von dir gewohnt ist

Zitat von jaenicke:

Dass 64-Bit oft langsamer ist, ist aber nicht nur bei Delphi so, das sieht man auch bei Java oder C++ z.B., aber der Irrglaube, dass man unbedingt 64-Bit braucht und da alles besser ist, hält sich leider (auch bei manchen hier im Forum) hartnäckig. In der Realität ist es für den Großteil der Projekte aber eher ein Nachteil.

Genau deshalb wollte ich das wissen. Ich fürchte nämlich, dieser Irrglaube wurde von den Reklamefritzen bewußt in die Welt gesetzt, um den Absatz von 64-Bit-Hard- und Software anzukurbeln. Dabei gibt es bei den herkömmlichen PCs ganz andere "Nadelöhre", an die man sich aber um der heiligen Kompatibilität willen nicht herantraut ...

Vielleicht erinnerst du dich noch: Ich hatte mal vor einiger Zeit einen Test gemacht mit Delphi XE2, und zwar ging es da um das Ausführen von Locate-Befehlen und setzen von IndexFieldNames beim Start einer Anwendung. Da waren die 64-Bit-Kompilationen größtenteils schneller als die 32-bittigen (Angaben im ms):

Testreihe mit Sortierung und Lokalisierung beim Start

*** Debug 32 IDE **********
DatMod.Verbinden_Tabellen 50
Set_Einstellungen 27790

*** Release 32 IDE **********
DatMod.Verbinden_Tabellen 48
Set_Einstellungen 27967

*** Debug 64 IDE **********
DatMod.Verbinden_Tabellen 47
Set_Einstellungen 24026

*** Release 64 IDE **********
DatMod.Verbinden_Tabellen 47
Set_Einstellungen 24489

*** Debug 32 EXE **********
DatMod.Verbinden_Tabellen 46
Set_Einstellungen 23111

*** Release 32 EXE **********
DatMod.Verbinden_Tabellen 49
Set_Einstellungen 22823

*** Debug 64 EXE **********
DatMod.Verbinden_Tabellen 46
Set_Einstellungen 19745

*** Release 64 EXE **********
DatMod.Verbinden_Tabellen 45
Set_Einstellungen 20034

Getestet wurde die Zeit, die zum Verbinden mehrerer Tabellen benötigt wird (MyQuery.Open), wenn IndexFieldNames einen Wert hat und im select ein Order-Befehl steht. Wieso das bei den 64-Bit-Versionen schneller war, weiß ich nicht. Fließkommaberechnungen finden dabei ja wohl kaum statt. Oder etwa doch?

[Patito]

Zitat von jaenicke:

Schneller ist man bei 64-Bit, wenn es um viele Fließkommaoperationen geht. Solche Berechnungen sind durch die Multimedia-Befehle der CPU deutlich schneller.

Naja, ob es wirklich daran liegt? Zitat aus dem Embarcadero Wiki:
"In Win64, the precision of floating-point computations was reduced from extended (10-byte values) to double (8-byte values)."

[Sir Rufo]

Zitat von Perlsau:

Zitat von Sir Rufo:

System.Integer ist immer 32bit (x32,x64)
Was du meinst/suchst ist System.NativeInt

Kann man das so interpretieren, daß eine 64-Bit-Anwendung, wenn man int64 statt Integer einsetzt, schneller wird?

Das war hier nicht Kern der Aussage. Der TE hat Integer verwendet, weil er glaubte, dadurch je nach Platform einen 32bit bzw. 64bit Integer zu haben.

[Namenloser]

Mit den Registern sollte es nichts zu tun haben, die sind unter einer 64Bit-CPU immer 64Bit breit und werden im 32Bit-Modus einfach nur zur Hälfte genutzt.

Ich vermute eher, dass es am Cache liegt: Unter 64Bit sind viele Datentypen doppelt so groß wie unter 32Bit, aber der Cache der CPU ist in beiden Modi gleich groß → unter 64Bit passt weniger in den Cache → mehr Cache-Faults.

[gammatester]

Zitat von NamenLozer:

Mit den Registern sollte es nichts zu tun haben, die sind unter einer 64Bit-CPU immer 64Bit breit und werden im 32Bit-Modus einfach nur zur Hälfte genutzt.

Es könnte auch an Registern liegen, wenn viel multipliziert wird. Das Produkt von zwei 32-Bit-Integern hat halt nicht mehr als 64-Bit, das von zwei 64-Bit-Integern schon. Vielleicht sieht man ja am erzeugten Code mehr.

[BUG]

Zitat von Sir Rufo:

System.Integer ist immer 32bit (x32,x64)

Aber Pointer/Objektreferenzen sind jetzt 64 Bit lang; wenn man viele Klassen/Referenzen (z.B. in Baumstrukturen) benutzt, führt dass zu einem bis zu doppelt so hohem Speicherverbrauch, was das Programm ausbremsen kann.
Ich nehme aber an, dass in deiner numerischen Berechnung nicht so viele Zeiger/Objekte benutzt werden.

[Union]

Ich würde das mal profilen, runter bis zur RTL. Erst dann kann man eine konkrete Aussage treffen woran es liegt. Alles andere ist geraten.

[Robotiker]

Hallo,

Zitat von BigAl:

Als 32-Bit benötigt der Diskretisierungsvorgang ca. 24,58 Sekunden. Als 64-Bit Anwendung werden ca. 28,21 Sekunden benötigt (absolut reproduzierbar). Das klingt jetzt nicht nach viel, aber die Objekte werden später wesentlich komplexer und umfangreicher, was die benötigte Zeit vervielfacht...

Bei Berechnungen dieser Größe kann man nur wirklich was herausholen, wenn man sie auf mehrere Kerne verteilt. Um das automatisch zu machen, hat der Delphi Compiler nicht wirklich viel zu bieten.

Beim Intel C++ Compiler und bei VC++ gibt es Autovektorisierung und -parallelisierung.
http://en.wikipedia.org/wiki/Automat...ion#Techniques
http://msdn.microsoft.com/de-de/library/hh872235.aspx

Dann gibt es noch entsprechende Bibliotheken, bei Intel die Threading Collections und TBB, bei MS die PPL. Hier ein lesenswertes EBook dazu:
http://msdn.microsoft.com/en-us/library/gg675934.aspx

Das skaliert, auch wegen des Caches, nicht mit der Anzahl der Kerne, aber z.B. ein Faktor 3-4 bei einem 8-Kern-Prozessor gegenüber einer Single-Thread-Lösung sind üblich.

Was auch noch helfen kann, wäre Profile Guided Optimization, das haben diverse C++ Compiler.
http://blogs.msdn.com/b/vcblog/archi...ation-pgo.aspx

[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.