Dateien kopieren - TThread

[Pentium 80486]

Hallo an alle,

derzeit überarbeite ich einige Funktionen in einem meiner Projekte.
Hierbei geht es um das Kopieren von Dateien.

Anfangs war alles so ausgelegt, dass ich eine StringListe mit Dateipfaden hatte. Diese wurde in einem Thread abgearbeitet.
Nun habe ich alles umgeschrieben und multithreadig-fähig gemacht, indem ich die Liste von mehreren Threads abarbeiten lasse (darf man das so nennen?).

Der Geschwindigkeitszuwachs ist enorm:
1 Thread, 100 x 10MB-Dateien ~ 25 Sekunden und mehr
5 Threads (je Thread 20 Dateien), ~ 10 bis 15 Sekunden.

Nun frage ich mich, wieviele Threads ich laufen lassen kann, ohne einen Systemabsturz zuverursachen?
Eine weitere Frage wäre; kann man noch mehr Leistung rauskitzeln? Getestet habe ich das Obige mit folgendem System:
- Intel Core i7 720QM (runtergetaktet auf etwa 4 x ~500Mhz)
- 1333Mhz - RAM
- Seagate Momentus XT (300 MBps 7200 rpm)

Mir geht es nicht darum, den schnellsten von allen Codes zu bekommen. Mir geht es viel mehr darum, dass der Kopiervorgang auch auf langsamen Systemen mit langsamen Systemkomponenten angenehm flot vonstatten geht.

[Medium]

Als eine Faustregel für für aktuelle CPUs günstige Threadanzahlen ist mir an einigen Stellen "2*AnzahlCPUKerne" begegnet (logische mitgezählt). Warum man über AnzahlCPUKerne hinaus noch Geschwindigkeitsvorteile hat weiss ich allerdings nicht mehr genau, und die Tabelle mit den Vergleichswerten ist mir leider auch nicht mehr im Kopf (bzw. auch ihr virtueller Lagerort nicht).

Aber: An und für sich dürfte beim Kopieren die CPU bei weitem kein Flaschenhals sein! Theoretisch hättest du sogar eine Geschwindigkeitsminderung sehen müssen, da nun die Platte ihr Ärmchen ja viel öfter schwingen muss, da die (gleicheztig, für die Platte ja aber sequenziell) zu kopierenden Dateien potenziell an ganz verschiedenen physikalischen Stellen liegen könnten. Read-Ahead und Caching werden da zwar Linderung verschaffen, aber schneller hätte ich niemals erwartet.
Meine Vermutung daher: Die Dateien liegen auf unterschiedlichen Laufwerken, und werden auch auf unterschiedliche Ziellaufwerke kopiert. Dann würde es Sinn machen nach Laufwerken zu gruppieren, und pro Laufwerk einen Thread zu starten.

Zur Obergrenze für Threads ganz allgemein spuckte Onkel Google als erste Links aus: 1, 2
Einen "Systemabsturz" wird man durch Unmengen an Threads jedoch kaum hinbekommen, eher wird dein Programm entweder einfrieren, oder mit einer Fehelermeldung vom System weggeschossen.

[Pentium 80486]

Read-Ahead und Caching hören sich sehr interessant an. Jedoch habe ich absolut keine Ahnung wie man soetwas umsetzt.

Das mit dem sich ständig und vermehrt bewegendem Ärmchen der Festplatte ist mir als allererstes in den Sinn gekommen.
Ich hoffe, dass die heutige Festplattentechnologe solche kurzzeitigen "Strapazen" verkraftet.

Read-Ahead.. hat das was mit Prefetching zu tun? Vorausschauendes Lesen heißt es ja. Prefetching ist ja, schlagt mich bitte nicht, quasi dasselbe (grob gesagt).

[Medium]

Mach dir um die Mechanik mal keine Sorgen, die kann das ab. Wir haben ja nicht mehr 1980
Read-Ahead ist Prefetching, und die Platten machen das, wie auch das Caching, selbst. Das ist schon alles da. Ich hab diese nur hier hin geschrieben, weil ich vermute, dass diese Maßnahmen multithreaded Zugriffen zumindest ein wenig ihren (von mir immer noch erwarteten) Geschwindigkeitsverlust zu mindern.

Dass du überhaupt eine Verschnellerung hattest ließe für mich nur den o.g. Schluss zu (mehrere beteiligte Devices), alternativ wären aber auch noch "nicht optimal" (lies: schlecht) geschriebene Kopierroutinen, die CPU und RAM mehr als sinnvoll ärgern, so dass sich Multithreading positiv auswirken kann.

[Pentium 80486]

Um ehrlich zu sein habe ich deinen ersten Beitrag noch nicht richtig verstanden, ist ja schon spät

Du vermutest also, dass die von meinem Programm abzuarbeitenden Daten auf verschiedenen Laufwerken liegen. Das habe ich so verstanden oder eben nicht vestanden.
Um Missverständnissden aus dem Weg zu gehen:

ich lasse 100 10MB große Textdateien mit 1-en drin von Desktop -> "Neuer Ordner" nach Desktop -> "Neuer Ordner 2" kopieren.
Aktuell verarbeiten fünf Threads diese Aufgabe.
Jeder Thread übernimmt 20 Dateien.

Edit:
ich möchte noch etwas zu den 1980ern sagen.
Damals waren die Festplatten zwar leistungsärmer und langsamer, dafür aber viel robuster!

Vor ein paar Jahren habe ich den Serverraum einer Firma zu Gesicht bekommen und ich wusste nicht ob ich lachen oder weinen soll.
Da waren doch tatsächlich noch uralte IDE-Festplatten verbaut. Nicht unbedingt schnell, aber langlebiger als so manch moderner Kram.

Edit #2:
Ein Test hat ergeben, dass der Verarbeitungsprozess mit acht Threads etwa 35 Sekunden dauert. Mit vier Threads ist er ~ 15 Sekunden schneller fertig.

[himitsu]

Zitat von Pentium 80486:

Der Geschwindigkeitszuwachs ist enorm:
1 Thread, 100 x 10MB-Dateien ~ 25 Sekunden und mehr
5 Threads (je Thread 20 Dateien), ~ 10 bis 15 Sekunden.

Wie und wie oft hast du das gemessen?

Das Problem bei Dateizugriffen ist meistens nicht die CPU, sondern die Festplatte, dazu dann noch die Controler und die Caches.
Je mehr kopiert werden soll, um so besser kann es sein, die Caches zu umgehen, um das System nicht komplett lahmzulegen, denn wenn z.B. die WindowsFileCache überfüllt wird, der RAM zur Neige geht, dann werden schnell mal die Programme ausgelagert.

Bei SSDs kommt es auf die Cache drauf an und ob, bzw wieviele Operationen sie gleichzeitig verarbeiten und zwischenspeichern kann, bzw. ob sie parallele Zugriffe auf unterschiedliche Chips/Speicherblöcke schafft.
Bei normalen HDDs (wenn die sonstige Hardware nicht langsamer ist, als die Platte), sind paralelle Zugriffe total kontraproduktiv, da die Platte dann mehr mit der Umpositionierung des Schreiblesekopfes beschäftigt ist, als mit dem eigentlichen Schreiben und Lesen. Dort ist das Sequentielle kopieren, über einen angemessenen Softwarepuffer der Ideale weg.

Da ein Computer aber auch noch andere Programme ausführt, kann es auch passieren, daß diese störend dazwischenfunken.




Wenn nebenbei diese Daten noch verarbeitet werden sollen, dann haben Threads eventuell wieder Vorteile.
Einer (pro HDD) ließt und schreibt und Einer/Mehrere verarbeiten die Daten.

[hathor]

Bei Angaben wie "schneller fertig" sollte man vorsichtig sein!
Was bedeutet das? Dass das Betriebssystem meldet, dass alle Threads ausgeführt und beendet worden sind?
Oder dass die Festplatte tatsächlich alle Daten erhalten hat und die Laufwerks-Aktivitätsanzeige erloschen ist?
Wie sind die Einstellungen des Anti-Virus-Programms?
"Liest mit" beim Lesen, beim Schreiben oder ist es ausgeschaltet = realitätsfremd...
Wie ist die Einstellung der Leistungsüberwachung, der Indexierung der Files, der Indexierung der Inhalte der Files etc. (z.B. bei WIN 7: Resourcenmonitor ausgeschaltet?) ?
Viele unbeantwortete Fragen...

[jaenicke]

Das Problem ist, dass nach deiner ersten Messung die Daten komplett im Arbeitsspeicher liegen dürften. Dass weitere Messungen dann schneller sind, ist klar, weil es nur noch darum geht die Daten möglichste schnell zu schreiben.

Wenn du realistische Werte haben willst, musst du den PC vor jeder Messung komplett neu starten. Und selbst dann kann dir der Schreibcache hineinfunken. Du solltest die Platte daher zusätzlich auf schnelles Entfernen statt Cache einstellen (was bei der Systemplatte aber wenig sinnvoll wäre).

Auf dem selben Datenträger ist es ohne massives Caching so gut wie ausgeschlossen, dass mehrere parallele Kopiervorgäge schneller sind.