Преимущества гиперпоточности для многопроцессорной обработки?

Я управляю вычислительным узлом в кластере HTC. Узел представляет собой двухпроцессорную машину Xeon с 56 ядрами и 112 потоками, а типичная рабочая нагрузка состоит из множества экземпляров однопоточных заданий моделирования методом Монте-Карло. Тесты показывают, что пропускная способность хорошо масштабируется с количеством заданий примерно до 56, с некоторой нелинейностью из-за частот турбонаддува, которые не поддерживаются для большого количества активных заданий. Все это имеет смысл для меня, и я бы сказал, что это ожидаемое поведение.

То, что я не совсем понимаю, заключается в том, что масштабирование почти полностью теряется для большего количества заданий. При увеличении количества заданий до 64 и выше до 112 пропускная способность остается неизменной: преимущество от параллельного выполнения большего количества заданий полностью компенсируется более продолжительным выполнением одного задания. Я знаю, что масштабирование далеко не линейно для гиперпоточности, но нулевое масштабирование меня немного удивило.

Основываясь на моих крайне ограниченных знаниях о принципе работы гиперпоточности, я предполагаю, что он может быть эффективен для запуска двух потоков одного и того же процесса, но не для запуска двух отдельных процессов. Мне нужно какое-то подтверждение об этом, чтобы определенно исключить гипотезы о неисправности и, в конечном итоге, отключить гиперпоточность.

Упрощенная гиперпоточность использует тот факт, что во многих потоках процессов существует время простоя, когда ядро ​​обычно ожидает завершения других задач. При переключении между двумя потоками ядро ​​процессора не будет простаивать при ожидании в одном потоке, а сможет сделать что-то полезное в другом потоке. Видеть https://www.intel.com/content/www/us/en/gaming/resources/hyper-threading.html

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

Плохая аналогия: Hyper-Threading, или вообще SMT, похожа на собственность для отдыха в режиме таймшера. Планирование всех 52 недель в году — это нормально, каждый получает место для себя. Привлеките еще пару человек к этой схеме, возможно, они даже все еще работают, используйте время, когда помещения в противном случае простаивают из-за отмен. Но большее количество двойных бронирований волшебным образом не превратит один дом в два.

Ядра ЦП имеют несколько различных типов исполнительных блоков: целочисленные, с плавающей запятой и другие. Но только так много. (Существуют блок-схемы, чтобы увидеть их в конструкции ЦП, см., Например, Каскадное озеро.) Суперскалярные архитектуры пытаются выжать несколько инструкций за такт уже. Таким образом, хотя другой аппаратный поток может заимствовать неиспользуемую целочисленную единицу для цикла, он должен делиться ею. А память всегда слишком медленная, скорее всего DRAM и пропускная способность шины являются реальными ограничивающими факторами.

Тестирование постепенного увеличения количества заданий — отличный способ увидеть убывающую отдачу от SMT. Особенно с вашей высокой вычислительной нагрузкой HTC, которая, вероятно, довольно стабильна и предсказуема. Ваши 115% процессоров - это примерно то, что я ожидал. Нет смысла идти выше.