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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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