![]() |
Langsames Multithreading
Hallo,
ich möchte gerne eine Verarbeitung über mehrer Threads laufen, das hat soweit funktioniert. Aber jetzt kommt der haken, ich habe bemerkt, dass 2 Threads genauso schnell wie ein Thread arbeiten und mir leuchtet bis jetzt noch nicht ein warum das so ist. Ich habe ein Intel Xeon E3-1225 V2 und habe dementsprechend 4 physische Kerne. Jeder Thread liest seine eigene CSV-Datei aus und verarbeitet diese Zeile für Zeile in einer Schleife. Durch "SetThreadAffinityMask" werden die Threads dem jeweiligen Kern zugewiesen. Jetzt könnte man darauf kommen, dass es was mit dem Dateizugriff zu tun hat, aber in diesem Fall verwende ich eine SSD und das sollte eher weniger ein Problem sein. Anhand des Ressourcen-Managers habe ich festgestellt, dass wenn die 2 Threads parallel laufen, die zwei jeweiligen Kerne nur 50% ihrer Leistung verwenden. Sobald einer der zwei Threads bereits fertig ist, schießt der andere sofort mit der vollen Leistung, als ob die Arbeit auf die Kerne zerteilt wird. Wenn ich jedoch die Verarbeitung sequenziell durchführe, kriege ich immer die volle Leistung. Das hat zur Auswirkung, dass es keinen Unterschied macht ob ich parallel oder sequenziell verarbeite, da beide Varianten auf fast genau die gleiche Zeit kommen. Kann es sein, dass die Threads Prozessabhängig sind? Ich habe nämlich einen Versuch gestartet und das Programm 2x ausgeführt und habe sie sequenziell verarbeiten lassen. (2 PIDs) Das hat mich schon sehr gewundert, dass ich so auf mein gewünschtes Ergebnis komme, da beide Prozesse in ihrem Kern diesmal die volle Leistung erhalten haben und die Zeit sich dadurch nahe zu halbiert hat. Das ist aber nicht die gewünschte Lösung, ich möchte die Anwendung nur einmal starten und trotzdem die volle Leistung der Kerne ausschöpfen können. |
AW: Langsames Multithreading
Wieso verteilst du die Threads von Hand auf die Kerne? Normalerweise sollte das Scheduling von Windows die verteilen.
Das Problem hört sich danach an als ob die Threads in einem Synchronisierungsblock hängen und damit nur die Hälfte der Zeit effektiv arbeiten können weil nur einer von Beiden den gearde verwenden darf. Für genauere Analysen solltest du Quelltext zur Verfügung stellen. |
AW: Langsames Multithreading
Die Verteilung wird vorgenommen, weil ich so die volle Leistung von jedem Kern erreichen möchte, um
dadurch das maximal an Perfomance zu gewinnen und sich die Threads nicht stören. Die Threads müssen zugewiesen werden, da das in Delphi 5 nicht automatisch passiert und alle nur den ersten Kern verwenden. Hier ein Beispiel wo es bereits schon klemmt, es reicht schon, wenn der Thread einfach nur in der Schleife läuft:
Code:
...
begin CoInitializeEx(nil, COINIT_APARTMENTTHREADED); try while not Terminated do begin for i := 0 to MaxCount do //MaxCount kann über 30.000 Zeilen gehen FCSVFile.ReadLine; //Die Zeile wird innerhalb der Klasse ausgelesen und aufbereitet break; end; finally CoUninitialize; end; end; |
AW: Langsames Multithreading
Ohne jemals (bewusst) etwas mit Threads gemacht zu haben: Wäre es möglich das deine CSV-Klasse gar nicht multithreadingfähig ist?
|
AW: Langsames Multithreading
.. arbeiten dann beide Threads mit ein und der selben Instanz von FCSVFile?
Wäre es möglich jdem Thread eine eigene Instanz zu spendieren? Grüße Klaus |
AW: Langsames Multithreading
Jeder Thread hat seine eigene CSVFile-Instanz, dafür wurde schon gesorgt,
das muss auch so sein, da alle Threads ihre eigene Datei verarbeiten. Es wird nichts Global angesprochen und bei diesem Fall gibt es auch keine Critical Sections. |
AW: Langsames Multithreading
Wie würde es denn aussehen, wenn du die Daten in die Instanzen von FCSV erst komplett einliest, und dann erst beide Threads startest?
Dann hättest du eine Beeinflussung durch Filezugriffe erst mal ausgeschlossen, da du ja im Test die Daten auch nirgends ausgibst. |
AW: Langsames Multithreading
Was macht MaxCount und ReadLine intern?
Und sind die Dateien alle auf der selben Festplatte? Windows verteitlt das eigentlich schon recht ordentlich und wenn jetzt zusätzölich noch irgendein Programm auf dem Kern richtig läuft, dann bremst du dich unnötig selber aus, weil du deine Threads nicht verschieben lässt. |
AW: Langsames Multithreading
Ein üblicher Bottleneck beim Multithreading ist der Memory-Manager.
Falls Deine Threads Speicher benötigen, werden sie sich gegenseitig in die Quere kommen. FastMM von Delphi ist eher Richtung Single-Threading optimiert. Lösen kann man solche Probleme dann durch geeignetes Pooling, oder man experimentiert mit andersartigen Memory-Managern. |
AW: Langsames Multithreading
Und das COINIT_APARTMENTTHREADED beachtet keiner ? Dies sorgt für die Serialisierung der Threads, fürchte ich. Ein COINIT_MULTITHREADED könnte aufschlußreiche Ergebnisse bringen.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz