PureBoard

Ich habe mal eine Grundsatzfrage zur Verwendung von Threads. Ich habe mehrere Textdateien die ich einlese und auswerte. Momentan mache ich das ohne Threads, d.h. ich arbeite die Liste der Textdateien der Reihe nach ab.

Bin nun am überlegen, ob ich die verschiedenen Textdateien in verschiedenen Threads abarbeiten soll. Wenn die Maschine nun z.B. nur einen Kern hätte (gibt es ja kaum noch), wäre es sicher Kontraproduktiv, mehrere Threads zu starten. Wahrscheinlich ist es genau so Kontraproduktiv, mehr Threads zu starten, als Kerne im Prozessor sind.

Wie würdet ihr das handhaben? Ein Haupt-Thread, der nur die Verwaltung macht und je vorhandenen Kern (-1 für den Hauptthread) einen Thread zur Auswertung einer Textdatei startet und wenn eine Textdatei fertig bearbeitet ist, wieder einen Thread mit einer neuen Textdatei starten.

Habt Ihr so was schon mal gemacht, oder soll ich einfach brutal für jede Textdatei einen Thread starten, ohne Rücksicht auf die Anzahl der Kerne zu nehmen?

Hallo Josh,
wie lange braucht Dein Programm beim ersten mal um die Textdateien von der Festplatte einzulesen und wie lange braucht Dein Programm für die Auswertung?
Eine Textdatei teilweise von der Festplatte zu lesen, den Lesekopf auf eine andere Textdatei zu setzen und dann die erste Textdatei weiter zu lesen ist sicher nicht optimal.
Der Start eines Threads braucht bei mir etwa 25 Mikrosekunden und 1 MB Speicher für Threadstack.

Gruß

Dateioperationen in Threads auszulagern ist meistens kontraproduktiv, wobei SSDs daran schon einiges geändert haben.
Erzähl uns mal etwas mehr über dein Vorhaben und vor allem die Größe und Anzahl der Daten, damit man abschätzen kann welches Vorgehen sich am ehesten lohnt.

Das mit den Kernen ist richtig. Es können max. soviele parallel Threads laufen, wie der Prozessor Kerne hat. Jeder weitere bringt keinen Vorteil (eher Nachteile).

oder soll ich einfach brutal für jede Textdatei einen Thread starten, ohne Rücksicht auf die Anzahl der Kerne zu nehmen?

Besser nicht.

Mehr Threads als Kerne macht keinen Sinn. Wenn du 5 Threads, aber nur 2 Kerne hast, laufen trotzdem nur max. 2 gleichzeitig. Nicht umsonst kann man bei rechenlastigen Dingen (wie z.B. Videokompression) die Anzahl Threads vorgeben.

Wenn du 100 Dateien in eigenen Threads öffnest, hättest du 100 Threads, die sich um die vorhandenen Kerne (und vor allem, und wie auch schon angesprochen, um die Festplatte) Kloppen. Dann passiert in etwa das, was auch passiert, wenn du im Dateimanager 100 Dateien markierst und auf Enter drückst.

Ich würde mal in den Raum werfen: Einen Thread für dein Hauptprogramm/GUI (den Mainthread, den du sowieso hast) und noch einen weiteren, der die Dateien nacheinander von der Festplatte einliest und verarbeitet. Der Mainthread sagt dann: "Lesethread, lade Datei xyz und gib mir das Ergebnis zurück, sobald du fertig bist.".

Auch wenn das jetzt auf einem Prozessor mit nur einem Kern läuft, ist es trotzem besser, weil sie dann wie beim normalen Multitasking abwechselnd ausgeführt werden und das Hauptprogramm vom User währenddessen weitergenutzt werden kann.

Die größte Bremse wird ohnehin die Festplatte sein und die ist am schnellsten, wenn nur ein Prozess darauf zugreift.

Einfach mal ausprobieren.

Ich weiß noch wie wird damals über robocopys multithreading option gestaunt haben.
Rechner hatten nur 1 CPU Kern (+HT), aber mit 16 Threads wurde deutlich schneller kopiert.

Gibt halt viele Variablen die da mit reinspielen.
Der Dateisystemtreiber ist auch nicht blöd und springt nicht unnötig auf der Festplatte rum.

Wieviele Threads gleichzeitig laufen lassen?

So viele wie man eben braucht.

Man könnte ja auch das Maximum austesten und sehen was der Stack hergibt.

Im "Normalfall" braucht man aber recht wenig Threads.

Ist kein Problem mit vielen Threads, wenn man viele nennen bei einer meiner Anwendungen darf...

Beispiel:
Pro Kommunikation zu einer Steuer werden immer zwei Threads benötigt. Einen für die Kommunikation und einen als Watchdog.
Zur zeit sind 60 Steuerung eingerichtet und Somit 120 Thread aktiv.
Dazu kommt ein Threads zur bearbeiten der gesammelten Daten und übergibt diese eine Datenbank.

Läuft absolute Störungsfrei und die Belastung der CPU ist sehr Minimal. Unter 1 Prozent bei inaktiver GUI.

Wenn du mal in der Systemsteuerung (bei Windows) unter Leistung nachsiehst, wirst du immer sehen, dass zwischen 1000-2000 Threads am laufen sind. Die Anzahl der Threads ist also grundsätzlich in bestimmen Grenzen "egal" und nicht abhängig von der Anzahl Kerne. Entscheidend ist, was in den Threads gemacht wird.

Wenn in einem Thread auf das Eintreten eines bestimmten System-Ereignisses gewartet wird (wie z.B.die Positionierung des Schreib/lese-Kopfes der Festplatte ), wird DIESER Kern des Prozessors für die nachstehenden Threads ausgebremst.

ohne Rücksicht auf die Anzahl der Kerne zu nehmen?

Ja! Es ist die Aufgabe des Betriebssystems, diese geschickt zu verteilen und braucht uns nicht zu kümmern! Denn einzigen Einfluss darauf haben wir, in dem wir mehrere Threads erzeugen, die dann das OS aufteilen kann.

Gruß
Thomas

Sylvia hat geschrieben:Wenn du mal in der Systemsteuerung (bei Windows) unter Leistung nachsiehst, wirst du immer sehen, dass zwischen 1000-2000 Threads am laufen sind.

Kurze Frage: Wo genau ist das zu sehen (unter Windows 7)? Ich finde es leider nicht.