The OpenNET Project / Index page

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

Каталог документации / Раздел "Программирование, языки" / Оглавление документа
next up previous contents
Next: Фортран 90 и модуль Up: Скрипты для компиляции и Previous: Скрипты для компиляции и   Contents

Использование разделяемых бибилиотек

Разделяемые бибилиотеки могут помочь уменьшить размер исполняемых файлов. Это особенно ценно для кластеров рабочих станций, где исполняемые файлы обычно копируются по сети на каждую машину, которая исполняет параллельную программу. Однако, существует несколько практических проблем использования разделяемых библиотек; этот раздел обсуждает некоторые из них и методы решения большинства этих проблем. В настоящее время разделяемые библиотеки не поддерживаются для С++.

Чтобы создать разделяемые библиотеки для mpich, Вы должны конфигурировать и собирать mpich с опцией $-$$-$enable-sharedlib. Поскольку каждая Unix-система и практически каждый компилятор использует различные и зачастую несовместимые множества опций для создания разделяемых объектов и библиотек, mpich может не определить коректные опции. В настоящее время mpich воспринимает Solaris, GNU gcc (на большинстве платформ, включая LINUX и Solaris) и IRIX. Информацию о построении разделяемых библиотек на друих платформах можно присылать на [email protected].

Когда разделяемые библиотеки построены, Вы должны сообщить командам компиляции и компоновки mpich об их использовании (причина, по которой разделяемые библиотеки не используются по умолчанию, будет пояснена ниже). Вы можете сделать это либо опцией командной строки -shlib или установкой переменной окружения MPICH_USE_SHLIB в значение yes. Например,

mpicc -o cpi -shlib cpi.c
или
setenv MPICH_USE_SHLIB yes
mpicc -o cpi cpi.c
Использование переменной окружения MPICH_USE_SHLIB позволяет Вам управлять использованием разделяемых библиотек без изменения команд компиляции; это очень полезно в проектах, которые используют make-файлы.

Запуск программы, построенной с испоьзованием разделяемых библиотек, может быть очень сложным. Некоторые (большинство?) систем не запоминают, где находились разделяемые библиотеки, когда компоновался исполняемый файл! Вместо этого, они пробуют найти разделяемые библиотеки либо в каталоге по умолчанию (таком, как `/lib'), либо в каталоге, определяемом переменной окружения, такой, как LD_LIBRARY_PATH, либо в каталоге, определяемом агрументом командной строки, таким, как -R или -rpath (см. ниже более подробно). configure для mpich проверяет их и сообщает, когда исполняемый файл, построенный с разделяемыми библиотеками, вспоминает их размещение. Он также пытается использовать аргументы командной строки компилятора, чтобы заставить исполняемый файл вспомнить размещение разделяемых библиотек.

Если Вам необходимо установить переменные окружения, чтобы указать, где находятся разделяемые библиотеки mpich, Вам необходимо убедиться в том, что и процесс, из которого Вы запустили mpirun, и любые процессы, запущенные mpirun, получат переменную окружения. Простейший способ сделать это - установить переменную окружения внутри Вашего файла `.cshrc' (для пользователей csh или tcsh) или `.profile' (для пользователей sh или ksh).

Однако, установка переменной окружения внутри скриптов запуска может вызвать проблемы, если Вы используете несколько различных систем. Например, у Вас имеется единый файл `.cshrc', который Вы используете в SGI (IRIX) и Solaris. Вы не хотите установить LD_LIBRARY_PATH, чтобы указать SGI на Solaris-версию разделяемых библиотек mpich2. Вместо этого, Вы можете пожелать установить переменную окружения перед запуском mpirun:

setenv LD_LIBRARY_PATH $$\lbrace$LD_LIBRARY_PATH$\rbrace$:/usr/local/mpich/lib/shared
mpirun -np 4 cpi
К сожалению, это не всегда сработает. В зависимости от метода, используемого mpirun и mpich для запуска процессов, переменная окружения может не передаться новому процессу. Это вызовет завершение программы с сообщением вида
ld.so.1: /home/me/cpi: fatal: libpmpich.so.1.0: open failed:
No such file or directory
Killed
Существуют различные решения этой проблемы; каждое из них зависит от конкретного устройства mpich (например, ch_p4), которое Вы используете, и эти решения обсуждаются в соответствующих разделах в разд.3.

Альтернативой использованию LD_LIBRARY_PATH и безопасного сервера является добавление опции к команде компоновки, предоставляющей путь для использования в поиске разделяемых библиотек. К сожалению, опция, которая Вам нужна, это ``добавить этот каталог в путь поиска'' (такая, какую Вы получаете, используя -L). Вместо этого, многие компиляторы предлагают только опцию ``заменить путь поиска на данный путь''3. Например, некоторые компиляторы позволяют использовать -Rpath:path:...:path для определения заменяемого пути. Тогда, если и mpich, и пользователь предоставляют путь поиска библиотек через -R, один из путей будет утерян. В итоге, mpicc и другие скрипты могут проверить наличие опции -R и создать универсальную версию, но сейчас они этого не делают. Вы можете, однако, предложить полный путь поиска самостоятельно, если Ваш компилятор поддерживает такие опции, как -R.

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


Alex Otwagin 2002-12-16



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру