Лучший подход для чтения и записи больших файлов с коллективным MPI-IO - PullRequest
Новая
       20

Лучший подход для чтения и записи больших файлов с коллективным MPI-IO

5 голосов
/ 19 февраля 2012

Я хотел бы читать и записывать большие наборы данных на Фортране, используя MPI-IO. Мой предпочтительный подход состоит в том, чтобы использовать тип MPI, определенный с помощью MPI_type_create_subarray с одним измерением, чтобы описать представление каждого процесса в файле. Мой код на Фортране выглядит следующим образом: 

  ! A contiguous type to describe the vector per element.
  ! MPI_TYPE_CONTIGUOUS(COUNT, OLDTYPE, NEWTYPE, IERROR)
  call MPI_Type_contiguous(nComponents, rk_mpi, &
    &                      me%vectype, iError)
  call MPI_Type_commit( me%vectype, iError )

  ! A subarray to describe the view of this process on the file.
  ! MPI_TYPE_CREATE_SUBARRAY(ndims, array_of_sizes, array_of_subsizes,
  !                          array_of_starts, order, oldtype, newtype, ierror)
  call MPI_Type_create_subarray( 1, [ globElems ], [ locElems ], &
    &                           [ elemOff ], MPI_ORDER_FORTRAN, &
    &                           me%vectype, me%ftype, iError)

Однако, array_of_sizes и array_of_starts, описывающие глобальные величины, являются просто «нормальными» целыми числами в интерфейсе MPI. Таким образом, при таком подходе существует ограничение в 2 миллиарда элементов. Есть ли другой интерфейс, который использует MPI_OFFSET_KIND для этих глобальных значений? Я вижу, что единственный способ обойти это - использовать опцию смещения в MPI_File_set_view вместо определения представления с помощью типа MPI для подмассива. Однако это "чувствует" неправильно. Ожидаете ли вы влияние на производительность в любом подходе для коллективного ввода-вывода? Кто-нибудь знает, изменится ли этот интерфейс в MPI-3? Может мне стоит использовать какой-нибудь другой тип MPI?

Каково рекомендуемое решение для эффективной записи больших файлов данных с коллективным вводом-выводом параллельно на диск?

1 Ответ

3 голосов
/ 19 февраля 2012

Помощь приходит.

В MPI-3 будут программы обработки типов данных, которые используют MPI_Count вместо int. Для обратной совместимости (стона) существующие подпрограммы не изменятся, но вы должны быть в состоянии сделать свой тип.

Но сейчас .. Тем не менее, для подмассива, в частности, на данный момент это обычно не считается большой проблемой - даже для двумерного массива индексы в 2 миллиарда дают размер массива 4x10 18 , что, по общему признанию, довольно большой (но именно такой тип чисел предназначен для вычислений типа exascale). В более высоких размерах это еще больше.

В 1d список чисел длиной 2 миллиарда составляет всего ~ 8 ГБ, что не является большой натяжкой данных, и я думаю, что вы оказались в такой ситуации. Мое предложение было бы оставить в форме у вас есть это так долго, как вы можете. Есть ли общий фактор в местных элементах? Вы можете обойти это, связав типы в единицы (скажем) 10 вектипов, если это работает - для вашего кода это не должно иметь значения, но это уменьшит на тот же коэффициент числа в locElements и globElements. В противном случае, да, вы всегда можете использовать поле смещения в представлении набора файлов.

...