Отзыв на отчет по тестированию HW и SW Intel, установленного

Отзыв
на отчет по тестированию HW и SW Intel, установленного на кластере IBM 1350
Очень интересные результаты. Особенно попытка использования смешанного распараллеливания
с помощью MPI + OMP.
В последнее время наблюдается очень большой интерес к такому смешиванию. К тому несколько
причин (естественно, вы их знаете, раз уж экпериментируете со смешиванием)
1) появление мощных кластеров – тысячи узлов; использование процессоров с несколькими
ядрами. Обычные реализации MPI не могут задействовать все эти ядра хотя бы потому, что имеют
какое-то ограничение на количество процессов (масштабируемость, поддержка коннектов/связей)
2) обмен между процессами (на узле) существенно медленнее, чем между потоками
3) наверняка вы можете продолжить этот список
Я вижу, что вы тоже столкнулись с трудностями, которые привносит неоднозначная нумерация
процессоров под Linux. Ситуация даже сложнее, т.к. мы видели кластера, где нумерация на одном
узле отличается от нумерации на другом. Включенный hyper-threading привносит свою лепту в
неразбериху.
Наша библиотека (версия 3.0, что вы использовали) не была предназначена для смешанного (MPI
+ OMP) выполнения. Нужно было явно задавать номера процессоров, на которых вы хотите
закрепить процессы. Из-за неоднозначности нумерации процессоров трудно получить желаемое
распределение процессов по процессорам. И если процесс создавал вычислительные потоки, то
они наследовали закрепление родителя. В конечном итоге процесс и потоки закрепляются на
одном процессоре, что ухудшает производительность. Выходом является либо отказ от
закрепления (в итоге получаем нестабильность результатов), либо руками создавать и закреплять
потоки (как раз хорошо продемонстрирован в примере из вашего отчета).
Это не есть хорошо, поэтому мы реализовали версию (выпущен буквально на днях и будет
доступен пользователям в течение 1-2 недель), которая имеет специальный механизм для
удобного и гибкого задания распределения процессов, гибридного MPI + OMP выполнения,
закрепления создаваемых потоков независимо от родительского процесса.
И этот механизм работает согласно пожеланию пользователя независимо от кластера с его
нумерацией.
Очень удобно. Например, чтобы процессы легли на сокеты, а потоки распределились между
ядрами в сокете.
Точки приложения в ваших исследованиях очень важны.
Например:
Влияние привязки процессов и потоков к ядрам узла на скорость обмена данными.
Вы можете видеть разницу в 2-3 раза при правильной (или неправильной) привязке
Влияние шины на пропускную способность памяти при различных способах обхода массива.
Это не MPI часть, а больше оптимизация программы. Могу сравнить с последовательным
доступом к памяти (что хорошо) и с каким-то шагом (что плохо из-за промахов по кэшу)
Возможно, вы тут немного другое имели в виду
Исследование конкурентного доступа к памяти
Может быть регулировано целевым распределением процессов
Я бы рекомендовал использовать для ваших дальнейших исследований нашу последнюю версию
Intel MPI 3.1.1. Нам были бы полезны ваши отзывы.
Нам бы хотелось приехать к вам на семинар и рассказать о новых возможностях Intel MPI и Intel
Trace Collector & Analyzer.
Герман Воронова Intel, Саров