Оптимальное количество потоков для вычисляет - интенсивная задача на сервере с Гиперпоточностью
Я не отказался бы администратору от него. Кроме того, если у Вас нет очень занятого сервера, я задался бы вопросом точно, сколько из хита производительности на самом деле происходит из-за него. Это - одна вещь видеть, что раздел не выравнивается, это - совсем другой, чтобы доказать, что это - причина проблем производительности. Вы выполнили какой-либо perfmon или другую диагностику для подтверждения подозрений?
8 потоков были бы идеальными, если предположить, что нет значительных дополнительных накладных расходов на объединение результатов или что-то подобное. При наличии только четырех потоков любые исполнительные блоки, которые не могут быть насыщены одним потоком на виртуальное ядро, будут потрачены впустую. Их можно использовать с восемью потоками.
Обратите внимание, что это относится только к нереалистичному предположению, что каждый поток может насыщать ядро. Кроме того, он может не применяться, если разделение ресурсов кэша процессора отрицательно сказывается на производительности. Некоторые задачи имеют производительность, которая «падает с обрыва» при определенном размере кэша. Если ваш разрыв находится между полным размером кэша физического ядра и половиной этого размера кэша, то четыре потока могут быть лучше.
Доктрина, которой меня учили при компиляции, была в 1,5 раза больше количества ядер. Это учитывает любое время, когда поток / процесс ожидает ввода-вывода.
Если ваша задача не имеет шансов заблокировать более медленные операции, такие как ввод-вывод, то может не быть необходимости превышать количество ядер, но если это может, вам нужно больше процессов, чем ядер.
Посмотрите на это с другой стороны: если у вас четыре ядра и три процесса, вы никогда не сможете достичь 100% ЦП. То же самое верно для четырех процессов, когда один из них блокирует ввод-вывод. Если у вас есть шесть процессов без блокировки, вы можете быть немного менее эффективными, поскольку ядро использует некоторое время ЦП, переключая процессы между четырьмя ядрами, но ни одно ядро никогда не простаивает.
К сожалению, я понятия не имею о физический / виртуальный аспект вашего вопроса.
Я предполагаю, что оптимально использовать одну задачу на ядро и отключить гиперпоточность.
Если я запущу столько потоков с интенсивным процессором, сколько у меня есть логических ядер, у меня будут быстрые переключения контекста для задач с интенсивным использованием процессора, но дорогие для фоновых задач, поскольку гиперпоточность полностью используется задачами с интенсивным использованием процессора. С другой стороны, если я запустил столько потоков с интенсивным использованием процессора, сколько у меня физических ядер, у меня не будет переключений контекста для этих задач и быстрых переключений контекста для фоновых задач. Выглядит неплохо,но фоновые задачи найдут свободные логические процессоры и будут запускаться почти мгновенно. Как будто они выступают в реальном времени (хорошо -20).
Я не знаю, насколько быстро происходит переключение контекста между двумя задачами на одном ядре. Также я боюсь, что совместное использование кеша между двумя потоками на одном ядре снизит частоту попаданий в кеш (если только они не запускают одну и ту же программу размером менее 1 МБ). Сомневаюсь, что без штрафных санкций. Мне кажется, что сложная задача с интенсивным использованием ЦП будет выполняться быстрее для одной задачи на ядро, чем одна задача на виртуальный процессор. Но если вы сделаете это, вы оставите два виртуальных процессора свободными, а фоновые задачи получат приоритет, которого у них не должно быть.
В первом сценарии гиперпоточность используется, фоновые задачи будут использовать дорогостоящие переключатели контекста, потому что я максимизировал гиперпоточность с нормальная обработка. Второй вариант неприемлем, потому что до 50% мощности моего процессора отдается приоритетным фоновым задачам.
Обычно я отключаю гиперпоточность на моем рабочем столе и серверах Intel. Я показываю как это делается в https://serverfault.com/a/720471/309821 .
Но это основано на предположениях. Мне кажется, что это лучше, но, возможно, это не так.