grundsätzliche Frage zu Multithreading

[Gargamel]

Hi

Die Tage habe ich die Geschwindigkeit von C#, Delphi und C++ getestet. Dazu habe ich in einer 10-Mio.-For-Schleife einen Vektor normalisiert. Dabei kam heraus, dass C# dafür 1,5 Sekunden benötigt. Delphi 0,5 Sekunden und C++ irgendwas um 0,003 Sekunden. Dass C# am langsamsten ist, dachte ich mir fast. Aber der Unterschied zwischen Delphi und C++ ist arg groß. Da ich nun für meine KI jeden Leistungsvorteil nutzen möchte, will ich sämtliche Berechnungen über C++ erledigen, wobei die Verwaltung der KI selbst in Delphi erfolgt.
(Ich mag halt Delphi und will C++ nur dann nutzen, wenn es unbedingt nötig ist)

Der Aufbau sieht so aus: Hauptprogramm(3D-Engine) --> KI(Delphi-DLL) --> reine Berechnungen(C++-DLL)

Was mich nun interessieren würde ist, inwieweit sich das mit Multithreading vereinbaren lässt. In der Delphi-DLL werden, z.B. bei einem Quad-Core, 4 Threads erstellt, die ständig auf exportierte Funktionen der C++-DLL zugreifen (Pathfinding, Fuzzy-Logic, usw.).

Geht das so überhaupt?

Danke

[Der schöne Günther]

Ich sehe jetzt nicht ganz, eine weitere "Zwischen-DLL" überhaupt nötig ist, aber noch eher glaube ich, dass man den generellen Performance-Unterschied jetzt nicht an einer Vektor-Operation festmachen sollte. Ich glaube nicht, dass es so einen argen Unterschied gibt... :oops:

[Neutral General]

Eine weitere Idee um es ggf. in Delphi noch schneller zu kriegen:

1. inline funktion
2. inline assembler (ggf. sogar mit MMX, SSE ?)

Dann sparst du dir den ganzen C++ Kram.

[Medium]

Und wenn man wirklich das letzte Bischen herausquetschen will, wäre CUDA bzw. OpenCL eine prima Sache. Gerade für Aufgaben wie "führe N Mal die gleiche Operation auf Member in einem langen Datenstrom aus". In welcher Sprache man das dann einbettet dürfte auch ziemlich egal werden. Ansonsten stimme ich zu: Es kommt auch stark darauf an, wie man konkret gecoded hat. Delphi ist sicherlich nicht per se langsamer als C++, beide erzeugen ähnlich performanten Maschinencode. Die Frage ist, ob du die Aufgabe in Delphi für Delphi sinnvoll optimiert umgesetzt hast. (Nutzung von SSE via inline asm wäre ein ähnliches Schmankerl wie GPGPU, aber da würde ich eher zu letzterem greifen, wenn man schon was neues lernen muss. Zudem krallt man sich damit dann auch nicht so arg an eine Architektur.)

[Gargamel]

@Günther

Wie gesagt, die reine Verwaltung mache ich lieber in Delphi. Nur den Mathe-Kram würde ich gerne wegen der Geschwindigkeit auslagern.

@General

Inline Assembler kann ich nicht nutzen, da der 64bit-Delphi-Compiler sowas nicht kann. (Delphi XE3)

[Gargamel]

@Medium:

Mit CUDA binde ich mich leider an nVidia. Für ein Spiel ist das nicht sinnvoll. OpenCL hingegen klingt ganz gut.

[Neutral General]

@Gargamel: Soweit ich weiß kannst du zwar keine kompletten inline-Funktionen mit asm - end machen aber du kannst glaube ich sowas machen:

Delphi-Quellcode:

begin
  asm

  end;
end;

? Kann mich aber auch täuschen.

Ansonsten probier mal deine Funktion zum normalisieren von Vektoren mit inline; zu markieren.
Ich denke das sollte wie gesagt auch noch mal etwas bringen.

[Aphton]

Es wäre sowieso kein gültiger Vergleich, wenn beide Algorithmen nicht zu 100% identisch ablaufen. Dh. wenn in C++ geinlinet wird, dann muss in Delphi das auch geschehen und vice versa. Von daher ist es eig. relativ egal.

Ich würde übrigens gerne Code sehen...

[Der schöne Günther]

Das gehört hier wahrscheinlich nicht mehr hin.

Aber gibt es überhaupt Nvidia-Karten mit OpenCL? Ich dachte die bleiben weiterhin bei CUDA. Auch haben Sie das Format geöffnet, vielleicht springt ja sogar ATI auf diesen Zug auf...

[Blup]

Ein Unterschied von 2-5% zwischen den einzelnen Compilern ist durchaus denkbar, deine Ergebnisse mit hundertfacher Laufzeit deuten aber eher auf Fehler in der Implementierung hin.
Assembler ist wirklich nur das letzte Mittel, wenn alle anderen Optimierungen schon durch sind. OpenCL scheint hier der bessere Weg zu sein.

Multithreading und DLL-Aufrufe geht natürlich, sofern die Funktionen in der DLL auch threadsicher implementiert sind oder nur von einem Thread verwendet werden.