Размер имеет значение!

Хемуль

Спецвыпуск Xakep, номер #034, стр. 034-048-2

С точки зрения ученого, SMP тоже хорош. Программы его часто работают с большими массивами данных, обрабатывая их последовательно. Например, как рассчитывается взрыв водородной бомбы? Все пространство, где будет происходить "виртуальный взрыв", разрезается на кубики (ячейки), время делится на маленькие кусочки (шаги), так, чтобы в течение одного шага изменения внутри кубиков были небольшими. Потом начинается счет: машина вычисляет, как должны измениться условия в каждой ячейке за время одного шага, обновляет информацию, увеличивает счетчик времени, снова вычисляет изменения и так далее. Понятно, что чем больше ячеек нарезать, чем мельче шаг по времени задать, тем точнее будет результат и меньше вероятность воплотить в жизнь анекдот о физиках, которые после испытаний ядерной бомбы в отчете написали: "Мощность взрыва: 5-10 килотонн… мы думали, что пять, а оно как рвануло...". В общем, если мы возьмем два процессора и заставим каждый из них обрабатывать свою половину ячеек, то получим ускорение в два раза, по сравнению с обычной однопроцессорной машиной. Конечно, тут тоже есть свои грабли. Не будем вдаваться в подробности, но обеспечить одновременный доступ двух процессоров к одной ячейке памяти не так просто, как кажется.

Массивно-параллельная система

Внешне MPP выглядит довольно обыкновенно. Чаще всего это набор одинаковых системников, соединенных локальной сетью. В лучшем случае все это богатство установлено на стеллажи или привинчено к стандартным 19-дюймовым стойкам. Все вместе это называется "массивно-параллельный суперкомпьютер" или "вычислительный кластер". Ты спросишь, что же тут особенного? Главное в MPP-машине не железо, хотя оно тоже бывает уникально, компьютер такого типа суперкомпьютером делает софт. Правда, на первый взгляд, софт тоже не представляет собой ничего необычного - стандартный Linux, дополненный парой программ со странными названиями: MPI, PVM, PVFS... Программы эти помогают программисту объединять процессы в единое целое. Программист делит задачу на куски, организует распределение работы между узлами, решает как, когда и в каком порядке узлы будут обмениваться данными и т.д. Начинается отладка: программа скомпилировалась и запустилась, но через две минуты падает. На самом деле, падает из-за сбоя в программе только один процесс. Остальные падают из-за потери связи с ним. Находим ошибку. Исправляем. Задача начинает считать и через несколько минут зависает. Конечно, зависает один процесс, остальные зависли из-за невозможности получить от него данные. Вставляем отладочные операторы, читаем листинги, медитируем. Задача заработала, но неправильно. Снова чешем репу... И так очень долго. Есть, конечно, отладчики, работающие на многопроцессорных системах, но жизнь они облегчают незначительно.