Параметри паралельного вводу / виводу, зокрема паралельний HDF5

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

Які є ефективні та портативні (в ідеалі ефективні) варіанти для такої ситуації? Паралельний HDF5 здається багатообіцяючим. Хтось має з цим досвід у реальному житті?

Чи буде MPI-I / O чимось вартим уваги? Чи може це ефективно працювати з заданим макетом файлів, або мені потрібно все адаптувати?

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

MPI-IO дуже низький; варто щось розібратися в цьому, щоб знати, що відбувається "під кришкою" з паралельними HDF5, NetCDF4 або ADIOS , але використовувати його самостійно дійсно добре підходить лише для необроблених бінарних даних, де структура добре відома під час компіляції. HDF5 та NetCDF4 набагато гнучкіші.

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

У нашому центрі у нас є заняття, що тривають вдень і щодня, на паралельних введеннях / виводах, де ми говоримо про основні поняття, MPI-IO, HDF5 та NetCDF4; слайди можна знайти тут .

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

Що стосується гнучкого запису виводу масштабованим способом, у мене є досвід роботи з XDMF , який може бути досягнуто великими паралельними бінарними записами, використовуючи HDF5 (як PETSc VecView ), поєднаний з невеликою кількістю XML-коду, записаного послідовно для опису макета. Це можна прочитати за допомогою програм візуалізації, таких як Paraview або MayaVi2 . Інший спосіб зробити це - використовувати формат VTK з доданими двійковими даними, однак для цього потрібно знати все, що потрібно записати наперед.

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

Те, що я зараз роблю, не зовсім оптимально, але працює зараз. Я збираю всю справу на одному процесорі і роблю серійний вихід. Тим часом інші гравці чекають, коли письменник закінчить. Це добре працювало для мене, тому що мені вдалося утримати коефіцієнт обчислення на виході досить високим - тому масштабованість була б хорошою для понад 200 процесорів. Але це не рішення, яке ви шукаєте.

Ще одне рішення - це те, що запропонував Ян, - пишіть серійно до N файлів і мати безпілотний процесор зібрати плитки на один шматок - якщо це дозволяє оперативна пам'ять.

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