Неплохой джентльменский набор, не правда ли? А сколько занятных вопросов связано с работой в «параллельном» режиме стандартных библиотек! К примеру, функция GetHostByAddr в стандартном программном интерфейсе Microsoft, активно использующаяся сетевыми программами, одно время грешила тем, что при ее повторных вызовах с разными адресами из разных потоков выдавала обоим потокам указатель на одну и ту же структуру данных, хотя запрашивали они совсем разное. И если производитель клятвенно заверяет вас, что его библиотека совсем-совсем, ну честно-честно является thread-safe[Безопасной для использования в параллельном режиме], — вспомните, что даже Microsoft нет-нет да и ошибается, модифицируя продукт с десятилетней историей. А о трудности отыскания подобных глюков красноречиво свидетельствует то, сколько потребовалось времени, чтобы GetHostByAddr выловить[Исправили его в Windows XP SP1. Сколько лет он жил никем не замеченный, одному богу известно].
Идея MPI заключается в следующем. OpenMP (да и многие другие системы для разработки параллельного ПО) ориентируется на так называемые системы с общей памятью, когда на компьютере запущена всего одна программа (точнее, один процесс), но внутри этого процесса «живет» несколько потоков исполнения, каждому из которых доступна вся память процесса, а стало быть, и все его данные. MPI исходит из другой предпосылки: на компьютере запущено много-много программ (процессов), которые друг с другом напрямую общаться не могут и вынуждены устанавливать контакт через специальные окна или даже внешние каналы связи. Называется все это IPC (Inter-Process Communication) и, как вы уже, наверное, догадались, сильно изменяется от компьютера к компьютеру и от операционной системе к операционной системе. А MPI — попытка стандартизировать связь между процессами, предоставив всем желающим удобную модель запуска на нескольких процессорах тех программ, которые будут коллективно обрабатывать данные, и обеспечивая «почтовые пересылки» между этими программами. Вот и весь Message Passing Interface.
MPI универсален и всеяден. Он не накладывает практически никаких ограничений на приложение, на железо, на каналы, которые используются для связи между компьютерами. Можно в буквальном смысле слова поставить на стол две персоналки с MPI, соединить их Ethernet-кабелем — и кластер на два процессора, на котором можно запускать любое MPI-приложение, — готов! Потому-то этот интерфейс так и любят ученые, реализующие с его помощью программы для самых немыслимых суперкомпьютеров.
Впрочем, при желании можно использовать MPI и для обычных двухъядерных процессоров или двухпроцессорных систем — «вотчины» проектов OpenMP. Но, конечно, MPI для таких целей «тяжеловат», — как в плане быстроты исполнения программного кода, которому, в отличие от его OMP-коллег, приходится еще и оплачивать «накладные расходы» на канал связи, так и в плане высокой сложности разработки MPI-приложений. Последние, правда, лишены большинства тех «граблей», которые существуют для обычных систем с распределенной памятью; но зато для написания соответствующего кода от программиста требуется четкое мышление, позволяющее в деталях продумать систему обмена информацией между процессами.
Возможных решений тут всего три. Во-первых, средства, подобные OpenMP, заметно упрощают разработку «параллельных» программ, поскольку устраняют необходимость ручного задания объектов синхронизации. Правда, платить за это приходится еще более суженной функциональностью и производительностью (автоматика особой сообразительностью не отличается), так что изучить объекты синхронизации программисту не помешает. Второй способ — использование «по старинке» большого объема выводимой вручную отладочной информации. И, наконец, третий — использование специальных программ вроде Intel Thread Checker, не только наглядно и доступно отображающих в виде графика ход исполнения программы, но и способных в некоторых случаях находить распространенные ошибки начинающих.
ShadowUser. Говоря коротко и не совсем точно, она запоминает состояние вашего жесткого диска и при каждой перезагрузке восстанавливает его. Казалось бы, ничего особенного, об этом мы говорили чуть выше — однако есть одна тонкость: вам не требуется ни делать образ диска, ни создавать «точку восстановления», как в утилитах класса True Image или GoBack. Достаточно активировать ShadowUser и перезагрузить компьютер — все, теперь вы в безопасности, о которой и не мечтали.
Интерфейс MPI
Еще один стандарт де-факто в мире параллельных вычислений — пакет MPI (Message Passing Interface), тоже разрабатывавшийся как универсальное средство облегчения жизни разработчику параллельного ПО. Только устроено оно совсем иначе, нежели OpenMP, и ориентировано в основном для других, «более возвышенных» целей.Идея MPI заключается в следующем. OpenMP (да и многие другие системы для разработки параллельного ПО) ориентируется на так называемые системы с общей памятью, когда на компьютере запущена всего одна программа (точнее, один процесс), но внутри этого процесса «живет» несколько потоков исполнения, каждому из которых доступна вся память процесса, а стало быть, и все его данные. MPI исходит из другой предпосылки: на компьютере запущено много-много программ (процессов), которые друг с другом напрямую общаться не могут и вынуждены устанавливать контакт через специальные окна или даже внешние каналы связи. Называется все это IPC (Inter-Process Communication) и, как вы уже, наверное, догадались, сильно изменяется от компьютера к компьютеру и от операционной системе к операционной системе. А MPI — попытка стандартизировать связь между процессами, предоставив всем желающим удобную модель запуска на нескольких процессорах тех программ, которые будут коллективно обрабатывать данные, и обеспечивая «почтовые пересылки» между этими программами. Вот и весь Message Passing Interface.
MPI универсален и всеяден. Он не накладывает практически никаких ограничений на приложение, на железо, на каналы, которые используются для связи между компьютерами. Можно в буквальном смысле слова поставить на стол две персоналки с MPI, соединить их Ethernet-кабелем — и кластер на два процессора, на котором можно запускать любое MPI-приложение, — готов! Потому-то этот интерфейс так и любят ученые, реализующие с его помощью программы для самых немыслимых суперкомпьютеров.
Впрочем, при желании можно использовать MPI и для обычных двухъядерных процессоров или двухпроцессорных систем — «вотчины» проектов OpenMP. Но, конечно, MPI для таких целей «тяжеловат», — как в плане быстроты исполнения программного кода, которому, в отличие от его OMP-коллег, приходится еще и оплачивать «накладные расходы» на канал связи, так и в плане высокой сложности разработки MPI-приложений. Последние, правда, лишены большинства тех «граблей», которые существуют для обычных систем с распределенной памятью; но зато для написания соответствующего кода от программиста требуется четкое мышление, позволяющее в деталях продумать систему обмена информацией между процессами.
Отладка параллельных приложений
Это отдельная песня. Я не говорю даже о том, что когда в программе запущен не один, а несколько потоков, то пошаговая отладка превращается в настоящий кошмар: контрольные точки «ловят» все треды подряд, а шаг одного потока запросто может сопровождаться полусотней шагов соседнего. Главная проблема в отладке параллельных приложений заключается в том, что возникающие там глюки уникальны. Зачастую они связаны со случайным совпадением каких-то событий в «жизни» слабо связанных друг с другом потоков, а потому проявляются, как говорится, в соответствии с текущей фазой луны, — возникнут раз-другой и бесследно исчезнут. Мало того, иногда присутствие «наблюдателя» (отладочных средств) изменяет результат измерений, поскольку слегка перестраивает «свойства окружающей среды», — вот и вылавливай после этого какой-нибудь плавающий глюк, обусловленный параллельностью.***