Delphi 64 Bit langsamer als 32 Bit

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

[Robotiker]

Zitat von mkinzler:

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

Diese Aussage erstaunt mich jetzt. Hat man den neuen Compiler im BCB nicht eingeführt, damit man Libs wie die Threading Collections und TBB (beide übrigens von Intel) verwenden kann ?

Hat nicht JT von Embarcadero einen Blogeintrag darüber geschrieben, dass man das MS Rest SDK im BCB integriert, da ist die PPLx enthalten, die Cross-Plattform Opensource Variante der PPL aus VC.

Ich hatte eigentlich durchaus den Eindruck, dass es hier Leute gibt, die professionelle leistungsfähige Software erstellen. Die auch mal eine Blick über den Tellerrand wagen, sei es auch nur um sich Ideen für die Entwicklung in Delphi zu holen.

Vom Fragesteller hatte ich schon den Eindruck, dass er sich ernsthaft mit der Materie auseinandersetzt. Ist da ein Link auf ein Video zu MS, wo gezeigt wird, wie man Schleifen cachegünstig optimiert, schlecht, weil es von MS kommt ? Hat das nicht zumindest indirekt mit dem 32/64 Bit Thema zu tun ? (Ganz sicher aber mit dem Problem des Fragestellers.) Gibt es auch nur ansatzweise ähnliche Doku bei Embarcadero, dann verweise ich gerne drauf ?

[Der schöne Günther]

Das Thema war so angenehm zu lesen, eine wahrer Leuchtturm in den tosenden Böen des Internets. Jetzt nicht mehr.

Was hat das jetzt noch mit der ursprünglichen Frage am Hut?

[Patito]

Um das ganze wieder mehr relevant für Pascal zu machen hätte ich da die Frage wie es denn mit der Verwendung der GPU
in Pascal aussieht?

Vermutlich ist da ein Hybrid aus solider Pascal-GUI und einem Number-Cruncher in C for CUDA sinnvoll.

[pertzschc]

Zitat von Der schöne Günther:

Das Thema war so angenehm zu lesen, eine wahrer Leuchtturm in den tosenden Böen des Internets. Jetzt nicht mehr.

Recht hast Du - seit Monaten mal wieder ein fesselnder Thread!

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