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