Delphi 64 Bit langsamer als 32 Bit

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

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

[Robotiker]

Zitat von JamesTKirk:

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

Sind Anwendungen, wie die des Threaderstellers, eigentlich eine Zielgruppe für Pascal Compiler Entwickler ?

Leute die solche Berechnungen mit Millionen Daten und Millarden Operationen darauf machen, haben ja meist dicke Rechner mit mehreren Prozessoren. (GPUs usw. lassen wir mal ganz außen vor.) Bei den oben erwähnten C++ Lösungen dafür hat man ja heute Libs zum z.B. große Arrays auf CPUs zu partitionieren und hinterher die Teillösungen zusammenzubringen.

Sind die Delphi/Pascal Lösungen dafür Assemblerroutinen und Threads ? Tiling, Loadbalancing usw. alles händisch ? Arbeitet nicht die Zeit gegen solche Lösungen ? Es gibt schliessich immer mehr Kerne auf CPUs, die aber einzeln nicht schneller werden.

[mkinzler]

@Robotiker: Wir befinden uns hier in einem Delphi (also Pascal Forum) und da wunderst Du dich, dass man hier über Delphi diskutiert? Nach Deiner Definition/Sichtweise gibt es natürlich keinen Grund überhaupt auf die Idee zu kommen, etwas nicht mit (Visual) C++ zu lösen zu wollen, da man mit VC++ ja alles besser machen kann als mit irgendeinem anderen Tool.
Native Gemüter (was wir ja aus Deiner Sicht zu sein scheinen) verwenden, aus vielleicht sentimentalen Gründen, "veraltete" Dinge wie Delphi/FPC/Lazarus, ...

Dieser Beitrag habe ich als Mitglied und nichta als Moderator verfasst, das heisst er muss nicht unbedingt der Meinung des Teams entsprechen.

[Robotiker]

Zitat von mkinzler:

Native Gemüter (was wir ja aus Deiner Sicht zu sein scheinen)

Dieser Eindruck entsteht da in der Tat.

Der Fragesteller hat weiter oben festgestellt, dass ihm schon eine kleine Verbesserung des Codes 200 Minuten (!) Verbesserung bringen würden. Ist es bei solchen Dimensionen vermessen mal zu fragen, warum keiner überhaupt mal über das Thema Parallelisierung redet ?

Ich arbeite seit Turbo Pascal 3 mit Pascal, aber bei solchen Aufgaben heute nicht mehr. Aber ich habe Erfahrungen mit solchen Datenmengen.

Geht es hier also darum möglichst schnell solche Berechnungen zu lösen, oder einfach nur darum "ein Programm wie früher" zu schreiben ?

Besteht "native Code Performance" in Delphi heutzutage daraus "stunning multimedia apps" in FireMonkey zu schreiben, über die dann alle ganz "exited" sind ?

Meine Absicht war nicht den Fragesteller zu einer anderen Programmiersprache zu drängen, sondern zu zeigen, was man braucht um auf heutiger Hardware solche Probleme zu lösen. Deswegen meine Frage, ob und wie man sich bei FreePascal dieser Entwicklung stellt. Das solche Frage nicht erwünscht sind, weil man ja auf dem richten Weg ist, habe ich jetzt verstanden.

[mkinzler]

Zitat:

Das solche Frage nicht erwünscht sind, weil man ja auf dem richten Weg ist, habe ich jetzt verstanden.

Darum geht es nicht, sondern um die Tatsache, dass in fast jedem Deiner Beiträge etwas von VC, C++ u.ä. steht.

Zitat:

Ist es bei solchen Dimensionen vermessen mal zu fragen, warum keiner überhaupt mal über das Thema Parallelisierung redet ?

Nein es ging hier aber um 32Bit vs. 64Bit. Parallelisierung sollte unabhängig von der Busbreite ein Thema sein.

Zitat:

Besteht "native Code Performance" in Delphi heutzutage daraus "stunning multimedia apps" in FireMonkey zu schreiben, über die dann alle ganz "exited" sind ?

Nein, ich würde sogar sagen "reines FM2 wäre hierfür nicht meine 1. Wahl.

Zitat:

Meine Absicht war nicht den Fragesteller zu einer anderen Programmiersprache zu drängen, sondern zu zeigen, was man braucht um auf heutiger Hardware solche Probleme zu lösen

Nämlich die Verwendung von Bibliotheken für (V)C++, welche in Delphi/BC++ nicht funktionieren.

[JamesTKirk]

Zitat von Robotiker:

Zitat von JamesTKirk:

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

Sind Anwendungen, wie die des Threaderstellers, eigentlich eine Zielgruppe für Pascal Compiler Entwickler ?

Leute die solche Berechnungen mit Millionen Daten und Millarden Operationen darauf machen, haben ja meist dicke Rechner mit mehreren Prozessoren. (GPUs usw. lassen wir mal ganz außen vor.) Bei den oben erwähnten C++ Lösungen dafür hat man ja heute Libs zum z.B. große Arrays auf CPUs zu partitionieren und hinterher die Teillösungen zusammenzubringen.

Es sehe hier durchaus Anwendungsmöglichkeiten für Pascal Compiler. Aktuell ist FPC und vielleicht auch die Laufzeitbibliothek nicht unbedingt darauf ausgelegt, aber das heißt ja nicht, dass das so bleiben muss. Vor allem bei einem Open Source Projekt, wo jeder was beitragen kann.
Meine Idee ist zum Beispiel die Funktionalität von Vector Pascal in FPC zu integrieren, was eine native Nutzung von SIMD Units ermöglichen würde (FPC unterstützt zwar aktuell SIMD Instructions, wendet die aber nur für einzelne Werte an, also eher als FPU-Ersatz). Dann müssten auch noch ein paar Optimierungen her wie Auto Vectorizing oder sonstige Nettigkeiten, wie sie LLVM zur Zeit bekommt. Vielleicht auch ein paar Threading Erweiterungen wie sie Oxygene kennt (z. B. parallel for ).

Zitat von Robotiker:

Sind die Delphi/Pascal Lösungen dafür Assemblerroutinen und Threads ? Tiling, Loadbalancing usw. alles händisch ? Arbeitet nicht die Zeit gegen solche Lösungen ? Es gibt schliessich immer mehr Kerne auf CPUs, die aber einzeln nicht schneller werden.

Meine Anmerkung mit Assembler betraf zwei Grundroutinen, die sehr häufig implizit aufgerufen werden. Wenn die nicht schnell sind, dann bringt dir auch die ganze sonstige Optimiererei nicht allzu viel. Und auch wenn natürlich der Compiler auch entsprechend optimieren können muss gibt es hier und da Routinen wo es besser ist, wenn man von Hand ne Assemblerroutine schreibt (eben zum Beispiel diese beiden besagten Routinen FillChar und Move ), da hierdurch Prozessorbefehle verwendet werden können, die der Compiler normalerweise nicht verwendet (ein Compiler reizt das Instruction Set eines Prozessors normal nie voll aus).
Was aktuell (zumindest so weit ich das Überblicke) allerdings tatsächlich noch fehlt sind Frameworks (ich nenn es mal einfach so), die einem das Arbeiten mit und Verwalten von vielen Threads abnehmen (du magst das nennen wie du willst, aber von der OS Perspektive her sind es am Ende immer noch Threads, die da parallel laufen).

Gruß,
Sven

[jaenicke]

Zitat von JamesTKirk:

Was aktuell (zumindest so weit ich das Überblicke) allerdings tatsächlich noch fehlt sind Frameworks (ich nenn es mal einfach so), die einem das Arbeiten mit und Verwalten von vielen Threads abnehmen

Wobei die OmniThreadLibrary dabei durchaus einiges an Arbeit abnimmt. Ob die auch für solche massiven Berechnungen sinnvoll nutzbar ist, kann ich nicht sagen, dafür kenne ich beides zu wenig.

[Robotiker]

Zitat von jaenicke:

Wobei die OmniThreadLibrary dabei durchaus einiges an Arbeit abnimmt. Ob die auch für solche massiven Berechnungen sinnvoll nutzbar ist, kann ich nicht sagen, dafür kenne ich beides zu wenig.

Ja, das legt zumindest den nächsten Level, man hat nicht mehr nur TThread.

Aber so was wäre schön (einfach die Diagramme anschauen, den Code ignorieren):
http://www.parallel-universe-online....123-flow-graph

[Edit]
Sollte aber eigentlich mit dem neuen Compiler im Builder irgendwann verwendbar sein.