MPI универсален и всеяден. Он не накладывает практически никаких ограничений на приложение, на железо, на каналы, которые используются для связи между компьютерами. Можно в буквальном смысле слова поставить на стол две персоналки с MPI, соединить их Ethernet-кабелем - и кластер на два процессора, на котором можно запускать любое MPI-приложение, - готов! Потому-то этот интерфейс так и любят ученые, реализующие с его помощью программы для самых немыслимых суперкомпьютеров.
Впрочем, при желании можно использовать MPI и для обычных двухъядерных процессоров или двухпроцессорных систем - «вотчины» проектов OpenMP. Но, конечно, MPI для таких целей «тяжеловат», - как в плане быстроты исполнения программного кода, которому, в отличие от его OMP-коллег, приходится еще и оплачивать «накладные расходы» на канал связи, так и в плане высокой сложности разработки MPI-приложений. Последние, правда, лишены большинства тех «граблей», которые существуют для обычных систем с распределенной памятью; но зато для написания соответствующего кода от программиста требуется четкое мышление, позволяющее в деталях продумать систему обмена информацией между процессами.
Это отдельная песня. Я не говорю даже о том, что когда в программе запущен не один, а несколько потоков, то пошаговая отладка превращается в настоящий кошмар: контрольные точки «ловят» все треды подряд, а шаг одного потока запросто может сопровождаться полусотней шагов соседнего. Главная проблема в отладке параллельных приложений заключается в том, что возникающие там глюки уникальны. Зачастую они связаны со случайным совпадением каких-то событий в «жизни» слабо связанных друг с другом потоков, а потому проявляются, как говорится, в соответствии с текущей фазой луны, - возникнут раз-другой и бесследно исчезнут. Мало того, иногда присутствие «наблюдателя» (отладочных средств) изменяет результат измерений, поскольку слегка перестраивает «свойства окружающей среды», - вот и вылавливай после этого какой-нибудь плавающий глюк, обусловленный параллельностью.
Возможных решений тут всего три. Во-первых, средства, подобные OpenMP, заметно упрощают разработку «параллельных» программ, поскольку устраняют необходимость ручного задания объектов синхронизации. Правда, платить за это приходится еще более суженной функциональностью и производительностью (автоматика особой сообразительностью не отличается), так что изучить объекты синхронизации программисту не помешает. Второй способ - использование «по старинке» большого объема выводимой вручную отладочной информации. И, наконец, третий - использование специальных программ вроде Intel Thread Checker, не только наглядно и доступно отображающих в виде графика ход исполнения программы, но и способных в некоторых случаях находить распространенные ошибки начинающих.
Как ни крути, за параллельными приложениями будущее, - а значит, пришла пора осваивать соответствующие приемы программирования и инструментарий. Компания Intel не только обещает завалить рынок недорогими многоядерными процессорами, но и предоставляет весь необходимый инструментарий для полноценного использования своих разработок. И судя по тому, что новейшие продукты Intel на процессорах AMD зачастую отказываются запускаться - AMD как платформе разработчиков вскоре придется неуютно.
Софтерра: Фотографическая чертовщина
В мире программного обеспечения популярны два диаметрально противоположных тезиса. Первый заключается в том, что весь софт должен быть свободным и распространяться с исходными текстами, что только открытый способ разработки приносит плоды, с аппетитом съедаемые конечными пользователями. Против этой идеи выступают некоторые руководители крупных софтверных компаний: они утверждают, что продукция компании должна оплачиваться «нормальным» способом - а именно коммерческой реализацией товара.
Конечно, каждый разработчик вправе сам выбирать модель распространения будущего продукта. Нам же интересно сравнить конечные результаты обоих подходов.