Kein wirklicher Geschwindigkeitsvorteil durch Threads?

[Bernhard Geyer]

Zitat:

Zitat von Ginko (Beitrag 1214945)

" Auf einem Ein-Prozessor-System stellen 16 aktive Threads die praktikable Obergrenze dar. "

Das wichtigest Wort ist wohl praktikable.
D.h. für viele Fälle sollte man nicht mehr nehmen, es kann aber auch im Einzelfall schon bei weniger Threads zu Verlangsamung kommen.
Mann sollte es mit dem Eigenen Anwendungsfall testen.

[BUG]

Ich höre öfter mal 1-1,5 mal Anzahl Kerne als Grenzwert, das hängt aber sicher von der Aufgabe und dem System ab.
Das Optimum ist da nur heuristisch zu ermitteln.

Für jede Datei einen Thread zu Erstellen ist aber höchstwahrscheinlich der falsche Weg.
Anstelle von der Anzahl der Ressourcen (Kerne, evtl. Platten/Partitionen), welche die "ideale" Anzahl von Threads bestimmen, lässt du die Anzahl der Aufgaben diese Entscheidung treffen, die damit nichts zu tun hat und vermutlich auch noch vom arglosen User vorgegeben wird.

Zu viele Threads kosten Zeit für die Erstellung (wenn du keinen Pool benutzt), Zeit für die Threadwechsel und nicht zu vergessen: das Dateisystem (und das Gesamtsystem allgemein) wird auch nicht gerade effizienter, je mehr Threads darauf herumhacken.

[Ginko]

Gibt es einen Weg die Dauer des gesamten Vorgangs zu messen ?

Delphi-Quellcode:

procedure TForm1.Button8Click(Sender: TObject);
var
  DateienLst: TSearchRec;
  Thread1: TMyThread1;
  //Zeittest
  freq: Int64;
  startTime: Int64;
  endTime: Int64;
begin
  QueryPerformanceFrequency(freq);
  QueryPerformanceCounter(startTime);

  if FindFirst(Directory + '*.txt', faAnyFile and not faDirectory, DateienLst) = 0 then
    try
      repeat
        Thread1:= TMyThread1.Create(True);
        Thread1.FreeOnTerminate := True; 
        Thread1.FDateienname:= Directory+DateienLst.Name;
        Thread1.Resume;
      until FindNext(DateienLst) <> 0;

    finally
      SysUtils.FindClose(DateienLst);
    end;

  QueryPerformanceCounter(endTime);
  ShowMessage('Die Routine benötigte etwa ' + IntToStr((endTime - startTime) * 1000 div freq) + 'ms');
end;

Der Wert der hier raus kommt deckt sich ja nicht mit der Gesamtdauer, da die Threads ja unabhängig laufen oder ?

[Der schöne Günther]

Zitat:

Zitat von Ginko (Beitrag 1214945)

" Auf einem Ein-Prozessor-System stellen 16 aktive Threads die praktikable Obergrenze dar. "

Wohlgemerkt "Ein-Prozessor-System", nicht "Ein-Kern-CPU" - Der Text ist mit Sicherheit 10, 15 Jahre alt. Schau doch mal in deinen Taskmanager, wieviele Threads da manche Prozesse haben. Und ist nicht auch das RAD Studio in Delphi geschrieben? Das Teil hat auch deutlich mehr als 16 Threads. Diese Schlingel.

PS: Üblicherweise reserviert Windows glaube ich eine Stack-Größe von ca 1MB pro Thread. Wenn du jetzt 100 Threads aufmachst, kostet dich das natürlich auch 100 Megabyte und mehr. Nicht, dass das heute noch jemanden stören würde, aber vor ein paar Jahren hat man das sicherlich gemerkt, wenn man mal eben 200 Threads aufgemacht hat...

[Sir Rufo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214957)

Zitat:

Zitat von Ginko (Beitrag 1214945)

"Auf einem Ein-Prozessor-System stellen 16 aktive Threads die praktikable Obergrenze dar. "

Wohlgemerkt "Ein-Prozessor-System", nicht "Ein-Kern-CPU" - Der Text ist mit Sicherheit 10, 15 Jahre alt. Schau doch mal in deinen Taskmanager, wieviele Threads da manche Prozesse haben. Und ist nicht auch das RAD Studio in Delphi geschrieben? Das Teil hat auch deutlich mehr als 16 Threads. Diese Schlingel.

Warum sollten das "Schlingel" sein?

Hast du alle diese Threads untersucht, ob diese auch aktiv sind? :roll:

Zitat:

Zitat von Der schöne Günther (Beitrag 1214957)

PS: Üblicherweise reserviert Windows glaube ich eine Stack-Größe von ca 1MB pro Thread. Wenn du jetzt 100 Threads aufmachst, kostet dich das natürlich auch 100 Megabyte und mehr. Nicht, dass das heute noch jemanden stören würde, aber vor ein paar Jahren hat man das sicherlich gemerkt, wenn man mal eben 200 Threads aufgemacht hat...

Dazu gibt es einen sehr guten (englischen) Beitrag
Of Threads, Stacks and RAM – Part 1
Of Threads, Stacks and RAM – Part 2

[Uwe Raabe]

Zitat:

Zitat von Ginko (Beitrag 1214954)

Der Wert der hier raus kommt deckt sich ja nicht mit der Gesamtdauer, da die Threads ja unabhängig laufen oder ?

Der Wert, der da rauskommt ist mal gerade die Zeit für das Erstellen der Dateiliste und das Erzeugen und Starten der Threads. Die Laufzeit der Threads kommt da überhaupt nicht zu tragen. Dazu müsstest du auf das Beenden aller Threads warten.

[jaenicke]

Zitat:

Zitat von Ginko (Beitrag 1214954)

Der Wert der hier raus kommt deckt sich ja nicht mit der Gesamtdauer, da die Threads ja unabhängig laufen oder ?

Zähle mit wie viele Threads du erstellt hast und weise diesen beim Erstellen ein OnTerminate zu. In diesem Event OnTerminate zählst du dann wieder runter. Wenn du da bei 0 ankommst, wurden alle beendet und du kannst das dem Benutzer melden bzw. deine Zeitmessung beenden.

[Ginko]

Ok danke das werde ich mal versuchen.

[creed steiger]

für was eigentlich threads?

Starte halt deine Prozesse ohne poWaitOnExit und prüfe später ab,ob sie beendend sind.

http://lazarus-ccr.sourceforge.net/d.../tprocess.html

http://lazarus-ccr.sourceforge.net/d...s.options.html

[Ginko]

So hat sich doch gelohnt, also vorher waren es ca. 27sek jetzt sind es ca. 15sek. Also fast doppelt so schnell und beide Kerne sind bei voller Last für die Zeit.
Den Zeittest habe ich so gemacht:

Delphi-Quellcode:

[...]
 private
    { private declarations }
    procedure CountDown(Sender: TObject);
  public
    { public declarations }
  end;
[...]
{ TForm1 }
var
  GThreadCount: Integer = 0;
  Gfreq: Int64;
  GstartTime: Int64;
  GendTime: Int64;

procedure TForm1.CountDown(Sender: TObject);  //Aktion am Ende eines Threads
begin
  Dec(GThreadCount);
  if ThreadCount = 0 then
  begin
    QueryPerformanceCounter(GendTime);
    ShowMessage('Die Routine benötigte etwa ' + IntToStr((GendTime - GstartTime) * 1000 div Gfreq) + 'ms');
  end;
end;

procedure TForm1.Button1Click(Sender: TObject); 
var
  DateienLst: TSearchRec;
  Thread1: TMyThread1;
begin
  QueryPerformanceFrequency(Gfreq);
  QueryPerformanceCounter(GstartTime);

  GThreadCount:= 0;
  if FindFirst(Directory + '*.txt', faAnyFile and not faDirectory, DateienLst) = 0 then
    try
      repeat
        Inc(GThreadCount);
        Thread1:= TMyThread1.Create(True);
        Thread1.FreeOnTerminate := True;
        Thread1.FDateienname:= Directory+DateienLst.Name;
        Thread1.OnTerminate:= @CountDown;// Prozedur die beim beenden des Threads ausgeführt wird
        Thread1.Resume;
      until FindNext(DateienLst) <> 0;
    finally
      SysUtils.FindClose(DateienLst);
    end;
end;

Um die Threads zu beschränken habe ich hier diese nützliche Unit mal benutzt (http://www.delphipraxis.net/93835-wo...tml#post637044), da habe ich aber noch keinen Zeittest hinbekommen.
@creed steiger Danke für den Hinweis, ich weiß aber nicht wo ich den ExitStatus abfragen soll damit ich ihn für den Zeittest benutzen kann und kann man die Anzahl auch irgenwie begrenzen der Prozesse, ohne alzu großen Aufwand?