Bringt paralleles Einlesen/Schreiben mehrerer Dateien etwas?
-
Ich frage mich immer wieder, wie gut I/O auf Festplatten parallelisierbar ist und habe keine befriedigenden Antworten im Internet gefunden. Folgende Szenarien:
- Will mehrere Dateien parsen und im RAM speichern
- Will mehrere Dateien einlesen, leicht ändern (nur lokal, brauche wenig Buffer) und direkt wieder rausschreiben
- Habe Ergebnisse, will mehrere Dateien rausschreiben
Und das gleiche noch mit nur einer Riesendatei anstatt mehreren.
Nach meinem Verständnis der Hardware ist es kontraproduktiv, zwei Dateien gleichzeitig einzulesen, aber sicher bin ich mir da nicht. Wäre nett, wenn jemand ein paar grundlegende Äusserungen dazu machen könnte.
-
Wenn beim Parsen mehr als nur triviale Verarbeitung ist, dann mach trotzdem NOCH nicht parallel, der Schreib-Lese-Kamm fühlt sich total verarscht. Wenn die allermeisten Kunden SSDs haben, dann mach.
Und beim Schreiben ist es komplett egal, man schreibt ja erst in den einige GB großen Schreibcache und das BS sortiert es schon rum, also spar Dir die Mühe.Ich bestätige Dein Verständnis von Hardware.
-
Lineares Lesen/Schreiben ist am schnellsten.
Wenn du wenige grosse Files hat, liest bzw. schreibst du die also am Besten eine nach dem anderen.Wenn du dagegen viele kleine Files hast, kann es was bringen die parallel zu lesen bzw. schreiben.
Dann hat nämlich dein OS, bzw. auch der Controller der Platte mehrere offene IOs "ausständig", und kann gucken welches die beste Reihenfolge ist die auszuführen.Angenommen die IOs lesen die Sektoren 100, 10100, 200, 10200, 300 und 10300. Dann ist es viel schneller wenn die Platte das in der Reihenfolge 100, 200, 300, 10100, 10200, 10300 macht, als in der zuerst genannten.
Das kann sie natürlich nur wenn das Programm alle IOs startet bevor es auf die Beendigung des ersten wartet.
-
@volkard & hustbaer: Danke, das leuchtet ein.
hustbaer schrieb:
Dann hat nämlich dein OS, bzw. auch der Controller der Platte mehrere offene IOs "ausständig", und kann gucken welches die beste Reihenfolge ist die auszuführen.
Das erstaunt mich, hat das OS tatsächlich so viel Suveränität? Das würde ja heissen, ein einzelnes read kann Millisekunden dauern, weil andere Threads/Prozesse (sind die hier gleichwertig?) bevorzugt werden.
Und noch eine Vermutung zum bestätigen: Wenn ich eine Datei sequentiell lese, merkt das OS das und liest im Hintergrund weiter?
-
paralles io schrieb:
Wenn ich eine Datei sequentiell lese, merkt das OS das und liest im Hintergrund weiter?
Ja. Es liest vorsichtigerweise im Voraus, obwohl Du nicht angefragt hast.
Unter WinXP war das glaube ich 2MB als Default-Einstellung.
-
paralles io schrieb:
hustbaer schrieb:
Dann hat nämlich dein OS, bzw. auch der Controller der Platte mehrere offene IOs "ausständig", und kann gucken welches die beste Reihenfolge ist die auszuführen.
Das erstaunt mich, hat das OS tatsächlich so viel Suveränität? Das würde ja heissen, ein einzelnes read kann Millisekunden dauern, weil andere Threads/Prozesse (sind die hier gleichwertig?) bevorzugt werden.
Das würde mich auch erstaunen. Also ich vermute nicht, daß das OS so souverän ist.
Aber die Platte mit NCQ ist es!!
-
volkard schrieb:
paralles io schrieb:
hustbaer schrieb:
Dann hat nämlich dein OS, bzw. auch der Controller der Platte mehrere offene IOs "ausständig", und kann gucken welches die beste Reihenfolge ist die auszuführen.
Das erstaunt mich, hat das OS tatsächlich so viel Suveränität? Das würde ja heissen, ein einzelnes read kann Millisekunden dauern, weil andere Threads/Prozesse (sind die hier gleichwertig?) bevorzugt werden.
Das würde mich auch erstaunen. Also ich vermute nicht, daß das OS so souverän ist.
Aber die Platte mit NCQ ist es!!Bei NetWare 4.x hieß das 'elevator seek' und war ein offiziell beworbenes Feature.
-
Auf der Linux Mailing-Liste (Archiv) hab ich was von "IO-Elevators" gelesen, und dass sie da was tunen/ändern wollen wegen der SSDs.
Unter Windows hab' ich den Test selbst mal gemacht.
Mach 1000+ Random IOs gleichzeitig und dann 1000+ Random IOs hintereinander. Unterschied in der Ausführungszeit: dramatisch.
Klar könnte es die HDD gewesen sein, aber ich vermute eher dass Windows da mit die Finger im Spiel hat. Weil der Unterschied wie gesagt dramatisch war, und MS komplett irre wäre wenn sie diese Optimierungsmöglichkeit nicht nutzen würden.
-
hustbaer schrieb:
Unter Windows hab' ich den Test selbst mal gemacht.
Mach 1000+ Random IOs gleichzeitig und dann 1000+ Random IOs hintereinander. Unterschied in der Ausführungszeit: dramatisch.Da muß man aber arg aufpassen, daß man nur den Elevator misst.
hustbaer schrieb:
Klar könnte es die HDD gewesen sein, aber ich vermute eher dass Windows da mit die Finger im Spiel hat. Weil der Unterschied wie gesagt dramatisch war, und MS komplett irre wäre wenn sie diese Optimierungsmöglichkeit nicht nutzen würden.
MS *ist* manchmal komplett irre.
Andererseits, mehrere parallele Kurzrechner und die Daten nicht ganz im Lesecache?http://stackoverflow.com/questions/9191/how-to-obtain-good-concurrent-read-performance-from-disk
-
volkard schrieb:
Andererseits, mehrere parallele Kurzrechner und die Daten nicht ganz im Lesecache?
Bahnhof
http://stackoverflow.com/questions/9191/how-to-obtain-good-concurrent-read-performance-from-disk
Da stehn auch nur Vermutungen.
