Почему 16 потоков более эффективны, чем 8 на i7 с гиперядерным 4 ядром? (Robocopy)
В Windows 8.1 я использую Robocopy для сохранения данных двух серверов в специальном хранилище ПК. Объем данных составляет 147 314 файлов в 4 110 папках (66 841 845 760 байт).
Все 3 задействованных ПК оснащены процессором i7 с 4 ядрами и находятся в сети 1 Гб. Пространство памяти цели (зеркальное и полосатое на D:) реализовано с использованием корпуса JBOD 4 x 4 ТБ.
Из-за 4-х ядерных процессоров и гиперпоточности я ожидал, что коммутатор Robocopy /MT:8 будет работать лучше, и что более 8 потоков будут излишними из-за отсутствия управления потоками в бенефициарах.
Я проверял это. Я перечисляю здесь данные четвертой серии испытаний (продолжительность в мм: сс):
1 thread: 59:19
2 threads: 39:12
4 threads: 29:13
8 threads: 24:36
16 threads: 24:19
32 threads: 24:27
Конечно, несколько секунд, использующих 16 потоков, пренебрежимо малы, но они одинаковы во всех сериях тестов, т. Е. Не из-за большей нагрузки на тест менее 16 потоков (если это не было так во всех 4 сериях тестов). Также обратите внимание, что 32 потока почти всегда немного быстрее, чем 8 потоков.
Вопрос: по какой технической причине использование 16 потоков более эффективно, чем 8 потоков на i7 с 4 ядрами с многопоточностью?
1 ответ
TL;dr версия: если вы выполняете что-то с высокой интенсивностью использования процессора, такое как перекодирование видео с помощью Handbrake, то вам не захочется использовать больше ядер, чем процессоров, поскольку для выполнения этой работы не будет места. В этом случае, когда большинство потоков будет тратить 90% своего времени на ожидание чтения или записи, имея больше потоков, скорее для вас, чем против.
Копирование файлов не является особо сложной задачей. Хотя наличие большего количества ядер может помочь предотвратить блокирование вашего инструмента копирования другими задачами, маловероятно, чтобы каждый поток работал где-то на 100% на каждом ядре.
Каждый поток копирования отправит запрос на чтение на жесткий диск, а затем перейдет в спящий режим в ожидании выполнения запроса на чтение. Ваш диск с вращающейся ржавчиной обычно имеет время поиска 9 миллисекунд, практически целую вечность с точки зрения ЦП, и задача копирования не будет просто вращаться, говоря: "он уже готов?" и тратить циклы процессора. Это блокирует этот поток на 100% ресурсов процессора и тратит впустую ресурсы. Нет, происходит то, что поток выполняет чтение и поток переводится в спящий режим до тех пор, пока чтение не завершится и данные не будут готовы к следующему шагу.
Тем временем другой поток делает то же самое, блокируется на чтение и помещается в спящий режим. Это происходит для всех 16 ваших тем. (На самом деле ваши чтения и записи будут происходить в случайное время, когда они не синхронизированы, но вы поняли)
Как только у одного из потоков есть данные, готовые для него, Windows перепланирует его и начинает обрабатывать для записи. Что касается потока, процесс такой же. Там написано "записать эти данные в файл x в месте y", и Windows берет данные и удаляет поток. Windows выполняет фоновую работу, чтобы выяснить, где находится файл, перемещает данные (возможно, через сеть, добавляя к задержке больше миллисекунд), а затем возвращает управление потоку после успешного завершения записи.
Ни один поток не будет все время гореть на ядре ЦП, и поэтому больше потоков, чем у вас ЦП, не является проблемой. Никакая нить не проснется достаточно долго, чтобы это стало проблемой.
Если бы у вас был только один процессор с множеством других потоков, то вы могли бы быть узким местом на процессоре, но в многоядерной системе с такой нагрузкой я был бы удивлен, если бы проблема была в процессоре.
Вы, скорее всего, будете иметь узкие места в производительности жесткого диска и достигнете глубины очереди для буферов чтения или записи на дисках. Используя больше потоков, вы расширяете что-то до предела, будь то диск или сеть, и единственный способ узнать, какое количество потоков лучше, - это сделать то, что вы сделали, и поэкспериментировать с этим.
В системе с копированием с SSD на SSD, я подозреваю, что меньшее количество потоков может быть лучше, поскольку будет меньше задержка, чем при копировании файлов с вращающихся ржавых жестких дисков, проталкивании по сети и записи на вращающуюся ржавчину, но у меня нет никаких доказательств того, что поддержать это предположение.