TTask & Synchronize Verständnisproblem

[Mavarik]

Oder eher nicht...

Ok, der ThreadPool managed nur so viele gleichzeitige Thread wie es für die CPU - Core Anzahl sinnvoll ist, aber ist das auch sinnvoll für einen download?

i.d.R. nicht...

Hier würde ich die Anzahl begrenzen.
Das geht nicht über den Threadpool.

Mavarik

[Zacherl]

Zitat von Mavarik:

aber ist das auch sinnvoll für einen download?

Threads die primär IO-Operationen ausführen sind tatsächlich immer recht kritisch zu sehen. Zumindest ist deren Verhalten im Hinblick auf Performance deutlich abweichend zu CPU-lastigen Threads. Muss man denke ich individuell betrachten.

Zitat von Mavarik:

Hier würde ich die Anzahl begrenzen.
Das geht nicht über den Threadpool.

Doch doch, man kann die maximale Threadanzahl einstellen, oder sich sogar einen custom ThreadPool erzeugen, der dann dediziert nur für eine spezielle Art von Tasks verwendet werden kann

[Mavarik]

Zitat von Zacherl:

Doch doch, man kann die maximale Threadanzahl einstellen, oder sich sogar einen custom ThreadPool erzeugen, der dann dediziert nur für eine spezielle Art von Tasks verwendet werden kann

Ja, aber Achtung:

Zitat von System.Threading.pas:

Delphi-Quellcode:

function TThreadPool.SetMaxWorkerThreads(Value: Integer): Boolean;
begin
  Result := Value >= TThread.ProcessorCount;
  if Result then
    TInterlocked.Exchange(FMaxLimitWorkerThreadCount, Value);
end;

Mavarik

[Zacherl]

Zitat von Mavarik:

Ja, aber Achtung:

Zitat von System.Threading.pas:

Delphi-Quellcode:

function TThreadPool.SetMaxWorkerThreads(Value: Integer): Boolean;
begin
  Result := Value >= TThread.ProcessorCount;
  if Result then
    TInterlocked.Exchange(FMaxLimitWorkerThreadCount, Value);
end;

Das ist ja echt eine blöde Limitierung

[jaenicke]

Warum sollte man denn das Maximum geringer setzen wollen als die Anzahl der CPU Kerne?

Wenn man weiß, dass eine Aktion z.B. die Festplatte sehr stark beansprucht, ist ein Threadpool eher nicht geeignet, weil man dann ja gar nicht viele Tasks parallel möchte.

[himitsu]

Zitat von jaenicke:

Warum sollte man denn das Maximum geringer setzen wollen als die Anzahl der CPU Kerne?

Weil man das System nicht komplett auslasten will?

[jaenicke]

Dafür gibt es ja Prioritäten für Threads und Prozesse. Es macht doch keinen Sinn dann z.B. drei Kerne voll auszulasten und den vierten leer laufen zu lassen nur für den Fall, dass er benötigt wird...

[Mavarik]

Zitat von jaenicke:

Warum sollte man denn das Maximum geringer setzen wollen als die Anzahl der CPU Kerne?

Eben... Es gab mal eine Theorie, dass auf einem mobilen Gerät weniger Strom verbraucht wird, wenn man nicht alle Kerne benutzt, aber ich denke das stimmt nicht.

Aber für einen Download gelten andere Regeln, z.B. wenn der Server nur 1x die IP zu lässt.

Je nach Server und Bandbreite sind ca. 4 Thread optimal (bei großen Dateien) bei Tausenden kleinen sind mehr Thread besser...

Für den Download und die Verarbeitung der Daten empfehle ich sowas sie meine Parallel-Multithreading-Pipeline.

Wie man es implementiert ist fast egal - man kann auch einfach "nur" eine Anzahl von Workerthreads per Hand erzeugen und so die Daten verarbeiten.

Mavarik

[Uwe Raabe]

Zitat von Mavarik:

Aber für einen Download gelten andere Regeln, z.B. wenn der Server nur 1x die IP zu lässt.

Wer sagt denn, daß die Downloads alle von demselben Server kommen? Aber selbst wenn, dann warten die anderen Download-Threads auf den freiwerdenden Socket und benötigen dabei vermutlich auch keine CPU-Zeit. Dafür skaliert das System automatisch sobald mehrere gleichzeitige Downloads möglich sind. Ich sehe immer noch keinen Vorteil darin, die Anzahl der Threads zu begrenzen.