разделяемая память, MPI и системы массового обслуживания

Одним из все более распространенных подходов к высокопроизводительным вычислениям (HPC) являются гибридные программы MPI/OpenMP. т.е. у вас есть N процессов MPI, и каждый процесс MPI имеет M потоков. Этот подход хорошо подходит для кластеров, состоящих из многопроцессорных узлов с общей памятью.

Переход на такую ​​иерархическую схему распараллеливания, очевидно, требует некоторых более или менее инвазивных изменений, OTOH, если все сделано правильно, может повысить производительность и масштабируемость кода в дополнение к снижению потребления памяти для реплицированных данных.

В зависимости от реализации MPI вы можете или не можете выполнять вызовы MPI из всех потоков. Это определяется аргументами required и provided функции MPI_Init_Thread(), которую вы должны вызывать вместо MPI_Init(). Возможные значения

{ MPI_THREAD_SINGLE}
    Only one thread will execute. 
{ MPI_THREAD_FUNNELED}
    The process may be multi-threaded, but only the main thread will make MPI calls (all MPI calls are ``funneled'' to the main thread). 
{ MPI_THREAD_SERIALIZED}
    The process may be multi-threaded, and multiple threads may make MPI calls, but only one at a time: MPI calls are not made concurrently from two distinct threads (all MPI calls are ``serialized''). 
{ MPI_THREAD_MULTIPLE}
    Multiple threads may call MPI, with no restrictions. 

По моему опыту, современные реализации MPI, такие как Open MPI, поддерживают наиболее гибкий MPI_THREAD_MULTIPLE. Если вы используете старые библиотеки MPI или какую-то специализированную архитектуру, вам может быть хуже.

Конечно, вам не нужно создавать многопоточность с помощью OpenMP, это просто самый популярный вариант в HPC. Вы можете использовать, например. библиотека потоков Boost, библиотека Intel TBB или прямые потоки pthreads или Windows, если уж на то пошло.

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

На практике, если вам нужно разделить память между узлами, лучше всего сделать это вне MPI. я не думаю, что вам нужно использовать разделяемую память в стиле boost.interprocess, поскольку вы не описываете ситуацию, когда разные узлы вносят мелкие изменения в разделяемую память; он либо доступен только для чтения, либо разделен.

Ответы Джона и Деуса касаются того, как отображать в файле, что определенно то, что вы хотите сделать для статических данных 5 ГБ (гигабит?). Данные для каждого процессора звучат одинаково, и вам просто нужно отправить сообщение каждому узлу, сообщая ему, какую часть файла он должен захватить. ОС должна позаботиться о сопоставлении виртуальной памяти с физической памятью и файлами.

Что касается очистки... Я бы предположил, что она не выполняет очистку общей памяти, но файлы mmaped следует очищать, поскольку файлы закрываются (что должно освобождать их сопоставления памяти) при очистке процесса. Я понятия не имею, какие предостережения есть у CreateFileMapping и т. д.

Фактическая «общая память» (т.е. boost.interprocess) не очищается, когда процесс умирает. Если возможно, я бы рекомендовал попробовать убить процесс и посмотреть, что осталось.

С MPI-2 у вас есть RMA (удаленный доступ к памяти) через такие функции, как MPI_Put и MPI_Get. Использование этих функций, если ваша установка MPI их поддерживает, определенно поможет вам уменьшить общее потребление памяти вашей программой. Цена — это дополнительная сложность кодирования, но это часть удовольствия от параллельного программирования. Опять же, это удерживает вас в области MPI.

MPI-3 предлагает окна разделяемой памяти (см., например, MPI_Win_allocate_shared()), что позволяет использовать разделяемую память на узле без каких-либо дополнительных зависимостей.

Я мало разбираюсь в unix и не знаю, что такое MPI. Но в Windows то, что вы описываете, является точным соответствием объекту сопоставления файлов.

Если эти данные встроены в ваш .EXE или .DLL, который он загружает, то они будут автоматически совместно использоваться всеми процессами. Разрушение вашего процесса, даже в результате сбоя, не приведет к утечкам или невыпущенным блокировкам ваших данных. однако 9Gb .dll звучит немного сомнительно. Так что это, вероятно, не работает для вас.

Однако вы можете поместить свои данные в файл, а затем CreateFileMapping и MapViewOfFile на нем. Отображение может быть только для чтения, и вы можете отобразить весь файл или его часть в память. Все процессы будут совместно использовать страницы, сопоставленные с одним и тем же базовым объектом CreateFileMapping. рекомендуется закрывать несопоставленные представления и закрывать дескрипторы, но если вы этого не сделаете, ОС сделает это за вас при разборке.

Обратите внимание, что если вы не используете x64, вы не сможете отобразить файл размером 5 ГБ в одно представление (или даже файл размером 2 ГБ, 1 ГБ может работать). Но учитывая, что вы говорите о том, что это уже работает, я предполагаю, что вы уже используете только x64.

Если вы храните свои статические данные в файле, вы можете использовать mmap в unix для получения произвольного доступа к данным. Данные будут выгружаться по мере необходимости и тогда, когда вам потребуется доступ к определенному биту данных. Все, что вам нужно сделать, это наложить любые двоичные структуры на данные файла. Это аналог Unix CreateFileMapping и MapViewOfFile, упомянутых выше.

Кстати, glibc использует mmap, когда вызывается malloc для запроса более чем одной страницы данных.

У меня было несколько проектов с MPI в SHUT.

Насколько я знаю, есть много способов распределить задачу с помощью MPI, возможно, вы сможете найти другое решение, не требующее общей памяти, мой проект решал 7 000 000 уравнений и 7 000 000 переменных

если вы можете объяснить свою проблему, я постараюсь вам помочь

Я столкнулся с этой проблемой в малом, когда использовал MPI несколько лет назад.

Я не уверен, что SGE понимает файлы с отображением памяти. Если вы распространяете через кластер beowulf, я подозреваю, что у вас будут проблемы с когерентностью. Не могли бы вы немного рассказать о вашей многопроцессорной архитектуре?

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