Как гиперпоточность влияет на распараллеливание?
Я использую OpenMP код на гиперпоточном процессоре.
Если бы все остальные были равны, как изменится производительность на не-HyperThreaded CPU?
Я замечаю 100% загрузку процессора, независимо от того, сколько потоков я запускаю, но изменение количества потоков повышает производительность. Как это может быть?
Одинакова ли история для многопоточных процессоров не INTEL?
Решение
Улучшение производительности (если оно есть) от гиперпоточности предсказать сложно.
Гиперпоточность означает, что если один поток останавливается по (почти) какой-либо причине, ЦП будет иметь пул инструкций из другого потока для (попытки) выполнения. Даже без реального останова, если запланированы два потока, которые используют разные ресурсы выполнения, инструкции от обоих могут выполняться одновременно на одном и том же ядре. Таким образом, если, например, код сильно зависит от задержки основной памяти (например, непредсказуемые шаблоны чтения без предварительной выборки), гиперпоточность может существенно повысить производительность.
С другой стороны, если код тщательно написан, чтобы покрыть задержку за счет осторожного использования кэша, предварительной выборки и т. Д., Он может получить мало или вообще ничего от гиперпоточности. Особенно в старых ОС, которые не пытаются учитывать гиперпоточность в планировании потоков, дополнительные потоки могут фактически привести к дополнительным переключениям контекста, что замедляет общее выполнение.
Предполагая, что вы начинаете с полностью однопоточного кода, и добавляете некоторые директивы OpenMP, мой собственный опыт заключается в том, что Hyperthreading, как правило, хорош для повышения производительности на порядок или на 10%. Если код делает почти любую попытку префектирования или чего-либо подобного, большая часть (если не все) этого преимущества почти сразу испаряется.
Другие решения
Других решений пока нет …