Warum ist das Multithreading so langsam?

[EWeiss]

OT:
Unfein ist auf jedenfall schon mal
das du mehrere threads erstellst diese anschließend schließt
ohne vorher geprüft zu haben ob die Handles überhaupt existieren.

gruss

[Namenloser]

Delphi-Quellcode:

         WaitForSingleObject(Thread1, INFINITE);
         WaitForSingleObject(Thread2, INFINITE);

könntest du zumindest schon mal ersetzen durch WaitForMultipleObjects.

Desweiteren würde ich schauen, nicht für jede „Ebene“ 2 neue Threads anzulegen, sondern z.B. nur, wenn die Anzahl der Elemente eine bestimmte Schwelle überschreitet. Im Prinzip müsstest du einen Dualcore sogar schon ausreizen können, wenn du nur die aller erste „Ebene“ aufsplittest (einen Quadcore respektive mit den ersten zwei Ebenen).

Das Erzeugen und Verwalten von Threads bedeutet einen nicht zu unterschätzenden Overhead. Wahrscheinlich ist dein Programm deshalb so langsan. Es gibt/gab sogar mal eine Richtlinie, dass ein Prozess nicht mehr als 16 Threads haben sollte – ob das noch aktuell ist, weiß ich nicht. Aber man sollte jedenfalls nicht übertreiben.

[blablab]

Da ich nur einen DualCore habe benutze ich nur 2 Threads (abgesehen vom 1. Thread der immer gestartet wird). Die Schwelle werde ich noch einbauen, sobald der Code funktioniert. Bis dahin arbeite ich mit genügend großen Arrays, bei denen sich das aufsplitten eigentlich lohnen sollte.
Und WaitForMultipleObjects werde ich gleich mal ausprobieren

[Blup]

Zitat von blablab:

Da PArr und len angepasst werden, sollten sich die einzelnen Threads also nicht in die Quere kommen...

Zumindest liegt das Array in einem zusammenhängenden Speicherbereich, wenn ein Prozessor dort etwas ändert und der andere auf Daten zugreifen will, die im selben Adressegment des eigenen Cache liegen, hat er erst einmal Pause.

Versuchsweise könnte jeder Thread eine Kopie des zu sortierenden Teilarray erstellen, diese Kopie sortieren und zum Schluss zurückschreiben. Allerdings müsste man sicherstellen, das jede Kopie aus Sicht des Cache in einem anderen Adressegment liegt.

[Neutral General]

@Blup: Das könnte man dann ja mit VirtualAlloc sicherstellen.

Allerdings klingt das für mich schon etwas übertrieben... Mhh..

[blablab]

wie groß ist denn so ein adresssegment?

[Neutral General]

Im Normalfall (unter Windows) 4KiB (4096 Bytes)

[SirThornberry]

Also entweder hab ich es übersehen oder es gibt in deinem Quelltext nirgends eine Zuordnung der Threads zu den jeweiligen Kernen.
Du erstellst insgesamt 3 Threads und hast zusätzlich noch den Hauptthread (wenn ich das richtig verstanden habe). Und dann erwartest du das Windows weiß wie die 4 Threads auf die mehreren Kerne aufgeteilt werden sollen? Wenn das nicht festgelegt ist kann es durchaus auch passieren das der hauptthread und auf dem einen Kern läuft und alle anderen Threads auf dem anderen Kern.

[blablab]

Juhu, Ich hab den Fehler gefunden!
Ich hab bei jedem Vergleich eine globale Variable erhöht um die Vergleiche zu zählen. (Hatte ich schon längst vergessen...) Und beim Multithreading hat dieser gemeinsame Zugriff alles ausgebremst.
Tut mir leid, dass ihr da gar nicht hättet drauf kommen können
Aber vielen Dank für eure Unterstützung!!!

@SirThornberry:
Ist für die sinnvolle Zuordung der Threads zu den Kernen nicht Windows verantwortlich?
Ich kann es ja schon so machen, dass jeder Kern einen Thread bekommt. Aber wenn dann ein Thread von einem anderen Programm plötzlich 100% Auslastung bekommt, dann dauert das komplette Sortieren ewig, weil ich auf diesen Thread warten muss...