Варианты параллельного ввода-вывода, в частности параллельный HDF5


20

У меня есть приложение, которое можно тривиально распараллелить, но его производительность в значительной степени связана с вводом / выводом. Приложение считывает один входной массив, хранящийся в файле, размер которого обычно составляет 2-5 ГБ (но я ожидаю, что это число будет расти в будущем). Типичные вычисления применяют одну и ту же операцию к каждой строке или столбцу этого массива. Для операций с высокой загрузкой процессора я получаю очень хорошее масштабирование примерно до 100 процессоров, но при более медленных операциях преобладают операции ввода-вывода и связанных с ними коммуникаций (доступ по NFS), и я не могу эффективно использовать более нескольких процессоров.

Каковы эффективные и портативные (идеально переносимые) варианты для такой ситуации? Параллельная HDF5 кажется многообещающей. У кого-нибудь есть реальный опыт с этим?

Будет ли стоить изучить MPI-I / O? Может ли он эффективно работать с заданным форматом файла, или мне нужно все адаптировать?


4
Отличный вопрос У нас та же проблема, и наше грубое решение - записать / прочитать разложенный массив доменов в / из N файлов для N процессоров. Мне это не очень нравится, но все просто. Мне было бы интересно увидеть ответы, которые также касаются сложности различных библиотечных интерфейсов ...
— Янн

Как вы распределяете массив по процессорам? Что вы используете для параллелизма сейчас? Вы пишете в файлы через NFS как форму общения?
— Дан

2
Возможно, вам не придется слишком много переделывать свой код; Однажды у меня была такая проблема, и я смог добиться лучшего ускорения, избегая ввода-вывода, чем оптимизируя его.
— Дан

1
Вы используете систему очередей, такую ​​как PBS или Torque? Если это так, то есть команды для «вставки» файла в какой-либо каталог при запуске задания. Я не знаю, заметно ли это ускорило бы ситуацию, но это может стоить того.
— Дэн

1
@ Дан: да, я использую PBS, и я могу использовать его, чтобы поместить свой файл, где я хочу. Но поскольку в моем кластере нет локальных дисков, нет ничего лучше, чем общий том NFS.
— Хинсен

Ответы:


6

Параллельный ввод / вывод может помочь вам в этом случае, но если вы используете (по своей природе довольно последовательный) NFS для обслуживания ваших файлов, то это не даст того полного эффекта, который вам может понадобиться - будет последовательное узкое место в файловый сервер и наличие сотен процессов, отправляющих запросы на один сервер, не даст вам сотни ускоренных темпов выполнения одного процесса. Тем не менее, это может помочь в какой-то мере, особенно если учесть, что узким местом является чтение, а не запись, и это будет большим улучшением, если ваша система будет обновлена ​​до полностью параллельной файловой системы.

MPI-IO очень низкого уровня; Стоит кое-что понять об этом, чтобы знать, что происходит «под капотом» с параллельными HDF5, NetCDF4 или ADIOS , но его использование на самом деле хорошо подходит только для необработанных двоичных данных, где структура хорошо известна во время компиляции. HDF5 и NetCDF4 гораздо более гибкие.

Обратите внимание, что если ваши данные относительно просты - например, большие структуры данных в основном представляют собой n-мерные массивы или векторы - я рекомендую NetCDF4 (который также параллелен и основан на HDF5), а не HDF5; это значительно проще в использовании. HDF5 является более сложным, и в обмен на эту сложность допускаются очень сложные модели данных. Но если эта функция вам не нужна, быстрее начать работу в NetCDF4.

В нашем центре у нас есть дневные и однодневные занятия по параллельному вводу-выводу, где мы говорим об основных понятиях, MPI-IO, HDF5 и NetCDF4; слайды можно найти здесь .


5

Мы получаем хорошее масштабирование до всего XT6 в ORNL, используя MPI / IO для вывода векторов. Вот код . Подсистемы ввода / вывода для многих машин не рассчитаны на массовый параллелизм, поэтому я думаю, что @Dan прав, что я бы попытался минимизировать ввод-вывод, записывая только каждые несколько шагов, или какую-то другую стратегию агломерации.

Что касается гибкой записи выходных данных в масштабируемом виде, у меня есть опыт работы с XDMF , который может быть осуществлен большими параллельными двоичными записями с использованием HDF5 (например, PETSc VecView ) в сочетании с небольшим количеством кода XML, записанного в последовательном порядке для описания макета. Это можно прочитать с помощью пакетов визуализации, таких как Paraview или MayaVi2 . Другой способ сделать это - использовать формат VTK с добавленными двоичными данными, однако для этого необходимо, чтобы вы знали все, что вы хотите записать заранее.


XDMF выглядит интересно, но речь идет об организации данных, а не об эффективном доступе к тому, что XDMF называет «тяжелыми» данными. Что вы используете для этого аспекта?
— Хинсен

Мы просто используем XDMF, чтобы указать на HDF5. Таким образом, вы можете записать все двоичные файлы HDF5, но их можно прочитать большинством механизмов визуализации.
— Мэтт Кнепли

1

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

То, что я делаю в настоящее время, не совсем оптимально, но пока работает. Я собираю все это на одном процессоре и делаю последовательный вывод. В то же время другие игроки ждут, когда писатель закончит. Это хорошо сработало для меня, потому что мне удалось сохранить соотношение вычислений к производительности на достаточно высоком уровне, поэтому масштабируемость подойдет для более чем 200 процессоров. Но это не то решение, которое вы ищете.

Другое решение - это то, что предложил Янн - записывать последовательно в N файлов и иметь беспилотный процессор, собирающий плитки в один кусок - если позволяет оперативная память.

Помимо библиотек параллельного ввода / вывода, предложенных в предыдущих ответах, вы также можете изучить Parallel NetCDF http://trac.mcs.anl.gov/projects/parallel-netcdf , поскольку вы уже знакомы с NetCDF и MPI. Я не использовал это на практике, но планирую пойти в этом направлении, когда я ударился о стену со сбором + последовательный ввод-вывод.


Это вход, который создает мою проблему с масштабируемостью. Я предполагаю, что все входящие запросы от многих узлов перегружают сервер NFS, но я не знаю, как проверить эту гипотезу.
— Хинсен

@khinsen Чтобы проверить свою гипотезу, вы можете прочитать файл с небольшим числом процессоров, скажем, от 1 до 8, и разбросать данные по остальным. Сделайте профилирование, посмотрите, сколько времени вы тратите на ввод-вывод и сколько на разброс. Измените количество читателей процессора и посмотрите, что дает вам лучшую производительность.
— milancurcic

Хорошее предложение! Это будет некоторая работа, потому что это означает переписывание кода, но, вероятно, оно того стоит.
— Хинсен
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.