Комментарии 26
Правильно ли я понял, что оптимальное соотношение «количество-процессоров/ускорение» достигается при 32 процессорах (ядрах)?
Я бы сказал, что скорее на 64.
Ну это для этой конкретной задачи такое оптимальное соотношение. Если вы считаете интегралл, то последовательная часть у вас – это разделить область интегрирования и раздать процессорам задачи, потом все собрать и просуммировать. Ускорение будет почти совподать с количеством процессоров. Если же считаете методом пррогонки, то оптимальным будет использовать один процессор.
промазал
Скорость MPI очень странная, похоже infiniband не используется как транспорт MPI.
Для QDR инфинибенда на больших пакетах MPI bandwidth в одну сторону должна выходить на 3-4ГБайт\с.
Задержки при этом около единиц микросекунд.
Измерить можно или утилитами из драйверов OFED или intel MPI benchmark, обе у Вас должны быть.
И второе, обмен между MPI процессами на одном узле должна быть намного больше, потому как используется что-то типа shared memory транспорта, несколько ГБайт\с минимум.
Для QDR инфинибенда на больших пакетах MPI bandwidth в одну сторону должна выходить на 3-4ГБайт\с.
Задержки при этом около единиц микросекунд.
Измерить можно или утилитами из драйверов OFED или intel MPI benchmark, обе у Вас должны быть.
И второе, обмен между MPI процессами на одном узле должна быть намного больше, потому как используется что-то типа shared memory транспорта, несколько ГБайт\с минимум.
Это в случае больших пакетов. И там указаны усреднённое значение скорости, максимум для разных узлов порядка 1,162 Гбайт/с, а для одного 1,34 ГБайт/с. Я посмотрю попозже что дают intel MPI benchmark, OFED.
Более 8МБ пакеты — это уже очень большие пакеты.
Тот же intel MPI benchmark меряет по-умолчанию с размером пакетов от 0 до 4МБ всего.
На полку выходит уже начиная с размеров пакета в десятки КБ.
Например, со старыми двухпортовыми 10ГБит инфинибенд картами скорость примерно 1600МБайт\с.
Задержки около 4мкс.
Ваши значения скорее типичны для 10Гбит ethernet, проверить наверное можно тестом задержек.
Для инфинибенд это единицы мкс, для ethernet — десятки мкс.
Поищите в составе openmpi тесты
mpitests-osu_bw
mpitests-osu_latency
Тот же intel MPI benchmark меряет по-умолчанию с размером пакетов от 0 до 4МБ всего.
На полку выходит уже начиная с размеров пакета в десятки КБ.
Например, со старыми двухпортовыми 10ГБит инфинибенд картами скорость примерно 1600МБайт\с.
Задержки около 4мкс.
Ваши значения скорее типичны для 10Гбит ethernet, проверить наверное можно тестом задержек.
Для инфинибенд это единицы мкс, для ethernet — десятки мкс.
Поищите в составе openmpi тесты
mpitests-osu_bw
mpitests-osu_latency
Для разных узлов:
# OSU MPI Bandwidth Test v3.1.1
# Size Bandwidth (MB/s)
2097152 3091.82
4194304 3092.35
Исправлю
# 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
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
Исправлю
Добавлю, что оценить долю последовательного кода трудно оценить из такого подхода.
Даже имея полностью параллельный код, Вы выйдете на полочку, потому как
время коммуникаций растет пропорционально числу потоков и обязательно когда-нибудь превысит время расчетов, которое уменьшается с ростом потоков. :-)
Даже имея полностью параллельный код, Вы выйдете на полочку, потому как
время коммуникаций растет пропорционально числу потоков и обязательно когда-нибудь превысит время расчетов, которое уменьшается с ростом потоков. :-)
Автор, интересно было бы узнать какие вообще сейчас решают задачи на ваших суперкомпьютерах. Конкретно, начали ли их использовать для решения прикладных задач или только учебные? Какие компиляторы используются? По вашей ссылке я вижу, что сейчас есть возможность компилировать C++. Раньше был только С. Сами на чем писали? Какой стандарт C++ поддерживается?
Ну про Ломоносов, могу сказать что на нём считаются метеорологи, когда-то(не уверен, что сейчас или вообще когда-либо, ходил слух) вояки, химики. Про физику могу сказать считают разные задачи от эмиссии атомов, аэродинамики, каких-то квантовых систем до динамики гемостаза (свёртывания, моя группа этим занимается) и многие другие задачи.
Ну я начал с учебной вот потихоньку перехожу на прикладные задачи. Процесс свёртывания крови нелинейный, в нём наблюдаются автоволновые процессы, разумеется такие задачи в потоке крови моделируются на Ломоносове. Я сейчас в процессе присоединения к этой научной группе, и только набираюсь опыта в мат моделировании.
Друзья предлагали устроить биткоин ферму.
Что касается компиляторов, то можно использовать fortran, pure C, C++ v 4,4,6 по-моему в этой версии нет поддержки 11 стандарта(поправьте если не так), icc -v 13.1.0. Я писал на обычном C.
Ну я начал с учебной вот потихоньку перехожу на прикладные задачи. Процесс свёртывания крови нелинейный, в нём наблюдаются автоволновые процессы, разумеется такие задачи в потоке крови моделируются на Ломоносове. Я сейчас в процессе присоединения к этой научной группе, и только набираюсь опыта в мат моделировании.
Друзья предлагали устроить биткоин ферму.
Что касается компиляторов, то можно использовать fortran, pure C, C++ v 4,4,6 по-моему в этой версии нет поддержки 11 стандарта(поправьте если не так), icc -v 13.1.0. Я писал на обычном C.
А ещё вспомнил даже есть возможность на самих вычислительных узлах запускать bash-скрипты.
Меня очень заинтересовали автоволновые процессы в нелинейной системе свёртывания крови. Не могли бы вы дать ссылки на свои публикации или ключевые публикации научной группы, в которой работаете?
В 4.4.6(если вы пр gcc) есть поддержка 0x, чего впринципе в большинстве случаев хватает, чтобы компилировать написанные на C++11 программы.
Пожалуйста мотивируйте своих руководителей делать проекты для платформы BOINC ( boinc.berkeley.edu ). Сообщество с радостью будет считать российские проекты, особенно такие интересные.
p.s: суперкомпьютеры это хорошо, но сложно, а распределённые вычисления проще для научных групп, поскольку не нужно иметь доступ к мейнфрейму.
p.s: суперкомпьютеры это хорошо, но сложно, а распределённые вычисления проще для научных групп, поскольку не нужно иметь доступ к мейнфрейму.
Трое суток — это максимальное время выполнения одной задачи. Со временем стояния задачи в очереди оно никак не связано.
К сожалению, Ломоносов уже давно не торт. После его перевода на многоуровневую СХД (технических деталей я не смогу описать, правда) постоянно возникает огромное количество проблем именно с файловым вводом-выводом.
К сожалению, Ломоносов уже давно не торт. После его перевода на многоуровневую СХД (технических деталей я не смогу описать, правда) постоянно возникает огромное количество проблем именно с файловым вводом-выводом.
Да — это лимит времени выполнения одной задачи на regular на тесте, например, это 15 минут, я думал, что обычно время ожидания не превышает максимальное время счёта.
Вы имеете ввиду переход на 3 уровня хранения данных архивное (_backup), основное (на узле к которому подключаемcя по ssh) и с быстрым доступом или как там его (_scratch)? А какие проблемы возникают? Просто у знакомых на некоторых очередях вообще не создаются файлы даже лог запуска slurm*.out, не знаю почему и тех поддержка не помогла.
Вы имеете ввиду переход на 3 уровня хранения данных архивное (_backup), основное (на узле к которому подключаемcя по ssh) и с быстрым доступом или как там его (_scratch)? А какие проблемы возникают? Просто у знакомых на некоторых очередях вообще не создаются файлы даже лог запуска slurm*.out, не знаю почему и тех поддержка не помогла.
Время ожидание не ограничено ничем. Может быть существенно больше, чем запрошенное время счета.
Проблемы с файловой системой простые: при создании нового файла с некоторой долей вероятности файловый ввод-вывод зависает, ожидая, видимо, синхронизации буферов или чего-то еще такого. Ожидание продолжается до тех пор пока система не убивает задачу по лимиту времени. Это первый вариант.
Второй вариант более изощренный. В процессе моделирования у нас записывается «траектория» системы (бинарный файл с достаточно сложной структурой), которая является основным результатом моделирования. При этом счет иногда падает по не зависящим от нас причинам. Если счет упал, то его можно продолжить, используя файл с промежуточным состоянием системы. После перехода на новую СХД оказалось, что перезапустить счет на продолжение с использованием промежуточного файла можно только два раза. После третьего раза файл с траекторией оказывается поврежденным и использовать его дальше нельзя. Почему это происходит — никто не знает. Служба поддержки помочь не смогла.
Проблемы с файловой системой простые: при создании нового файла с некоторой долей вероятности файловый ввод-вывод зависает, ожидая, видимо, синхронизации буферов или чего-то еще такого. Ожидание продолжается до тех пор пока система не убивает задачу по лимиту времени. Это первый вариант.
Второй вариант более изощренный. В процессе моделирования у нас записывается «траектория» системы (бинарный файл с достаточно сложной структурой), которая является основным результатом моделирования. При этом счет иногда падает по не зависящим от нас причинам. Если счет упал, то его можно продолжить, используя файл с промежуточным состоянием системы. После перехода на новую СХД оказалось, что перезапустить счет на продолжение с использованием промежуточного файла можно только два раза. После третьего раза файл с траекторией оказывается поврежденным и использовать его дальше нельзя. Почему это происходит — никто не знает. Служба поддержки помочь не смогла.
Он был торт только первый год :)
Было бы интересно посмотреть ускорения в режиме умножения.
Интересно, какие задачи на нем будут решаться?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проба пера на суперкомпьютере Ломоносов