Варианты параллельного ввода-вывода, в частности параллельный 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.