TTask & Synchronize Verständnisproblem

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

[Uwe Raabe]

Gerade die Downloads sind ja in der Regel nicht sonderlich prozessorintensiv. Solange das Warten auf den Empfang des nächsten Datenpakets bzw. dessen Schreiben auf Platte nicht mit einem Busy-Wait implementiert ist, regelt sich das eigentlich ganz von selber.

Andererseits geht auch hier nichts über reale Messungen.

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

[Mavarik]

Zitat von Uwe Raabe:

Wer sagt denn, daß die Downloads alle von demselben Server kommen?

Es war ja nur ein Beispiel.

Zitat von Uwe Raabe:

Aber selbst wenn, dann warten die anderen Download-Threads auf den freiwerdenden Socket und benötigen dabei vermutlich auch keine CPU-Zeit.

Das "glaube" ich nicht... Server die so eine Begrenzung haben liefert i.d.R. eine Fehlerseite. Bedeutet alle Threads die nachträglich gestartet werden laufen in leere und der download wird unproduktiv.

Aber vielleicht sollte man diese Theorien mal gegen ein Testsystem laufen lassen...

Mavarik

[Uwe Raabe]

Ich stelle gerade fest, daß wir uns ziemlich weit vom ursprünglichen Thema entfernt haben

[Mavarik]

Zitat von Uwe Raabe:

Ich stelle gerade fest, daß wir uns ziemlich weit vom ursprünglichen Thema entfernt haben

Stimmt... Die Frage war ja auch eigentlich mit #2 beantwortet...