Ускорение MPI с тривиально распараллеливаемой петлей DO (F90)

Question

У меня есть простой цикл DO (Fortran 90), в котором отдельные итерации независимы друг от друга и только данные ввода / вывода с / на жесткий диск (процессы не обмениваются сообщениями /MPI между собой), которые я распараллелил используя MPI. При последовательном запуске одна итерация цикла занимает около одного дня. Если я запускаю 29 таких итераций параллельно, это займет около 2,5 дней. Он находится на одном узле суперкомпьютера (т. Е. Нет связи между междоузлиями).

Я слышал, как люди говорили, что в случае тривиально распараллеливаемых программ (независимых шагов в циклах) общее время выполнения должно быть приблизительно равно времени выполнения, когда вы выполняете только один шаг в цикле.

Вопрос: Это ускорение выглядит хорошо для вас?

Большое спасибо.

Answer 1

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

• у вас недостаточно памяти на вашем вычислительном узле, чтобы все процессы и их данные поместились в памяти;
• вычисления не сбалансированы между итерациями;
• Есть много дискового ввода / вывода, которые создают гонку на доступ к диску.
• и, возможно, некоторые другие, которые я не имею в виду.

Answer 2

Таким образом, вы работаете примерно вдвое быстрее, чем надеялись, когда масштабируете до 29 параллельных копий своего кода?

Может возникнуть проблема с пропускной способностью памяти, поскольку 29 копий одного и того же алгоритма считывают / записывают собственную память одновременно. Вот почему в таком случае было бы потенциально лучше (но гораздо сложнее) искать параллелизм за одну итерацию.

Давайте использовать кодирование видео в качестве конкретного примера того, какой может быть "одна итерация". Например, параллельное кодирование 29 видео похоже на то, что предлагает ОП. Если x264 использует 32 ядра для кодирования одного видео, то повторяет это для следующих 28 видео, использует гораздо меньше общего объема ОЗУ и лучше кэширует.

На практике, возможно, 2 или 3 параллельных видео, каждое из которых использует от 10 до 16 потоков, было бы хорошо, так как есть предел тому, сколько параллелизма может найти x264.

Это зависит от алгоритма и от того, насколько хорошо он масштабируется с помощью нескольких потоков. Если нет, или у вас нет времени, чтобы закодировать его, то используйте всю грубую силу. Фактор ускорения более 10 - это не то, что нужно чихать, потому что никаких усилий не происходит. (например, запуск однопоточной программы на разных наборах данных с make -j29 или GNUparallelили в вашем случае использование нескольких потоков в одной программе.:)

Пока ваш код работает, вы можете проверить загрузку ЦП, чтобы убедиться, что вы загружаете 29 ядер ЦП, как пытаетесь. Вы также можете использовать инструмент профилирования (например, Linux perf) исследовать эффекты кэша. Если параллельный прогон имеет более чем 29-кратное количество пропусков кэша данных однопоточного прогона, это может начать объяснять.