Delphi 64 Bit langsamer als 32 Bit

[Robotiker]

Zitat:

Zitat von JamesTKirk (Beitrag 1223975)

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:

Zitat von mkinzler (Beitrag 1223988)

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:

Zitat von mkinzler (Beitrag 1223992)

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.

[Robotiker]

Zitat:

Zitat von Patito (Beitrag 1224004)

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

Möglicherweise. Soweit wollte ich gar nicht gehen. Rechnen auf der GPU ist gut, wenn viele Tasks unabhängig laufen können (separate Daten) und nicht so viel Datenaustausch zwischen CPU und GPU anfällt.

Auch in Pascal hängt die ganze 32/64 Bit Geschichte und eine mögliche Parallelisierung über die Cache-Problematik zusammen. Der 64-Bit Code ist ggf. größer, passt schlechter in den Cache. Noch schwieriger ist es bei Parallelisierung, wie in dem Video gezeigt, man muss möglichst viele "heiße" Daten beieinander halten. Ganz blöd wäre es, wenn man das ganze als Single Thread Lösung implementiert und dann mehrere Programme mit unterschiedlichen Daten parallel startet "um den Rechner besser auszulasten", die klauen sich dann gegenseitig Cache Kapazität.

Die Kunst besteht darin eine Balance zischen Parallelisierung und Speicherdurchsatz zu finden, das eventuell auch skalierbar auf unterschiedlich großen PCs. Dazu muss man nicht umbedingt die zitieren Libs verwenden, aber da steckt viel Know-How drin, und in der Doku ist viel darüber geschrieben, wie man Probleme effizient aufteilt.

[pertzschc]

Zitat:

Zitat von Der schöne Günther (Beitrag 1223999)

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!

[BUG]

Zitat:

Zitat von Insider2004 (Beitrag 1223956)

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.

Hä :gruebel:

Ich weiß nicht, wie die Bitbreite der Register die Pipeline beeinflussen sollten.
Außerdem: Volle Pipeline, gute Pipeline :mrgreen: