grundsätzliche Frage zu Multithreading

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

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

[Gargamel]

Zitat:

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

Wobei mich ja genau das interessiert. Die Funktion in C/C++ sieht so aus:

Delphi-Quellcode:

__declspec(dllexport) int calcCPP(void)
{
   int sum = 0;
   for (int i = 0; i < (100000000 - 1); i++)
        {
            float vecX = 5.7458F;
            float vecY = 3.758F;
            float vecZ = 7.12544F;

            float len = sqrt(vecX*vecX+vecY*vecY+vecZ*vecZ);

            float normX = vecX / len;
            float normY = vecY / len;
            float normZ = vecZ / len;

         sum+=1;
        }
   return sum;
}

[Neutral General]

Und in Delphi?

[Robotiker]

Zitat von Blup:

Ein Unterschied von 2-5% zwischen den einzelnen Compilern ist durchaus denkbar,

Der Unterschied zwischen den (32 Bit-) Compilern vom C++ Builder und Visual C++ ist durchaus größer als 2-5%, eher manchmal 20-50% bei gleichem Code.

Zitat von Neutral General:

Wo spart C++ denn da über die Hälfte der Zeit?

Von welchem Compiler reden wir eigentlich ?
Schlägt da ein Vektorisierer zu, wie bei Microsoft oder Intel ?
http://msdn.microsoft.com/de-de/library/hh872235.aspx