У нас есть 12-ядерный MacPro для выполнения некоторых расчетов методом Монте-Карло. В его процессорах Intel Xeon включена технология Hyper-Threading (HT), поэтому на самом деле должно быть 24 параллельных процесса, чтобы они были полностью использованы. Однако наши расчеты более эффективны для работы в режиме 12x100%, чем 24x50%, поэтому мы попытались отключить Hyper-Threading через панель Processor в системных настройках, чтобы повысить производительность. Можно также отключить HT,
hwprefs -v cpu_ht=false
Затем мы провели несколько тестов и вот что мы получили:
- К нашему разочарованию, 12 параллельных задач выполняются одновременно с HT или без него.
- 24 параллельных задачи теряют 20%, если HT выключен (а не -50%, как мы думали)
- При включенном HT переключение с 24 на 12 задач снижает эффективность на 20% (тоже удивительно)
- При выключенном HT переключение с 24 на 12 ничего не меняет.
Похоже, что Hyper-Threading просто снижает производительность наших вычислений и избежать этого никак нельзя. Программа, которую мы используем для вычислений, написана на Фортране и скомпилирована с помощью gfortran. Есть ли способ сделать его более эффективным с этим железом?
Обновление. Наши расчеты методом Монте-Карло (MCC) обычно выполняются поэтапно, чтобы избежать потери данных и по другим причинам (этих шагов избежать не всегда возможно). В нашем случае каждый шаг состоит из множества симуляций с переменной продолжительностью. Поскольку каждый шаг разделен между несколькими параллельными задачами, они также имеют разную продолжительность. По сути, все более быстрые задачи должны ждать, пока не будут выполнены самые медленные. Этот факт заставляет нас делать более крупные шаги, которые заканчиваются с меньшим отклонением во времени за счет усреднения, чтобы процессоры не тратили время на ожидание. Это наша мотивация иметь 12*2,66 ГГц вместо 24*1,33 ГГц. Если бы можно было отключить HT, то мы бы получили примерно +10% производительности, переключившись с 24 задач с HT на 12 задач без HT. Однако тесты показывают, что мы теряем 20%. Так что мой вывод таков, что расчет на 30% неэффективен.
Для тестов я использовал довольно большие шаги, однако обычно шаги короче, поэтому эффективность становится еще выше.
Есть еще одна причина — для некоторых наших расчетов требуется 3-5 ГБ памяти, так что вы, наверное, видите, насколько экономично было бы для нас иметь 12 быстрых задач. Мы работаем над реализацией разделяемой памяти, но это будет долгосрочный проект. Поэтому нам нужно выяснить, как сделать существующее аппаратное/программное обеспечение максимально быстрым.
