4. Опыт использования языка

Первую реакцию на появление HPF можно охарактеризовать как осторожный энтузиазм. Большая часть сообщества пользователей, которая еще не переписала свои приложения с использованием средств явной передачи сообщений, надеялась на то, что этот язык обеспечит высокоуровневый программный интерфейс для параллельных машин, позволяющий сделать параллельные программы переносимыми и эффективными без потребности в ручном написании коммуникационного кода с использованием MPI или подобных ему средств. С другой стороны, поставщики надеялись на то, что появление HPF позволит расширить рынок масштабируемых параллельных компьютеров настолько, что это повысит прибыльность их бизнеса. Некоторые поставщики, включая Digital [46], IBM [43] и Thinking Machines, инициировали независимую разработку компиляторов. Ряд других поставщиков предлагал пользователям варианты компиляторов, созданные независимыми производителями программного обеспечения, такими как Portland Group, Inc. (PGI) [15] и Applied Parallel Research [8]. На пике этой активности 17 поставщиков предлагали продукты HPF и более 35 крупных приложений, написанных на HPF, по крайней мере, в одном из которых содержалось более 100000 строк исходного кода.

Тем не менее, по мере накопления опыта использования языка возрастало и разочарование части пользователей. Становилось понятно, что с использованием HPF не так уж просто добиться ожидавшихся высокой эффективности и переносимости программ, и многие разработчики программного обеспечения отказывались от применения HPF и переключались на использование MPI. К концу 1990-х гг. поток использования HPF в США практически иссяк, хотя, в Японии сохранялся высокий уровень интереса к этому языку (см. ниже).

Почему же HPF не добился большего успеха, хотя язык опирался на вполне разумные идеи о том, как можно расширить существующий язык для включения в него поддержки параллелизма по данным? С точки зрения авторов, это было вызвано четырьмя основными причинами: (1) недостаточно развитой технологией компиляции и отсутствием терпения в сообществе HPC; (2) недостаточной поддержкой важных средств, которые сделали бы язык пригодным для решения широкого набора проблем; (3) несогласованностью реализаций, мешавшей пользователям достичь переносимой эффективности своих программ; (4) сложностью взаимосвязей между программой и производительностью, которая затрудняла определение и устранение проблем, связанных с производительностью. В следующих ниже подразделах эти причины анализируются более подробно.

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

Во-первых, HPF определялся поверх стандарта Fortran 90, который являлся первой крупной модернизацией стандарта языка Fortran с 1977 г. Кроме того, расширения Fortran 90 были непростыми: для их реализации требовались огромные усилия разработчиков компиляторов. К числу новых средств, добавленных в Fortran 90, относились следующие: (1) механизмы полной и частичной обработки массивов, для поддержки которых требовались реализации, основанные на использовании дескрипторов массивов, и «скаляризация» присваиваний массивов; (2) модули и блоки интерфейсов (которые требуются в HPF для спецификации распределений массивов, передаваемых в подпрограммы); (3) рекурсия; (4) динамическое распределения памяти и структуры данных, основанные на указателях. Поскольку ни одно из этих средств не присутствовало в Fortran 77, для построения компилятора Fortran 90 требовалось значительное изменение реализации, в которой должны были появиться стековые фреймы для поддержки рекурсии, динамически распределяемая память и дескрипторы массивов. Для перехода от Fortran 77 к Fortran 90 требовалась работа, соизмеримая с работой по созданию компилятора с нуля (за исключением низкоуровневой генерации кода). Ко времени появления в 1993 г. первой спецификации HPF в большинстве компаний еще не были выпущены первые компиляторы для Fortran 90. Поэтому для реализации HPF этим компаниям сначала нужно было почти полностью реализовать Fortran 90, что сильно препятствовало принятию HPF.

Во-вторых, полный набор средств HPF, включая HPF Library, был достаточно обширным, и для его реализации требовались новые стратегии компиляции, которые к моменту выпуска HPF 1.0 были опробованы только в исследовательских компиляторах и в компиляторе CM Fortran. Для корректной компиляции HPF-программ требовались обширный глобальный анализ распределений, разделение вычислений, генерация коммуникационного кода и оптимизации, такие как чередование коммуникаций и вычислений. Для хорошей реализации всего этого требовалась зрелая технология компиляции, достигаемая лишь с годами, даже если бы предусловием не являлась реализация Fortran 90.

Наконец, для эффективной реализации HPF-программ требовалось, чтобы в компиляторе особое внимание уделялось локальности на отдельных процессорах. Поскольку большую часть процессоров, использовавшихся в системах с распределенной памятью, составляли монопроцессоры со сложной иерархией кэшей, для генерации эффективного кода требовалось использование развитых стратегий преобразования, таких как нарезка циклов (loop tiling) для обеспечения повторного использования кэша. Ко времени выпуска начальной спецификации HPF эти методы становились все более понятными [39, 98, 64], но они еще не использовались в большинстве коммерческих компиляторов [84, 28].

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

Тем временем, у разработчиков параллельных приложений имелись свои временные ограничения, которые не позволяли им дожидаться поры зрелости HPF. Вместо этого они обращались к использованию языка Fortran с явными вызовами MPI, т.е. программной модели, которая была достаточно сложной, но, по крайней мере, готовой для применения. Миграция на платформу MPI существенно снизила потребность в HPF, что привело к сокращению объема работ коммерческих компаний по разработке компиляторов (а иногда и прекращению этой работы). В результате HPF так никогда и завоевал уровня признания в среде пользователей передовых параллельных компьютеров, достаточного для достижения успеха. Можно достаточно точно сказать, что HPF упустил первую волну разработчиков приложений и, по существу, умер (или, по крайней мере, стал восприниматься как неудачная попытка) до появления второй волны.

Отсутствующие средства. Для достижения высокой производительности на различных приложениях и алгоритмах в модели параллельного программирования должны поддерживаться различные разновидности распределений данных. Это особенно важно для разреженных структур данных и адаптивных алгоритмов. В исходную спецификацию HPF были включены только три основных распределения: BLOCK, CYCLIC и CYCLIC(K). Эти распределения были эффективными для вычислений над плотными массивами, а в случае CYCLIC(K) – даже для вычислений линейной алгебры. Однако многие важные алгоритмические стратегии было затруднительно, а иногда и невозможно выразить средствами HPF без большой потери производительности. Этот недостаток заметно сужал пространство приложений, которые можно было бы эффективно выразить средствами HPF. В результате разработчики приложений, которым требовались распределения, не поддерживаемые в HPF, переходили к использованию MPI. Хотя эта проблема была частично устранена в стандарте HPF 2.0 (обсуждаемом ниже), вред был уже нанесен. В заключительном разделе этой статьи авторы предлагают стратегию для решения этой проблемы в будущих языках с распараллеливанием по данным.

Второй проблемой использования HPF являлась ограниченная поддержка параллелизма на уровне задач. Немного выручала возможность параллельных циклов, но пользователям требовались более мощные стратегии задачного параллелизма. Опять же, этот недостаток был исправлен в HPF 2.0, но было слишком поздно. Должно было произойти слияние возможностей HPF и OpenMP, обсуждаемое ниже.

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

Во-первых, разные поставщики компиляторов концентрировались в своих реализациях HPF на разных видах оптимизации. Это приводило к тому, что одно и то же приложение HPF демонстрировало существенно разную производительность на машинах разных поставщиков. В свою очередь, это вынуждало пользователей переписывать приложений для каждой новой машины для получения преимуществ от сильных сторон (и во избежание отрицательного влияния слабых сторон) реализации каждого поставщика, что противоречило исходной цели абсолютной переносимости.

Во-вторых, для решения некоторых проблем удобства использования и производительности можно было использовать библиотеку HPF Library, описанную в предыдущих разделах. Например, для реализации вычислений над разреженными массивами можно было использовать примитивы gather и scatter. Однако отсутствовала эталонная реализация этой библиотеки с открытыми исходными текстами, так что в каждом проекте по разработке компилятора приходилось реализовывать собственную версию библиотеки. Количество и сложность компонентов библиотеки делали эту реализацию очень обременительной. Конечный результат состоял в том, что библиотеке уделялось недостаточное внимание, ее реализации были несогласованными и, как правило, не обеспечивали должную производительность. Поэтому пользователям снова приходилось кодировать свои приложения по-разному для разных целевых машин, используя те библиотечные подпрограммы, которые обеспечивали наилучшую производительность.

Трудности при настройке производительности. Все известные авторам компиляторы HPF производили трансляцию исходных текстов на HPF в тексты на языке Fortran плюс MPI. В процессе трансляции выполнялись многие существенные преобразования, которые затемняли связи между тем, что написал разработчик, и тем, что выполнялось на параллельной машине. Это затрудняло распознавание пользователями проблем производительности и их устранение.

Для решения проблемы распознавания проблем производительности группа разработчиков из университета Rice совместно с группой Дэна Рида (Dan Reed) из Иллинойского университета выполнила работу по отображению в исходные тексты программ на HPF диагностики, выдаваемой системой Pablo Performance Analysis, которая была основана на архитектуре передачи сообщений [2]. Эта работа была исключительно эффективной, и соответствующая реализация была выполнена, по крайней мере, для одного коммерческого компилятора, но проблеме настройке в ней уделялось недостаточное внимание. Другими словами, пользователь мог хорошо разобраться в том, что вызывает проблему производительности, но не иметь никаких идей насчет того, каким образом следует изменить текст программы на HPF, чтобы преодолеть эту проблему. Конечно, пользователь мог использовать интерфейс EXTRINSIC, чтобы спуститься на уровень MPI, но это сводило на нет все преимущества от использования HPF.

Проблема распознавания проблем производительности в контексте настройки производительности также решалась группой Vienna Fortran в сотрудничестве с группой Марии Калцаросса (Maria Calzarossa) из итальянского университета Pavia. В этом проекте разрабатывался графический интерфейс, на основе которого явно параллельный, основанный на MPI целевой код совместно с информацией о производительности, обеспечиваемой инструментальным средством MEDEA, мог привязываться к соответствующим исходным операторам. Например, с использованием этого средства программист, знакомый с принципами генерации кода для независимого цикла на основе парадигмы инспектор/исполнитель [83], мог на основе анализа выяснить, является ли источником проблемы производительности время, требуемое для выполнения работы по распределению данных, (автоматическая) генерация расписания коммуникаций инспектором или же реальные коммуникации, сгенерированные для выполнения цикла.

5. Процесс стандартизации HPF 2

В стремлении исправить некоторые недостатки в HPF 1.0 и 1.1 HPF Forum в 1995-1996 гг. предпринял вторую попытку стандартизации. Эта работа привела к созданию стандарта HPF 2.0, в который вошел ряд новых средств:

1. Раздел REDUCTION директивы INDEPENDENT, определяющей независимые циклы. Этот раздел существенно расширял множество случаев, в которых была применима директива INDEPENDENT. (В HPF 1.0 имелся раздел NEW директивы INDEPENDENT, разрешающий наличие «локальных» переменных в каждой итерации цикла, но отсутствовал какой-либо прямой способ выполнения простого суммирования.)
2. Новые процедуры HPF Library SORT_DOWN, SORT_UP для выполнения сортировки. (В HPF 1.0 имелись функции GRADE UP и GRADE DOWN, которые производили вектора перестановок, а не сортировали элементы непосредственно.)
3. Расширенные возможности отображения данных, включая отображение объектов на подмножества множества процессоров; отображения указателей и компонентов производных типов; схемы распределения GEN BLOCK и INDIRECT, а также модификаторы распределения RANGE и SHADOW. (Как отмечалось выше, в HPF 1.0 поддерживались только регулярные схемы распределения данных.)
4. Расширенные возможности управления параллельными вычислениями, включая директиву ON для спецификации процессора, на котором должны производиться вычисления, и директива TASK REGION, обеспечивающая выполнение крупноблочных параллельных задач. (В HPF 1.0 все отображения вычислений возлагались на компилятор и систему поддержки времени исполнения.)
5. Множество дополнительных внутренних и библиотечных (из HPF Library) процедур, в основном, имеющих дело с поддержкой запросов и управления распределениями данных. (В HPF 1.0 имелась некоторая поддержка этих возможностей, но оказалось, что требуется большее количество средств.)
6. Поддержка асинхронного ввода/вывода с использованием нового оператора WAIT, а также дополнительного управляющего параметра ввода/вывода в операторе языка Fortran READ/WRITE. (В HPF 1.0 средства ввода/вывода игнорировались.)

За исключением первых двух пунктов этого списка, новые возможности относились скорее к «усовершенствованным расширениям» («Approved Extensions»), а не к «базовому языку» («Core Language»). Группа HPFF предполагала, что поставщики незамедлительно реализуют средства базового языка (например, раздел REDUCTION), а расширения будут реализовываться в соответствии с приоритетами, устанавливаемыми требованиями заказчиков. Не удивительно, что это привело к неразберихе в наборах средств, предлагаемых в продуктах разных поставщиков. Насколько известно авторам, ни одна коммерческая компания или исследовательская группа даже и не попыталась реализовать полный набор усовершенствованных расширений.