MPI универсален и всеяден. Он не накладывает практически никаких ограничений на приложение, на железо, на каналы, которые используются для связи между компьютерами. Можно в буквальном смысле слова поставить на стол две персоналки с MPI, соединить их Ethernet-кабелем - и кластер на два процессора, на котором можно запускать любое MPI-приложение, - готов! Потому-то этот интерфейс так и любят ученые, реализующие с его помощью программы для самых немыслимых суперкомпьютеров.

Впрочем, при желании можно использовать MPI и для обычных двухъядерных процессоров или двухпроцессорных систем - «вотчины» проектов OpenMP. Но, конечно, MPI для таких целей «тяжеловат», - как в плане быстроты исполнения программного кода, которому, в отличие от его OMP-коллег, приходится еще и оплачивать «накладные расходы» на канал связи, так и в плане высокой сложности разработки MPI-приложений. Последние, правда, лишены большинства тех «граблей», которые существуют для обычных систем с распределенной памятью; но зато для написания соответствующего кода от программиста требуется четкое мышление, позволяющее в деталях продумать систему обмена информацией между процессами.

Это отдельная песня. Я не говорю даже о том, что когда в программе запущен не один, а несколько потоков, то пошаговая отладка превращается в настоящий кошмар: контрольные точки «ловят» все треды подряд, а шаг одного потока запросто может сопровождаться полусотней шагов соседнего. Главная проблема в отладке параллельных приложений заключается в том, что возникающие там глюки уникальны. Зачастую они связаны со случайным совпадением каких-то событий в «жизни» слабо связанных друг с другом потоков, а потому проявляются, как говорится, в соответствии с текущей фазой луны, - возникнут раз-другой и бесследно исчезнут. Мало того, иногда присутствие «наблюдателя» (отладочных средств) изменяет результат измерений, поскольку слегка перестраивает «свойства окружающей среды», - вот и вылавливай после этого какой-нибудь плавающий глюк, обусловленный параллельностью.

Возможных решений тут всего три. Во-первых, средства, подобные OpenMP, заметно упрощают разработку «параллельных» программ, поскольку устраняют необходимость ручного задания объектов синхронизации. Правда, платить за это приходится еще более суженной функциональностью и производительностью (автоматика особой сообразительностью не отличается), так что изучить объекты синхронизации программисту не помешает. Второй способ - использование «по старинке» большого объема выводимой вручную отладочной информации. И, наконец, третий - использование специальных программ вроде Intel Thread Checker, не только наглядно и доступно отображающих в виде графика ход исполнения программы, но и способных в некоторых случаях находить распространенные ошибки начинающих.

Как ни крути, за параллельными приложениями будущее, - а значит, пришла пора осваивать соответствующие приемы программирования и инструментарий. Компания Intel не только обещает завалить рынок недорогими многоядерными процессорами, но и предоставляет весь необходимый инструментарий для полноценного использования своих разработок. И судя по тому, что новейшие продукты Intel на процессорах AMD зачастую отказываются запускаться - AMD как платформе разработчиков вскоре придется неуютно.

В мире программного обеспечения популярны два диаметрально противоположных тезиса. Первый заключается в том, что весь софт должен быть свободным и распространяться с исходными текстами, что только открытый способ разработки приносит плоды, с аппетитом съедаемые конечными пользователями. Против этой идеи выступают некоторые руководители крупных софтверных компаний: они утверждают, что продукция компании должна оплачиваться «нормальным» способом - а именно коммерческой реализацией товара.

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

Инструменты обработки цифровых изображений уже давно выпорхнули из умелых рук профессионалов и прочно обосновались на компьютерах пользователей, которых никто ни разу в жизни не называл «фотографами». Сегодня даже начинающим секретарям-референтам вменяется в обязанность обработка цифровых снимков и рассылка заказчикам. Что уж говорить о нас с вами… горе-специалистах.

Ситуацию усугубляет то, что популяризация цифрового фото привела к огромным продажам маленьких аппаратов с еле заметным глазком объектива, в народе называемых «мыльницами». Их использование можно свести к трем этапам: машинальное нажатие на кнопку спуска, укладка прически после увиденного снимка, обращение за помощью к компьютеру, чтобы как-то исправить отснятый материал. И в этот момент нашей последней соломинкой оказывается ПО для обработки цифровых изображений.

За долгие годы бесшабашного использования разнообразного софта россияне привыкли к тому, что программы бывают только бесплатные, но некоторые нехорошие разработчики зачем-то заставляют пользователей при установке вводить серийный код, созданный ближайшей программой keygen.exe. Однако не за горами тот день, когда в домашних ПК будет жить только лицензионный софт. А раз так, то пора подумать - хватит ли нам возможностей бесплатного ПО для обработки цифровых шедевров или все же придется раскошеливаться?