Назад | Перейти на главную страницу

Стоит ли отключать гиперпоточность?

У меня большая работа, и я экспериментирую с топологией, чтобы увидеть, что дает лучшие результаты (игра с ntasks, ncores-per-cpu, nodesи т. д.) Я использую slurm в качестве администратора очередей работы.

У меня есть два узла (CentOS 7, управляемый с помощью Bright 7), каждый из которых имеет 2xIntel (R) Xeon (R) CPU E5-2680 v3 @ 2.50GHz. Итак, два процессора с 12 ядрами, все гиперпоточные, так что у меня 48 ядер на узел. (См. Ниже топологию процессора lstopo дает)

Мой вопрос: в BIOS отключить гиперпоточность или попробовать отключить в SLURM? Или просто относитесь к моей системе, как к двойному числу ядер? Указание --thread-per-core=1 похоже, не действует.

Моя работа - это большая модель среды, множество операций ввода-вывода, множество матричных вычислений и т. Д., И сейчас на ее выполнение уходит несколько дней.

Я читал SLURM FAQ, но я все еще не понимаю, как действовать дальше.

В принципе, если вы чувствуете, что ваши операции выиграют от более свободного кеша L2 / L3, который возможен при отключенном HT, продолжайте и отключите HT в BIOS.

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

VMWare ESXi и Hyperthreading

http://lifehacker.com/how-hyper-threading-really-works-and-when-its-actuall-1394216262

Slurm распределяет по ядрам, SLURM был разработан для переносимости, а не для производительности. Таким образом, он распределяется следующим образом: «Обратите внимание, что даже в системах с включенной гиперпоточностью ресурсы обычно распределяются для заданий на уровне ядра (см. ПРИМЕЧАНИЕ ниже). Два разных задания не будут совместно использовать ядро». Он знает, что такое гиперпоточность, и его можно включить, но он специально смотрит на количество ядер на сокет. Это открытый исходный код, и я уверен, что оптимизация гиперпотоков в порядке.