Langsames Multithreading

[BLin4ik]

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.

[CarlAshnikov]

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.

[BLin4ik]

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;

[ringli]

Ohne jemals (bewusst) etwas mit Threads gemacht zu haben: Wäre es möglich das deine CSV-Klasse gar nicht multithreadingfähig ist?

[Klaus01]

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

[BLin4ik]

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.

[Captnemo]

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.

[himitsu]

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.

[Patito]

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.

[OlafSt]

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.