TL; dr версия: если вы выполняете что-то сильно загружающее ЦП, такое как перекодирование видео с помощью Handbrake, то вам не захочется использовать больше ядер, чем ЦП, так как для работы не будет места. В этом случае, когда большинство потоков будет тратить 90% своего времени на ожидание чтения или записи, имея больше потоков работает для вас, а не против.
Копирование файлов не является особо сложной задачей. Хотя наличие большего количества ядер может помочь предотвратить блокирование вашего инструмента копирования другими задачами, маловероятно, чтобы каждый поток работал где-то на 100% на каждом ядре.
Каждый поток копирования отправит запрос на чтение на жесткий диск, а затем перейдет в спящий режим в ожидании выполнения запроса на чтение. Ваш вращающийся диск ржавчины обычно имеет время поиска 9 миллисекунд, практически целую вечность с точки зрения ЦП, и задача копирования не будет просто вращаться, говоря: "это уже готово?" и тратить циклы процессора. Это блокирует этот поток на 100% ресурсов процессора и тратит впустую ресурсы. Нет, происходит то, что поток выполняет чтение и поток переводится в спящий режим до тех пор, пока чтение не завершится и данные не будут готовы к следующему шагу.
Тем временем другой поток делает то же самое, блокируется на чтение и помещается в спящий режим. Это происходит для всех 16 ваших тем. (На самом деле ваши чтения и записи будут происходить в случайное время, когда они не синхронизированы, но вы поняли)
Как только у одного из потоков есть данные, готовые для него, Windows перепланирует его и начинает обрабатывать для записи. Что касается потока, процесс такой же. Там написано «записать эти данные в файл x в месте y», и Windows берет данные и удаляет поток. Windows выполняет фоновую работу, чтобы выяснить, где находится файл, перемещает данные (возможно, по сети, добавляя к задержке больше миллисекунд), а затем возвращает управление потоку после успешного завершения записи.
Ни один поток не будет гореть все время на ядре ЦП, и поэтому больше потоков, чем у вас ЦП, не является проблемой. Никакая нить не проснется достаточно долго, чтобы это стало проблемой.
Если бы у вас был только один процессор с множеством запущенных потоков, то вы могли бы быть узким местом на процессоре, но в многоядерной системе с такой нагрузкой я был бы удивлен, если бы проблема была в процессоре.
У вас больше шансов оказаться в узком месте с производительностью жесткого диска, и вы достигаете глубины очереди для буферов чтения или записи на дисках. Используя больше потоков, вы расширяете что-то до предела, будь то диск или сеть, и единственный способ узнать, какое количество потоков лучше, - это делать то, что вы сделали, и экспериментировать с этим.
В системе с копированием с SSD на SSD, я подозреваю, что меньшее число потоков может быть лучше, поскольку будет меньше задержка, чем при копировании файлов с вращающихся ржавых жестких дисков, проталкивании по сети и записи на вращающуюся ржавчину, но у меня нет никаких доказательств того, что поддержать это предположение.