Почему производительность параллельной компиляции с HT хуже, чем без него?

Гиперпоточность на чипах Intel реализована как дублирование некоторых элементов физического ядра, но без достаточного количества электроники, чтобы быть независимым ядром (например, они могут совместно использовать декодер инструкций, но я не могу вспомнить особенности реализации Intel).

Представьте физическое ядро ​​с HT как 1,5 физических ядра, которое ваша ОС видит как 2 реальных ядра. Это не соответствует скорости в 1,5 раза (это может варьироваться в зависимости от варианта использования).

В вашем примере non-HT работает быстрее до 4 потоков, потому что ни одно из ядер не разделяет работу со своим конвейером HT. Вы видите плоскую линию над 4 потоками, потому что теперь у вас есть только 4 потока выполнения, и вы получаете небольшую дополнительную нагрузку на переключение контекста между потоками.

В примере HT вы немного медленнее до 4 потоков, вероятно, потому, что некоторые из этих потоков назначаются реальному ядру, а это HT, поэтому вы теряете производительность, поскольку эти два потока выполнения совместно используют физические ресурсы. Выше 4 потоков вы видите преимущество дополнительных потоков выполнения, но вы видите начало убывающей отдачи.

Вероятно, вы могли бы сопоставить производительность в обоих случаях до 4 потоков, но, вероятно, не с заданием компиляции. Я думаю, что многие процессы создаются для привязки к процессору. Если бы вы вместо этого запускали реальное параллельное задание с использованием OpenMP или MPI с X ‹= 4 потоками, привязанными к конкретным реальным ядрам ЦП, я думаю, вы бы увидели аналогичную производительность между HT-off и -on.

Учитывая количество потоков ‹= количество реальных ядер, использование HT должно быть медленнее, потому что (грубо говоря) вы потенциально сокращаете скорость ваших ядер вдвое. ¹

Имейте в виду, что обычно больше ядер НЕ лучше, чем более БЫСТРЫЕ ядра. Фактически, единственная причина, по которой так много работы было вложено в разработку многоядерных систем, заключается в том, что становилось все труднее создавать более быстрые и быстрые. . Так что, если у вас не может быть процессора с частотой 20 ГГц, вам потребуется процессор 8 x 3 ГГц.

Я считаю, что HT в первую очередь предназначен как преимущество в контекстах, где каждый поток не обязательно поглощает столько процессора, сколько может; он выполняет какую-то конкретную задачу, которая регулируется взаимодействием с пользователем, например, элементы САПР, видеоигры и т. д .; это те приложения, которые выигрывают от многозадачности. Напротив, серверные платформы, на которых основные приложения обычно выполняют независимые от потоков задачи, которые не зависят от чего-либо еще и поэтому оптимально выполняются как можно быстрее, не получают непосредственной выгоды от использования нескольких -задача; им выгодна скорость. make находится в той же категории, хотя, возможно, с большей степенью взаимозависимости между потоками, поэтому вы видите преимущество HT от 4-8 потоков.

^{1. Это упрощение. HT не просто удваивает количество ядер и вдвое снижает их скорость, но какая бы динамика ни использовалась, общее количество циклов процессора в секунду для системы не улучшается. То же самое, только более фрагментированное.}