Delphi 64 Bit langsamer als 32 Bit

[JamesTKirk]

Zitat:

Zitat von Robotiker (Beitrag 1223980)

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.

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.

Delphi-Quellcode:

parallel for

).

Zitat:

Zitat von Robotiker (Beitrag 1223980)

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

Delphi-Quellcode:

FillChar

und

Delphi-Quellcode:

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:

Zitat von JamesTKirk (Beitrag 1224101)

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:

Zitat von JamesTKirk (Beitrag 1224101)

Es sehe hier durchaus Anwendungsmöglichkeiten für Pascal Compiler.

Vielen Dank dafür, dass Du geantwortet hast.

In diese Richtung zielte ja meine Frage. Warum sollte man es nicht in Pascal machen können, wenn man es z.B. in Matlab hinkriegt. Gerade für solche mathematischen Sachen ist die Pascal-Syntax doch sehr lesbar.

Im Grunde geht es ja nur darum, die Fähigkeiten aktueller Hardware auszunutzen. Diese riesigen Datenstrukturen des Threaderstellers kann man am besten bearbeiten, wenn man vorgeht, wie wenn man mit vielen Mähdreschern ein großes Kornfeld mäht. Man stellt alle in eine Reihe und fährt drüber, zusätzlich macht die Vektorisierung quasi jeden Mähdrescher breiter. Sowas kann man in Delphi derzeit nicht wirklich gut ausdrücken, und nur darum ging es mir.

Es geht schliesslich darum, dass Berechnungen statt Stunden möglicherweise nur Minuten dauern. Statt zu sagen, "Oh, da haben wir ein Defizit" zu sagen "wir machen das aus sentimentalen Gründen" finde ich, bestenfalls, besorgniserregend. Aber so scheinen die Leute heute eingestellt zu sein, die bei Delphi geblieben sind. Schade.

[Edit]
Ja, Vector Pascal geht offensichtlich in die Richtung, die ich meine.

[Robotiker]

Zitat:

Zitat von jaenicke (Beitrag 1224103)

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.

[JamesTKirk]

Zitat:

Zitat von jaenicke (Beitrag 1224103)

Zitat:

Zitat von JamesTKirk (Beitrag 1224101)

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.

Ne Portierung der OmniThreadLibrary für FPC wäre auch mal was...

Zitat:

Zitat von Robotiker (Beitrag 1224106)

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

Sowas in Pascal zu implementieren wäre durchaus auch mal interessant. :)

So viele schöne Projekte, die man angehen könnte und so wenig Zeit... *seufz*

Gruß,
Sven

[mkinzler]

Klingt wie Concurrent Pascal oder SuperPascal.
Eine entsprechende Erweiterung für Delphi FPC wäre sicherlich nicht schlecht.

[Insider2004]

Generelle Überlegung: 16 bit ist schneller als 32 bit, 32 bit ist schneller als 64 bit. Trotzdem wurde nach 16 bit 32 bit eingeführt. Vorteil: Der Scrollbalken hat bei längeren Seiten kein Range-error ausgelöst. Und man konnte mehr Speicher adressieren. Alles hat Vor- und Nachteile. Es gibt ein paar Themen in der Mathematik, da sind 32 bit der reine Horror. Von daher kann 64 bit oder noch besser 128 bit nicht schnell genug kommen. Auch wenn 128 bit für 99% aller Computerbenutzer Perlen vor die Säue wäre.

[Sherlock]

Zitat:

Zitat von Insider2004 (Beitrag 1224254)

Auch wenn 128 bit für 99% aller Computerbenutzer Perlen vor die Säue wäre.

IMHO laufen doch GPUs mit 128 Bit...insofern sind alle Gamer total begeistert davon, und die machen mehr als 1% der Computernutzer aus ;)

Aber das nur als Zwischenruf...

Sherlock

[Bernhard Geyer]

Zitat:

Zitat von Sherlock (Beitrag 1224410)

IMHO laufen doch GPUs mit 128 Bit...insofern sind alle Gamer total begeistert davon,

Das ist aber die Busbreite Speicherinterface und nicht die Anzahl der Bits die für die Adressierung verwendet wird.
Und über eine 128 Bit Grafikkarte gähnen alle Hardcoregamer da die besseren Grafikkarten schon bei 384 Bit angekommen sind

[mentaltec]

ts ts ts

was man alles durcheinanderwürfeln kann - Operandenbreite CPU, Operandenbreite SIMD (hier auch gern über alle Operanden), Adressbreite logisch ,Adressbreite physisch implementiert, Datenbusbreite intern, Datenbusbreite extern ...