[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Программирование, языки" / Оглавление документа

Проблемы с привязками ФОРТРАН для MPI.

Как было отмечено в основной спецификации MPI, интерфейс нарушает стандарты несколькими путями. Это вызывало некоторые проблемы в программах на языке ФОРТРАН77 и стало более значимым для программ на ФОРТРАН90, поэтому пользователи должны быть осторожны при использовании новых возможностей ФОРТРАН 90. Эти нарушения изначально были адаптированы, но впоследствии возвращены с связи их важностью для возможности использования MPI. Остальная часть этой главы детально обсуждает потенциальные проблемы. Она заменяет обсуждение привязок ФОРТРАН оригинальной спецификации MPI (для ФОРТРАН90, но не ФОРТРАН77). Итак, следующие возможности MPI несовместимы с ФОРТРАН90:

1. Функция MPI с выбираемыми аргументами может быть вызвана с другими типами аргументов.
2. Функция MPI с фиктивным аргументом assumed-size может передать реальный скалярный аргумент.
3. Многие функции MPI предполагают, что аргументы передаются по адресу и аргументы не копируются при входе или выходе из функции.
4. Реализация MPI может читать или изменять данные пользователя (например, коммуникационные буферы, использующиеся для неблокирующей связи) независимо от программы пользователя, выполняющейся вне вызовов MPI.
5. Некоторые ``константы'', такие как MPI_BOTTOM, MPI_IN_PLACE, MPI_STATUS_IGNORE,
   MPI_STATUSES_IGNORE, MPI_ERRCODES_IGNORE, MPI_ARGV_NULL и MPI_ARGVS_NULL не являются обычными константами языка ФОРТРАН и требуют особой реализации. См. главу 1.5.4.
6. Функция выделения памяти MPI_ALLOC_MEM не может быть эффективно использована в ФОРТРАН без расширения языка, позволяющего выделенной памяти быть ассоциированной с переменной ФОРТРАН.

Проблемы из-за жесткого определения типов. Все функции MPI с аргументами выбора ассоциируют реальные аргументы различных типов ФОРТРАНa с одним и тем же фиктивным аргументом. Это не допускалось ФОРТРАН77, а в ФОРТРАН90 допустимо только в случае перегрузки функции для каждого типа. В Си эти проблемы решались использованием формального аргумента void*.

Этот фрагмент технически неверен и может вызвать ошибку во время компиляции:

  integer i(5)
  real x(5)
  ...
  call mpi_send(x, 5, MPI_REAL, ...)
  call mpi_send(i, 5, MPI_INTEGER, ...)

Так же для ФОРТРАНa технически недопустима передача скалярного аргумента в виде массива. Поэтому, следующий фрагмент кода может вызвать ошибку, так как аргумент buf для MPI_SEND объявлен как assumed-size массив типа <type> buf(*).

  integer a
  call mpi_send(a, 1, MPI_INTEGER, ...)

Совет пользователям: В случае, если вы наткнулись на одну из проблем, связанных с проверками типов, вы можете избавиться от нее, используя флаг компилятора, компилируя по отдельности или используя реализацию MPI с расширенной поддержкой ФОРТРАНa, как описано в главе 8.2.4. В качестве альтернативы, которая будет работать с переменными, являющимися локальными по отношению с функции (но не к аргументам функции) можно использовать ключевое слово EQUIVALENCE для создания другой переменной с типом, приемлемым для компилятора.[]

Проблемы, связанные с копированием данных и последовательностями. В MPI заложена неявная идея того, что непрерывный кусок памяти доступен через линейное адресное пространство. MPI копирует данные в память и из нее. Программа MPI определяет местонахождение памяти предоставляя адреса и смещения в памяти. В языке Си правила ассоциации последовательностей и указатели представляют всю низкоуровневую структуру.

В ФОРТРАН90 данные пользователя не обязательно расположены непрерывно. Например, кусок массива A(1:N:2) включает только элементы массива A с индексами 1,3,5,.... То же справедливо и для массивов указателей, которые ссылаются на такой кусок. Большинство компиляторов стараются, чтобы массив в качестве фиктивного аргумента находился в непрерывной памяти если он объявлен с явным размером (например, B(N)) или имеет assumed size (например, B(*)). Если необходимо, они реализуют это копированием массива в непрерывную память. И ФОРТРАН77, и ФОРТРАН90 оговорены позволять такое копирование, но немногие компиляторы ФОРТРАН90 это делают. Технически, стандарты ФОРТРАН должны позволять содержать массивы во фрагментированной памяти.

Так как фиктивные буферные аргументы MPI - assumed-size arrays, это приводит к серьезным проблемам с неблокирующими вызовами: компилятор после возврата копирует временный массив обратно, а MPI продолжает копировать данные в память, содержавшую его. Например, следующий фрагмент:

  real a(100)
  call MPI_IRECV(a(1:100:2), MPI_REAL, 50, ...)

Так как первый аргумент для MPI_IRECV - assumed-size array ( <type> buf(*)), секция массива a(1:100:2) перед передачей MPI_IRECV копируется во временный массив в непрерывной памяти. MPI_IRECV возвращается сразу и данные копируются обратно в массив a. Позже MPI может начать запись по адресам освобожденной памяти. Копирование также является проблемой и для MPI_ISEND, так как временная память может быть освобождена до того, как все данные будут оттуда переданы.

Большинство компиляторов ФОРТРАН90 не делают копию, если аргумент целиком является массивом явной формы, assumed-size array или ``простой'' секцией (например, A(1:N)) подобного массива. (Понятие ``простой'' секции мы определим в следующем параграфе). Также, многие компиляторы в этом отношении интерпретируют динамические (allocatable) массивы так же, как и массивы явной формы (хотя нам известен один, который так не делает). Тем не менее, это не так для assumed-shape и массивов указателей; так как они могут быть фрагментированы, часто производится копирование. Это тот случай, который вызывает проблемы с MPI, как описано в предыдущем параграфе.

``Простая'' секция массива формально определяется следующим образом:

  name ( [:,]... [<subscript>]:[<subscript>] [,<subscript>]... )

  A(1:N), A(:,N), A(:,1:N,1), A(1:6,N), A(:,:,1:N)

Та же проблема может быть и с в случае со скалярным аргументом. Некоторые компиляторы, даже для ФОРТРАН77 делают копию некоторых скалярных аргументов по умолчанию в вызванной процедуре. Это может вызвать проблему, проиллюстрированную в следующем примере:

  call user1(a,rq)
  call MPI\_WAIT(rq,status,ierr)
  write (*,*) a

  subroutine user1(buf,request)
  call MPI\_IRECV(buf,...,request,...)
  end

Если a скопировано, MPI_IRECV после завершения связи изменит копию и не изменит само a.

Заметьте, что копирование почти обязательно произойдет для аргумента, который представляет нетривиальное выражение (с как минимум, одним оператором или вызовом функции), секцией, не выбирающей непрерывную часть своего предка (например, A(1:n:2)), указатель, чья ссылка - такое выражение, или массив неявной формы, который (прямо или косвенно) ассоциируется с такой секцией.

Если есть опция компилятора, запрещающая копирование аргументов при вызовах и возвратах процедур, она должна быть включена.

Если компилятор делает копии при вызове процедур для аргументов, являющихся массивами явной формы или assumed-size arrays, простых секций таких массивов, скаляров, и у компилятора нет опций, запрещающих это, он не может быть использован а приложениях, использующих MPI_GET_ADDRESS, или любые неблокирующие функций MPI. Если компилятор копирует скалярные аргументы в вызванной процедуре и нет опции, запрещающей это, такой компилятор не может быть использован в приложениях, использующих ссылки на память между вызовами процедур как в указанном примере.

Особые константы. MPI требует набор особых ``констант'', которые не могут быть реализованы как нормальные константы языка ФОРТРАН, в том числе MPI_BOTTOM, MPI_STATUS_IGNORE,
MPI_IN_PLACE, MPI_STATUSES_IGNORE и MPI_ERRCODES_IGNORE. В языке Си это реализовано как константные указатели, обычно NULL, и используются там, где прототип получает указатель на переменную, а не саму переменную.

В ФОРТРАН реализация таких особых констант может потребовать использование конструкций, выходящих за пределы стандарта ФОРТРАН. Использование особых значений для констант (например, определение их через ключевое слово parameter) также невозможно, так как реализация не может отличить эти значения от нормальных данных. Обычно эти константы определены как предопределенные статические переменные (например, переменная, определенная в объявленном в MPI блоке COMMON), полагаясь на то, что компилятор передает данные по адресу. Внутри процедуры адрес может быть получен некоторым механизмом за рамками стандарта ФОРТРАН (например, расширениями ФОРТРАНa или реализацией этой функции на Си).

Порожденные типы ФОРТРАН90. MPI не поддерживает явно передачу порожденных типов ФОРТРАН90 фиктивным аргументам с выбором. И в самом деле, для реализаций MPI, предоставляющих явные интерфейсы через модуль mpi , компилятор отклонит такой тип еще во время компиляции. Даже когда явные интерфейсы не даются, пользователи должны знать, что ФОРТРАН90 не дает гарантии ассоциации последовательности для порожденных типов. Например, массив порожденных типов, состоящих из двух элементов может быть реализован как массив первых элементов, за которым следует массив вторых элементов. Здесь может помочь использование атрибута SEQUENCE.

Следующий фрагмент показывает один из возможных путей передачи порожденных типов в ФОРТРАН. Пример предполагает, что данные передаются по адресу.

  type mytype
     integer i
     real x
     double precision d
  end type mytype

  type(mytype) foo
  integer blocklen(3), type(3)
  integer(MPI\ADDRESS_KIND) disp(3), base

  call MPI_GET_ADDRESS(foo%i, disp(1), ierr)
  call MPI_GET_ADDRESS(foo%x, disp(2), ierr)
  call MPI_GET_ADDRESS(foo%d, disp(3), ierr)


  base = disp(1)
  disp(1) = disp(1) - base
  disp(2) = disp(2) - base
  disp(3) = disp(3) - base

  blocklen(1) = 1
  blocklen(2) = 1
  blocklen(3) = 1

  type(1) = MPI_INTEGER
  type(2) = MPI_REAL
  type(3) = MPI_DOUBLE_PRECISION

  call MPI_TYPE_CREATE_STRUCT(3, blocklen, disp, type, newtype, ierr)
  call MPI_TYPE_COMMIT(newtype, ierr)

! не очень-то хорошо пересылать foo%i вместо foo, но для скалярных
! объектов типа mytype это работает
call MPI_SEND(foo%i, 1, newtype, ...)

Когда переменная для процедуры ФОРТРАНa является локальной (то есть не модуль или блок COMMON), компилятор считает, что она не может быть изменена вызванной процедурой, если это не реальный аргумент вызова. В наиболее распространенной конвенции компоновщика от процедуры ожидается, что она сохранит и восстановит определенные регистры. Поэтому, оптимизатор будет предполагать, что регистр, содержавший верную копию такой переменной до вызова будет содержать ее и при возврате.

Обычно это не влияет на пользователей. Но в случае если в программе пользователя буферный аргумент для MPI_SEND, MPI_RECV и др. использует имя, которое скрывает настоящий аргумент, пользователь должен обратить внимание на эту главу. Один из примеров - MPI_BOTTOM с MPI_Datatype, содержащим абсолютный адрес. Другой способ - создание типа данных, который использует одну переменную как метку и работает с другими используя MPI_GET_ADDRESS для определения их смещения от метки. Переменная-метка будет единственной, упомянутой в вызове. Также следует уделить внимание случаю, когда используются те операции MPI, которые выполняются параллельно приложению пользователя.

Следующий пример показывает, что разрешено делать компиляторам ФОРТРАН.

Этот исходный код ...           может быть скомпилирован как:
call MPI_GET_ADDRESS(buf,       call MPI_GET_ADDRESS(buf,...)
               bufaddr, ierror)
call MPI_TYPE_CREATE_STRUCT(1,  call MPI_TYPE_CREATE_STRUCT(...)
               1,bufaddr,
               MPI_REAL,type,
               error)
call MPI_TYPE_COMMIT(type,      call MPI_TYPE_COMMIT(...)
               ierror)
val_old = buf                   register = buf
                                val_old = register
call MPI_RECV(MPI_BOTTOM,1,     call MPI_RECV(MPI_BOTTOM,...)
               type,...)
val_new = buf                   val_new = register

Компилятор не помечает регистр недействительным, так как не может определить изменение значения buf функцией MPI_RECV. Доступ к buf скрыт использованием MPI_GET_ADDRESS и MPI_BOTTOM.

Следующий пример иллюстрирует экстремальные, но допустимые возможности.

Исходный код          скомпилирован как      или как:
call MPI_IRECV(buf,   call MPI_IRECV(buf,   call MPI_IRECV(buf,
               ..req)                ..req)                ..req)
                      register = buf        b1 = buf
call MPI_WAIT(req,..) call MPI_WAIT(req,..) call MPI_WAIT(req,..)
b1 = buf              b1 := register

MPI_WAIT в параллельном потоке изменяет buf между вызовом MPI_IRECV и завершением MPI_WAIT. Но компилятор не видит возможности изменения buf после возврата MPI_IRECV и может загрузить buf раньше, чем указано в исходном коде. Он не видит причин не использовать регистр для хранения buf до вызова MPI_WAIT. Он также может поменять порядок следования операций, как в случае справа.

Для предотвращения изменения порядка команд или хранения буфера в регистре есть две возможности построения реализации кроссплатформенного кода на ФОРТРАН:

• Компилятор можно удержать от передвижения ссылки на буфер через вызов функции MPI окружением функции вызовами внешней процедуры с буфером в качестве аргумента. Заметьте, что если параметр объявлен во внешней процедуре, он должен быть OUT или INOUT. Сама процедура может быть пустой, но компилятор этого не знает и должен предположить, что буфер мог быть изменен. Например, вышеуказанный вызов MPI_RECV может быть изменен так:

    call DD(buf)
    call MPI_RECV(MPI_BOTTOM,...)
    call DD(buf)
  

  со скомпилированной отдельно

    subroutine DD(buf)
    integer buf
    end
  

  (будем считать, что buf имеет тип INTEGER). Таким же образом компилятор можно удержать от ссылки на переменную через вызов функции MPI.

  В случае неблокирующего вызова, как и в случае с MPI_WAIT, никакие ссылки на буфер не допускаются до проверки завершения переноса данных. Таким образом, в этом случае дополнительный вызов MPI не является необходимым, то есть вызов MPI_WAIT в примере может быть изменен так:

  call MPI_WAIT(req,..)
  call DD(buf)
  

• В качестве альтернативы можно включить буфер или переменную в модуль или блок и получать к ней доступ через использование USE или COMMON везде, где она определяется, на нее ссылаются или она появляется в виде аргумента вызова процедуры MPI. Компилятор должен будет предположить, что процедура MPI (в примере выше - MPI_RECV) может изменить буфер или переменную, так как он не может проанализировать то, что процедура MPI не делает ссылку на модуль или блок.

В будущем, атрибут VOLATILE рассматривается для ФОРТРАН2000 и должен будет придать буферу или переменной необходимые свойства, но он будет подавлять регистровую оптимизацию для любого кода, содержащего буфер или переменную.

В языке Си, функции, которые могут изменить переменные, не являющиеся ее аргументами не будут вызывать проблем с регистровой оптимизацией. Это так, потому что получение указателей на объекты хранения используя оператор & и последующие ссылки на объект с использованием указателя - часть языка. Компилятор Си понимает такой подтекст, поэтому, в общем случае проблемы быть не должно. Тем не менее, есть компиляторы с опциональной агрессивной оптимизацией, которые могут быть не столь безопасны.

Партнёры:

Хостинг: