MultiThreading Bei mir ca. 40x Langsamer bei IntegerBerechnu

[Hallo_Thomas]

Hallo,Ich habe ein mein erstes Multithreading-TestProgramm geschrieben,& es ist vieeeeeeeeeeeel zu langsam.

Ich setzte den einmal die gleiche Rechenschleife in einen Thread ein & einmal in eine Procedore.Und in meinem Programm ist die Procedur 40x Schneller!

Mir ist schon klar, das die erschaffung der Threads und so, die Sache so verlangsamt.

Aber auch Multithreading kann ja heutzutage effizenter eingetzt werden!

Was mache ich also bei meinem Programm, wo an den Thread eine Array übergeben wird und dann auch die Array zurück!


Das Programm sieht wie folgt aus unit1=>Startet SteuerTread(Hier wird alles berechnet)=>Dieser verwaltet die NebenThreads1&2 die die Berechnungen durchführen

Dies ist die Procedure und Rechenschleife, das gliche wird in den Threads berechnet!

Delphi-Quellcode:

 procedure Counten(Var Feld1:TIntegerDynArray);
Var x,y:Integer;
begin
    for y:=0 to 13 do
    for x:=0 to 156 do Feld1[x]:=Feld1[x]+1*2 div 2;
    x:=SumInt(Feld1);
end;

Hier der Code von meiner Threadschleife:

Code:

procedure TGeldStatistikThread.ThreadDone(Sender: TObject);
begin
  Dec(ThreadsRunning);
  Dec(Fi);
  Case ThreadsRunning of
  0:begin
     ThreadsRunning:=5;
     with TThread1.Create(Feld) do
      OnTerminate := ThreadDone;
      with TThread2.Create(Feld) do
      OnTerminate := ThreadDone;
    end;
  3:begin
      ThreadsRunning:=2;
      with TThread1.Create(Feld) do
      OnTerminate := ThreadDone;
      with TThread2.Create(Feld) do
      OnTerminate := ThreadDone;
      //Dec(Listenlaenge);
      if Fi<0 Then
      begin
        Synchronize(Label2);
        ThreadsRunning:=10;
      end;
    end;
  end;
end;

NebenThread1 & 2 sind Identisch!

Code:

unit UnitNebenThread1;

interface

uses
  Classes,Types,math;

type
  TNebenThread1 = class(TThread)
  private
  Fe:TIntegerDynArray;
  Liste:Integer;
    { Private declarations }
  protected
    procedure Execute; override;
    procedure Counten2(Var Feld1:TIntegerDynArray); virtual; abstract;
  public

    constructor Create(Var Feld:TIntegerDynArray);
  end;
  { TThreadCounter  }
  TThread1  = class(TNebenThread1)
  protected
    procedure Counten2(Var Feld1:TIntegerDynArray); override;
  end;
implementation

uses unit1;

constructor TNebenThread1.Create(Var Feld:TIntegerDynArray);
begin
  Fe:=Feld;
  FreeOnTerminate := True;
  inherited Create(False);
end;

procedure TNebenThread1.Execute;
begin
  Counten2(Fe){ Thread-Code hier einfügen }
end;

procedure TThread1.Counten2(Var Feld1:TIntegerDynArray);
Var x,y:Integer;
begin
    for y:=0 to 13 do
    for x:=0 to 156 do Feld1[x]:=Feld1[x]+1*2 div 2;
    x:=SumInt(Feld1);
end;


end.

[jfheins]

Zitat:

Mir ist schon klar, das die erschaffung der Threads und so, die Sache so verlangsamt.

Aber auch Multithreading kann ja heutzutage effizenter eingetzt werden!

Ich würde sagen, es liegt am Overhead von Threads, bei der Mini-Berechnung fällt der ganze Threadkram schon ins Gewicht.

Threads sind imho für rechenintensive Operationen gedacht, nicht für 1000 kleine Divisionen ...

[Hallo_Thomas]

Ich habe in meinem Programm eine Schleife, mit mehreren Proceduren, die ca. soviel Rechenleistung brauchen, wie hier, da ich dies 1 Mio. mal durchlaufen lassen möchte, also den Thread immer &immer wiederhole, da muss es doch möglichkeiten geben, die sache zu beschleunigen?Oder anderes gefragt,wie kann ich solhe rechnungen effizent auf 2 Prozessoren verteilen?

[Der_Unwissende]

Hi,
was bei dir hier die ganze Performance frisst ist mit sicherheit schon mal das synchronize. Synchronisation ist super komplex und aufwändig und sollte deswegen so selten wie möglich angewendet werden. In deinem Fall könnte das dummerweise sehr häufig passieren. Das du damit dann nur auf den Faktor 40 kommst kannst du noch als ok ansehen, ginge auch schlimmer!

Zudem solltest du nur einen Thread pro CPU verwenden. Sonst hast du das Problem, dass sobald der Thread gewechselt wird die Daten vom Thread1 gespeichert werden müssen, die von Thread2 geladen und Thread2 dann gestartet werden muss. Natürlich ist auch die Zeitscheibe von Thread2 irgendwann vorbei, dann geht es so weiter (im Kreis). Hast du nur einen Thread, so entfällt die Verwaltung dieser Wechsel.

Wie gesagt, versuche einfach so wenig wie möglich direkt zu zeichnen. Wenn es geht, dann lager die synchronized Sachen in einen eigenen Thread aus, der dann auch mit geringerer Priorität läuft.

Und unterschätze nicht die Komplexität vom Threading, einfache Tests ist hier ein gefährlicher Begriff, es schleichen sich schnell schwer zu findende Fehler ein! Und überschätze andererseits nicht den Gewinn durch Threads (nicht nur dein Programm bekommt CPU Zeit und letztlich verteilt das BS wie es möchte).

Gruß Der Unwissende

[C.Schoch]

Hi,
Ich würde einen oder mehrere Threads für die Berechnung erstellen und diese so lange laufen lassen, bis sie beendet sind, so hast du den Rechenaufwand für die Erstellung der Threads nur einmal.

Für eine Berechnung die 0,00.. sec dauert ist ein Thread eh überflüssig.

[Meflin]

Zitat von Der_Unwissende:

Zudem solltest du nur einen Thread pro CPU verwenden. Sonst hast du das Problem, dass sobald der Thread gewechselt wird die Daten vom Thread1 gespeichert werden müssen, die von Thread2 geladen und Thread2 dann gestartet werden muss. Natürlich ist auch die Zeitscheibe von Thread2 irgendwann vorbei, dann geht es so weiter (im Kreis). Hast du nur einen Thread, so entfällt die Verwaltung dieser Wechsel.

Dieser Logik kann ich jetzt nicht ganz folgen: auch wenn SEIN Programm nur einen Thread pro CPU verwenden würde, würde deswegen trotzdem die Zeitscheibe dieses Threads irgendwann vorbei sein, weil auf der CPU garantiert noch ein paar andere Threads laufen. Somit hat man da dann dieselbe Situtation. Und somit kann ich deiner Logik nur einen Thread pro CPU zu verwenden (wie viele CPUs hast du ) nicht folgen.

[Luckie]

Mehrere Threads machen unter Singleprozessorsystemen wenig Sinn. Die Parallelität ist nämlich nur eine Quasi-Parallelität für den Benutz, da jeder Thread nur eine kurze Zeit die CPU zugewiesen bekommt und das Reih um geht. Eine CPU kann eben nur eine berechnung zur gleichen Zeit ausführen, da geht kein Weg drann vorbei. Will ich also folgendes ausrechnen:

Code:

x := (a+b) * (c-d) / (e+f)

Und teile das bei einer CPU auf drei Threads auf, ist der Gewinn gleich null, weil alle drei Threads trotzdem nacheinander von der CPU bedient werden. Habe ich aber drei oder vier CPUs sieht die Sache schon wieder anderes aus. Lasse ich jeden Thread auf einer CPU laufen habe ich den beabsichtigten Gewinn. Wenn man davon ausgeht, dass die gestellte Aufgabe entsprechend komplex ist und den Overhead für die Verwaltung, sowohl von der Architektur als auch vom Betriebssystem (Die Prozessoren müssen ja irgendwie zusammenarbeiten.), dann nicht mehr ins Gewicht fällt. Dies gilt natürlcih nicht für Hardware zugriffe, wenn drei Thread auf die Festplatte schreiben, ist der Gewinn auch gleich null, weil die festplatte nur einen Schreib- / Lösearm hat und solche Zugriffe also von sich aus schon keine Parallelisierung zu lassen.

Threads benutzt man dewegen nur auf Singleprozessorsystemen, damit die Hauptanwendung noch reagiert und eine Interaktion mit dem Benutzer möglich ist.

[Meflin]

@Luckie: das stimmt so uneingeschränkt auch nicht (oder ich unterliege da jetzt einem Denkfehler): denn habe ich eine Anwendung mit 10 Threads, dann bekommt diese ja insgesamt mehr CPU-Zeit zugewiesen wie eine Anwendung mit einem, da ja die CPU Zeit mal abgesehen von der PRiorität der Threads gleich auf alle Threads verteilt wird. Also im Endeffekt doch ein Geschwindigkeitszuwachs

[ecotron]

Hallo,

Habe das Beispiel mal auf meiner AMD X2 laufen lassen. Der Multithreading Test ist bei mir 80x langsamer.

Wenn man aber zum Test die Berechnungdauer der procedure "Counten" vergrößert dann ist die Multithreading Test ~1.8x schneller.

[3_of_8]

Es gibt außerdem doch auch HTT-Prozessoren und die sind auch ein Singleprozessorsystem, aber trotzdem schneller bei mehreren Threads.