Frage zu Threads bei Festplattenntensiven Programmen

[Lufia]

Hallo

ich habe hier im Forum unter http://www.python-forum.de/topic-6427.h ... hreadcount einen Beitrag zum verwenden mehrerer Threads gefunden.

Ich habe ein kleines Programm das Dateien (tecplot) in eine anderes Format (vtk) umwandelt. Dabei dachte ich das ich die Umwandlung evtl. durch das verwenden mehrerer Threads beschleunigen kann. Dazu habe ich ein Liste mit den umzuwandelnden Dateien erzeugt, und diese wie im Programm vorgegeben auf mehrere Threads verteilt. Jeder Thread öffnet also Dateien wandelt diese um und schreibt das resultat in eine Neue Datei. Wobei die Umwandlung an sich sehr schnell geht.

Bei der Verwendung von mehr als einem Thread braucht die Umwandlung leider deutlich länger als zuvor. Ich verstehe aber nicht genau warum das so ist.
Ich vermute das es evtl. daran liegt das die Festplattenzugriff (einlesen/Schreiben) der Dateien viel Zeit kostet bzw. das von den Threads nicht richtig aufgeteilt wird?

Für Ratschläge aller Art bin ich sehr dankbar

[EyDu]

Die Festplatte kann nur eine begrenzte Anzahl an Daten in einer bestimmten Zeit lesen, da kannst du auch mit mehreren Threads nichts machen. Da diese selber noch die Dateien öffnen und parallel von der Festplatte lesen wollen, muss diese oft unnötige Sprünge zwischen den Dateipositionen machen, welches wieder recht viel Zeit kostet.

Wenn der Flaschenhals wirklich das Lesen von der Festplatte ist, dann kannst du kaum etwas dagegen ausrichten.Du könntest also höchstens versuchen, dass Lesen der Dateien in einen Thread zu packen, welcher deren Daten dann an die Worker verteilt.

[Lufia]

Vielen Dank für die Antwort,

dann lohnt es sich wohl für mich nicht das Problem mit mehreren Threads zu lösen. Die Datenmenge in den einzelnen Dateien ist sehr groß. Threads lohnen sich dann wohl nur wenn viel mit Daten aus dem Arbeitsspeicher gerechnet wird.

[lunar]

Threads lohnen sich dann wohl nur wenn viel mit Daten aus dem Arbeitsspeicher gerechnet wird.

So pauschal stimmt auch das nicht. Wenn nur ein Prozessor vorhanden ist, dann wird der Code eh sequentiell ausgeführt, auch wenn man darüber mit Threads hantiert. Im Zweifelsfall treibt man nur den Scheduling-Aufwand in die Höhe

Threads können zwei Dinge leisten: Rechenintensive Tasks auf mehrere Prozessoren verteilen, so kann man z.B. bei Videokodierung moderen Dual/Quad-Core-Systeme ausreizen. Das allerdings funktioniert mit CPython nicht oder nur schlecht, da Python über den GIL sicherstellt, dass nur ein Thread gleichzeitig Python-Bytecode ausführen kann. In CPython selbst kann man über Threads also keine Parallelität bei rechenintensiven Aufgaben herstellen.

Zum anderen kann man über Threads IO-lastige Aufgaben in den Hintergrund schieben. Ein Prozessor rechnet um Welten schneller als Daten von Platte oder Netzwerkkarte eintröpfeln. Während ein Programm auf Daten von der Platte oder vom Netzwerk wartet, kann es parallel auch noch andere Aufgaben erledigen, beispielsweise eben eine GUI bereitstellen.

Mit Threading kann man aber keinesfalls auf magische Weise die Geschwindigkeit von IO-lastigen Aufgaben steigern. Wenn die Platte oder das Netzwerk schon am Anschlag sind, behindern sich mehrere Threads zwar gegenseitig, aber der IO-Durchsatz kann selbstverständlich nicht steigen.