Стратегии против архитектур - I

 

Проблема:
Параллельные архитектуры

 

Теория говорит одно. “Устаревшая Фон-Неймановская архитектура”, “Устаревшая последовательная модель программирования”. Но практика, к сожалению, пока еще неумолима - чаще всего все по-прежнему идет от последовательного кода. Несмотря на призывы к изменению модели программирования, использования параллельных алгоритмов или хотя бы примитивов с самого начала решения задачи, несмотря даже на споры о том, как мыслит человек — последовательно, параллельно? или, возможно, объектно-ориентированно? — исходный (т.е. первоначальный) код человек пишет в большинстве случаев последовательно. И проблема даже не в том, что последовательно написан первый вариант кода, проблема в том, что второй вариант кода тот же самый человек с большой вероятностью писать уже не будет.
Сразу оговорюсь, что я не претендую на полноту описания всего мира программирования, но в научной, инженерной среде по-прежнему действует стандартная установка: есть задача, кем-то (чаще всего, не тобой) алгоритмически решенная в последовательном режиме, есть одна или несколько доступных архитектур, и, будь добр, “параллель”.
Но одна параллельная платформа — рознь другой. 
Программирование задачи для архитектуры CUDA - обычно, задача иного порядка, чем разделения на несколько нитей для многоядерного CPU. Совершенно особой задачей является и распараллеливание для кластерной архитектуры с применением интерфейса передачи сообщений MPI.
С чего же начать написание параллельной программы? Как в зависимости от платформы выбрать стратегию распараллеливания? Насколько велика вероятность получить эффективный результат?
Практически невозможно найти данные о “чистом” эксперименте в данной области — ситуации, когда конкретная задача решается на нескольких платформах людьми с примерно статистически равным уровнем подготовки. Действительно, как собрать достаточное число испытуемых и где найти платформу для проведения такого эксперимента?
Специалисты, работающие в области HPC, обычно заняты своим делом, то есть сфокусированы на своей узкой задаче и целевой платформе, у них есть устоявшийся “паттерн” решения задачи распараллеливания, полученный из собственного опыта. Такой паттерн не обязательно является оптимальным, и не обязательно подходит в общем случае. Сбор информации постфактум об удавшихся и неудавшихся проектах по распараллеливанию высокопроизводительных вычислений — это крайне полезный шаг, но он не заменит собой эксперимент по сравнению параллельных платформ.
Единственная возможность провести такой эксперимент — провести его в рамках образовательного проекта.
Прекрасно, что это понимают в Московском Физико-Техническом Институте. Конечно, организаторы Школы вряд ли видели первоочередной задачей построение эксперимента по сравнению практики распараллеливания для различных архитектур, но, как бы то ни было, такой эксперимент был проведен, а у нас возникла возможность непосредственно поучаствовать в нем.

 

 
Комментарии
02.04.2011 18:33  |
Оставить комментарий.
Подпись
Код на картинке
© 2010-2016, ООО ПАРСЕР , Все права защищены.
Деловая сеть Санкт-Петербург и Ленинградская область. Жёлтые страницы, телефонный справочник и каталог компаний, товаров и услуг.
top.dp.ru