Delphi 64 Bit langsamer als 32 Bit

[BigAl]

Hallo,

ich bin gerade am Schreiben einer sehr umfangreichen Anwendung. Im Zuge von diversen Optimierungen habe ich einige Messungen durchgeführt. Leider fällt mir immer wieder auf, dass die 32 Bit Variante schneller ist als die 64 Bit Variante. Bei den von mir eingesetzten Typen handelt es sich im Normalfall immer um klassische "Integer" etc. Diese sollten ja den nativen Type der Umgebung entsprechen.

Ein Beispiel: Ich diskretisiere Objekte für eine finite Elemente Simulation. Ein Testobjekt mit 36 Kanten wird auf ca. 270.000 Kanten diskretisiert. Hierbei werden sehr viele Berechnungen durchgeführt (Matrizen, Volumen, Längen, Flächen etc.), aber auch sehr viele Indexoperationen mit dynamischen Arrays (array of Integer). 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...

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

Viele Grüße

Alex

[Der schöne Günther]

Ich würde sagen weil die Register in deiner CPU nicht größer geworden sind. Webbrowser sind (glaube ich) bis heute größtenteils immer noch 32 Bit, da es sich einfach nicht lohnt bzw. sogar eben langsamer wird.

[jfheins]

Zitat:

Bei den von mir eingesetzten Typen handelt es sich im Normalfall immer um klassische "Integer" etc. Diese sollten ja den nativen Type der Umgebung entsprechen.

Integer sind eigentlich immer 32bit groß. Von 16 auf 32 bit wurden sie noch erweitert, danach sah man da keinen Sinn mehr drin.

[Sir Rufo]

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

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

Zitat von NamenLozer (Beitrag 1223727)

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:

Zitat von Sir Rufo (Beitrag 1223726)

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.

[Perlsau]

Zitat:

Zitat von Sir Rufo (Beitrag 1223726)

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?

[Namenloser]

Zitat:

Zitat von Perlsau (Beitrag 1223772)

Zitat:

Zitat von Sir Rufo (Beitrag 1223726)

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?

Ist nicht zu erwarten, nein. Nach dem Thread hier zu urteilen wird es eher langsamer.