Проба пера на суперкомпьютере Ломоносов

image

В этом посте я хочу рассказать о своём опыте расчётов на суперкомпьютере Ломоносов. Я расскажу о решении задачи, честно говоря, для которой не нужно использовать СК, но академический интерес превыше всего. Подробную информацию о конфигурации Ломоносова можно найти тут.

Скорость передачи данных между узлами/процессами


Сначала я решил провести простой тест пропускной способности кластера, и сравнить на сколько отличаются скорости передачи данных от одного потока другому а) если оба потока запущены на одном узле кластера; б) на разных. Следующие значения оценены с помощью теста mpitests-osu_bw.
Пиковая скорость на разных узлах:
3,02 ГБайт/с.
На одном узле:
10,3 ГБайт/с

Немного о задаче


Нужно решить уравнение диффузии на довольно простой области.


image

Мы имеем линейное уравнение в ч.п. Будем его решать без потока, т.е. на границах 1, 2, 4 производная по нормали к стенке 0, а на границе 3 концентрация определяется заданной функцией g(t). Таким образом мы получаем смешанную краевую задачу. Будем решать её методом конечных разностей (очень не эффективно, зато просто).

О распараллеливании


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

image

Параметры сетки используемые при вычислениях

Количество узлов в сетке: 3*10^6
Шаг по сетке: 0.0007.
Физическое время диффузии: 1 с
Шаг по времени: 6,5*10^-7
D: 0.8
Начальная концентрация на границе 3 0,01 моль.

Немного о законе Амдала


Джим Амдал сформулировал закон, иллюстрирующий ограничение производительности вычислительной системы с увеличением числа вычислителей. Предположим, что необходимо решить какую-либо вычеслительную задачу. Пусть α- доля алгоритма которая выполняется последовательно. Тогда, соответственно, 1-α выполняется параллельно и может быть распараллелена на p-узлах, тогда ускорение полученное на вычислительной системы можно получить как



Перейдём к самому интересному к результатам и результатам распараллеливания




Времена выполнения на различном количестве потоков

кол-во проц. 1 2 8 16 32 64 128
время, мин. 840 480 216 112 61 46 41

Аппроксимируем времена вычисления законом Амдала.

Из аппроксимации я получил долю последовательного кода порядка 4,2% и максимальное ускорение порядка 20 раз. Как видно из графика кривая выходит на плато, из этого можно сделать вывод, что достигается максимум ускорения и дальнейшее увлечение числа процессоров нецелесообразно. Более того в данном случае при увеличении числа процессов более 200 я получил спад ускорения, это связано с тем, что при увеличении числа процессов начинается нерациональное их использование, т.е. количеств строк в сетке становится соизмеримым с числом процессов и затрачивается больше времени на обмены и это время вносит заметный вклад во время вычислений.

Некоторые замечания


На СК используется система управления задачами sbatch и имеется несколько очередей test, regular4, regular6, gputest, gpu. Для данной задачи я использовал очередь regular4 время ожидания в которой может достигать трёх суток (на практике же время ожидания 17-20 часов).

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 26

  • UFO just landed and posted this here
      0
      Я бы сказал, что скорее на 64.
      • UFO just landed and posted this here
          +1
          Ну если смотреть по ресурсам то да. Просто у меня практически не было ограничения ресурсов, я мог использовать хоть 256, хоть 512 ядер.
        +3
        Ну это для этой конкретной задачи такое оптимальное соотношение. Если вы считаете интегралл, то последовательная часть у вас – это разделить область интегрирования и раздать процессорам задачи, потом все собрать и просуммировать. Ускорение будет почти совподать с количеством процессоров. Если же считаете методом пррогонки, то оптимальным будет использовать один процессор.
          0
          промазал
          +3
          Скорость MPI очень странная, похоже infiniband не используется как транспорт MPI.
          Для QDR инфинибенда на больших пакетах MPI bandwidth в одну сторону должна выходить на 3-4ГБайт\с.
          Задержки при этом около единиц микросекунд.
          Измерить можно или утилитами из драйверов OFED или intel MPI benchmark, обе у Вас должны быть.

          И второе, обмен между MPI процессами на одном узле должна быть намного больше, потому как используется что-то типа shared memory транспорта, несколько ГБайт\с минимум.

            +1
            Это в случае больших пакетов. И там указаны усреднённое значение скорости, максимум для разных узлов порядка 1,162 Гбайт/с, а для одного 1,34 ГБайт/с. Я посмотрю попозже что дают intel MPI benchmark, OFED.
              +1
              Более 8МБ пакеты — это уже очень большие пакеты.
              Тот же intel MPI benchmark меряет по-умолчанию с размером пакетов от 0 до 4МБ всего.
              На полку выходит уже начиная с размеров пакета в десятки КБ.
              Например, со старыми двухпортовыми 10ГБит инфинибенд картами скорость примерно 1600МБайт\с.
              Задержки около 4мкс.
              Ваши значения скорее типичны для 10Гбит ethernet, проверить наверное можно тестом задержек.
              Для инфинибенд это единицы мкс, для ethernet — десятки мкс.
              Поищите в составе openmpi тесты
              mpitests-osu_bw
              mpitests-osu_latency

                +2
                Для разных узлов:

                # OSU MPI Bandwidth Test v3.1.1
                # Size Bandwidth (MB/s)
                2097152 3091.82
                4194304 3092.35
                Для одного узла:
                # OSU MPI Bandwidth Test v3.1.1
                8192 8572.19
                16384 10694.34
                32768 10143.10
                65536 10544.98
                131072 9920.87
                262144 9718.30
                524288 9574.27
                1048576 9414.37
                2097152 7285.71
                4194304 5447.32


                Исправлю
                  +1
                  Ну вот это ближе к правде для QDR инфинибенд.
                  Почему собственно и удивили Ваши измерения в 1000-1200МБайт\с.
            +1
            Добавлю, что оценить долю последовательного кода трудно оценить из такого подхода.
            Даже имея полностью параллельный код, Вы выйдете на полочку, потому как
            время коммуникаций растет пропорционально числу потоков и обязательно когда-нибудь превысит время расчетов, которое уменьшается с ростом потоков. :-)
              +4
              Автор, интересно было бы узнать какие вообще сейчас решают задачи на ваших суперкомпьютерах. Конкретно, начали ли их использовать для решения прикладных задач или только учебные? Какие компиляторы используются? По вашей ссылке я вижу, что сейчас есть возможность компилировать C++. Раньше был только С. Сами на чем писали? Какой стандарт C++ поддерживается?
                +5
                Ну про Ломоносов, могу сказать что на нём считаются метеорологи, когда-то(не уверен, что сейчас или вообще когда-либо, ходил слух) вояки, химики. Про физику могу сказать считают разные задачи от эмиссии атомов, аэродинамики, каких-то квантовых систем до динамики гемостаза (свёртывания, моя группа этим занимается) и многие другие задачи.
                Ну я начал с учебной вот потихоньку перехожу на прикладные задачи. Процесс свёртывания крови нелинейный, в нём наблюдаются автоволновые процессы, разумеется такие задачи в потоке крови моделируются на Ломоносове. Я сейчас в процессе присоединения к этой научной группе, и только набираюсь опыта в мат моделировании.
                Друзья предлагали устроить биткоин ферму.
                Что касается компиляторов, то можно использовать fortran, pure C, C++ v 4,4,6 по-моему в этой версии нет поддержки 11 стандарта(поправьте если не так), icc -v 13.1.0. Я писал на обычном C.
                  0
                  А ещё вспомнил даже есть возможность на самих вычислительных узлах запускать bash-скрипты.
                    +3
                    Описание задачи для sbatch собственно и является bash-скриптом. Благодаря этому там можно реализовывать довольно сложную логику счёта.
                    +3
                    Меня очень заинтересовали автоволновые процессы в нелинейной системе свёртывания крови. Не могли бы вы дать ссылки на свои публикации или ключевые публикации научной группы, в которой работаете?
                      +1
                      В 4.4.6(если вы пр gcc) есть поддержка 0x, чего впринципе в большинстве случаев хватает, чтобы компилировать написанные на C++11 программы.
                        +1
                        Пожалуйста мотивируйте своих руководителей делать проекты для платформы BOINC ( boinc.berkeley.edu ). Сообщество с радостью будет считать российские проекты, особенно такие интересные.

                        p.s: суперкомпьютеры это хорошо, но сложно, а распределённые вычисления проще для научных групп, поскольку не нужно иметь доступ к мейнфрейму.
                      +4
                      Трое суток — это максимальное время выполнения одной задачи. Со временем стояния задачи в очереди оно никак не связано.

                      К сожалению, Ломоносов уже давно не торт. После его перевода на многоуровневую СХД (технических деталей я не смогу описать, правда) постоянно возникает огромное количество проблем именно с файловым вводом-выводом.
                        +3
                        Да — это лимит времени выполнения одной задачи на regular на тесте, например, это 15 минут, я думал, что обычно время ожидания не превышает максимальное время счёта.

                        Вы имеете ввиду переход на 3 уровня хранения данных архивное (_backup), основное (на узле к которому подключаемcя по ssh) и с быстрым доступом или как там его (_scratch)? А какие проблемы возникают? Просто у знакомых на некоторых очередях вообще не создаются файлы даже лог запуска slurm*.out, не знаю почему и тех поддержка не помогла.
                          0
                          Время ожидание не ограничено ничем. Может быть существенно больше, чем запрошенное время счета.

                          Проблемы с файловой системой простые: при создании нового файла с некоторой долей вероятности файловый ввод-вывод зависает, ожидая, видимо, синхронизации буферов или чего-то еще такого. Ожидание продолжается до тех пор пока система не убивает задачу по лимиту времени. Это первый вариант.

                          Второй вариант более изощренный. В процессе моделирования у нас записывается «траектория» системы (бинарный файл с достаточно сложной структурой), которая является основным результатом моделирования. При этом счет иногда падает по не зависящим от нас причинам. Если счет упал, то его можно продолжить, используя файл с промежуточным состоянием системы. После перехода на новую СХД оказалось, что перезапустить счет на продолжение с использованием промежуточного файла можно только два раза. После третьего раза файл с траекторией оказывается поврежденным и использовать его дальше нельзя. Почему это происходит — никто не знает. Служба поддержки помочь не смогла.
                          +2
                          Он был торт только первый год :)
                            0
                            Согласен. :)
                          0
                          Было бы интересно посмотреть ускорения в режиме умножения.
                            –2
                            Интересно, какие задачи на нем будут решаться?

                            Only users with full accounts can post comments. Log in, please.