TL; dr-Version: Wenn Sie etwas sehr CPU-intensives tun, z. B. das Transcodieren von Video mit der Handbrake, möchten Sie nicht mehr Kerne als CPUs verwenden, da die Arbeit nirgends zu erledigen wäre. In diesem Fall, in dem die meisten Threads 90% ihrer Zeit im Schlaf verbringen, wartet das Lesen oder Schreiben, wobei mehr Threads für Sie als für Sie arbeiten.
Das Kopieren von Dateien ist keine besonders CPU-gebundene Aufgabe. Wenn Sie mehr Kerne haben, kann dies zwar verhindern, dass andere Aufgaben Ihr Kopierwerkzeug blockieren, es ist jedoch unwahrscheinlich, dass jeder Thread auf jedem Kernen zu 100% ausgeführt wird.
Jeder Kopierthread sendet eine Leseanforderung an die Festplatte und geht dann in den Ruhezustand, während er auf die Erfüllung der Leseanforderung wartet. Ihre sich drehende Rostplatte hat im Allgemeinen eine Suchzeit von 9 Millisekunden, praktisch eine Ewigkeit in Bezug auf die CPU, und die Kopieraufgabe würde sich nicht einfach drehen und sagen: "Ist sie schon fertig?" und verschwenden CPU-Zyklen. Dadurch würde der Thread bei 100% CPU gesperrt und Ressourcen verschwendet. Nein, der Thread gibt einen Lesevorgang aus und der Thread wird in den Ruhezustand versetzt, bis der Lesevorgang abgeschlossen ist und die Daten für den nächsten Schritt bereit sind.
In der Zwischenzeit macht ein anderer Thread dasselbe, wird beim Lesen blockiert und in den Ruhezustand versetzt. Dies gilt für alle 16 Ihrer Threads. (In Wirklichkeit werden Ihre Lese- und Schreibvorgänge zu zufälligen Zeitpunkten ausgeführt, wenn sie nicht mehr synchron sind, aber Sie haben die Idee)
Sobald einer der Threads Daten für ihn bereitstellt, plant Windows diese erneut und beginnt mit der Verarbeitung, um geschrieben zu werden. In Bezug auf den Thread ist der Prozess derselbe. Es heißt "Schreiben Sie diese Daten in die Datei x an Position y" und Windows übernimmt die Daten und entschlüsselt den Thread. Windows erledigt den Hintergrund, um herauszufinden, wo sich die Datei befindet, verschiebt die Daten (möglicherweise über das Netzwerk addiert die Verzögerung um mehr Millisekunden) und gibt die Kontrolle an den Thread zurück, sobald das Schreiben erfolgreich war.
Kein Thread brennt ständig auf einem CPU-Kern, und daher sind mehr Threads als Sie über CPUs kein Problem. Kein Thread wird lange genug wach sein, damit er ein Problem darstellt.
Wenn Sie nur eine einzige CPU mit vielen anderen Threads hätten, könnten Sie Engpässe in der CPU haben. In einem Multicore-System mit dieser Art von Workload wäre ich jedoch überrascht, wenn die CPU das Problem ist.
Sie werden mit größerer Wahrscheinlichkeit in Bezug auf die Festplattenleistung Engpässe erhalten und erreichen die Warteschlangentiefe für die Lese- oder Schreibpuffer auf den Laufwerken. Wenn Sie mehr Threads verwenden, stoßen Sie etwas an seine Grenzen, sei es eine Festplatte oder ein Netzwerk, und Sie können nur herausfinden, was die beste Anzahl an Threads ist, indem Sie das tun, was Sie getan haben, und damit experimentieren.
Bei einem System mit SSD-zu-SSD-Kopieren würde ich vermuten, dass eine geringere Anzahl von Threads besser sein könnte, da es weniger Latenzzeiten gibt als das Kopieren von Dateien von sich drehenden Rost-HDDs, das Überspannen des Netzwerks und das Schreiben auf sich drehenden Rost stützen Sie diese Vermutung.