7. Полученные уроки

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

Во-первых, за двенадцать лет, прошедших после выпуска HPF 1.0, удалось многое узнать о технологии компиляции. Понятно, что при применении первых компиляторов HPF было трудно достичь высокой производительности. Распространенной практикой являлась перепись прикладных тестовых наборов для использования сильных сторон компилятора HPF в расчете на конкретную целевую машину. Другими словами, разработчикам приложений приходилось переписывать приложение для каждой новой платформы. Показательным примером являются параллельные тестовые наборы NAS. В версию HPF тестовых наборов NAS был включен набор HPF-программ, написанных инженерами компании Portland Group. Эти тестовые программы были разработаны с целью достижения наибольшей возможной производительности с использованием компилятора Portland Group. Они позволяли избежать просчетов в генерации кодов, которые могли бы подорвать эффективность генерируемого кода. К сожалению, это подрывало цель HPF – обеспечение возможности кодировать приложение в машинно-независимой форме и его компиляции без каких-либо изменений для различных платформ. Иначе говоря, практика кодирования с учетом особенностей целевой машины подрывала простоту использования HPF, приводя к существенным затратам времени при переносе программ с одной платформы на другую.

В последние десять лет основной целью исследовательской работы в университете Rice, возглавляемой Джоном Меллор-Крумми (John Mellor-Crummey), было достижение высокой производительности на HPF-программах, которые получались путем внесения минимальных изменений в программы, ранее написанные на Fortran 90. Если говорить о параллельных тестовых наборах NAS, то это означало, что последовательную программу на Fortran 90 (со встроенным параллельным алгоритмом) нужно было бы изменить только путем добавления соответствующих директив распределения данных: все остальной должно было быть сделано компилятором. Окончательной целью являлась генерация кода, который мог бы конкурировать по производительности с написанными вручную MPI-версиями программ, разработанных для тестовых наборов NAS.

Этой цели невозможно было достичь с использованием компилятора dHPF, разработанного в проекте университета Rice, потому что в MPI-версиях использовалось распределение, называемое «мультиразделением» (multipartitioning), которое не поддерживалось ни в HPF 1.0, ни в HPF 2.0. После того как исследователи из университета Rice добавили мультиразделения к набору распределений, поддерживаемых dHPF, они смогли достичь производительности, которая всего на несколько процентов отличалась от производительности вручную написанных MPI-версий приложений SP и BT из набора NAS [25].

Этот результат подтверждается опытом использования HPF в среде Earth Simulator и последующим экспериментом, в котором компилятор dHPF транслировал приложение Impact3D для системы Lemieux Питтсбургского суперкомпьютерного центра (Pittsburgh Supercomputer Center; система основывалась на процессорах Alpha и коммутаторах компании Quadrics). На полученном целевом коде удалось добиться производительности в 17% от пиковой производительности системы при числе процессоров от 128 до 1024 (в последнем случае была достигнута производительность в 352 Gigaflops, что, вероятно, является национальным рекордом США для HPF-программ) [24].

Эксперименты с мультиразделением иллюстрируют еще один важный аспект расширения области применимости языков с распараллеливанием по данным: требуется найти некоторый способ увеличения числа распределений, доступных для конечных пользователей. К сожалению, мультиразделение – это всего лишь одно из многих возможных распределений, которые может понадобиться внедрить в компилятор HPF; еще пару распределений представляют обобщенное блочное и косвенное распределения, введенные в HPF 2.0. Имеется много других распределений, которые можно было бы использовать для достижения высокой производительности при использовании конкретных приложений на конкретных параллельных системах. Базовая система не может поддерживать все возможные полезные распределения. Из этого следует потребность в некотором механизме, позволяющем добавлять в систему распределения, определяемые пользователями. Если бы имелась возможность определения интерфейса распределений и оптимизаций компилятора в терминах этого интерфейса, то можно было бы достичь цели разделения структур данных и распределений данных. В результате можно было бы значительно увеличить гибкость языка. В настоящее время исследования в этой области проводятся в контексте языка программирования Chapel, разрабатываемого в проекте Cascade. В Chapel [17] не поддерживаются какие-либо встроенные распределения, но имеется интерфейс класса распределений, позволяющий явно специфицировать отображения, определять последовательные и параллельные итераторы и, при необходимости, контролировать представлений распределений и структур локальных данных.

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

Одной из причин успеха MPI являлось наличие достаточно качественной эталонной реализации, называемой MPICH. Аналогичная эталонная реализация компилятора HPF и HPF Library была бы существенной поддержкой языка HPF. Компилятор компании Portland Group близко подошел к тому, чтобы его можно было считать эталонной реализацией HPF, но не было соответствующей стандартизованной реализации библиотеки. Несколько лидеров из сообщества разработчиков компиляторов и библиотек HPF обсуждало возможность получения федеральной поддержки для обеспечения эталонной реализации HPF Library, но финансирование так и не было открыто. Это было особенно печально по той причине, что очень хорошая реализация большей части требуемых функциональных возможностей имелась в составе библиотеки CMSSL (Connection Machine Scientific Subroutine Library), входившей в систему поддержки выполнения CM Fortran компании Thinking Machines. Когда компания Thinking Machines вышла из бизнеса и была продана компании Sun Microsystems, можно было сэкономить на разработке требуемых функциональных средств, если бы имелась государственная поддержка, но и эта возможность была упущена.

Отдельный класс проблем связан со средствами настойки производительности для HPF. Как отмечалось выше, сотрудничество между разработчиками компиляторов и соответствующих инструментальных средств могло бы обеспечить возможность отображения информации о производительности в код программ на HPF: примерами являются использование системы Pablo совместно с компиляторами dHPF и Portland Group [2]. Трудность состояла в том, что у пользователей имелись лишь ограниченные возможности мелкоструктурного управления генерацией кода после обнаружения источника узких мест в производительности. По сути, эти возможности сводились к использованию директивы EXTRINSIC для перехода на уровень непосредственного применения MPI. В расширениях HPF/JA эта ситуация была немного улучшена за счет обеспечения более развитых средств управления локальностью. Однако совершенно ясно, что в языке требуются дополнительные средства, позволяющие при необходимости подменить стандартные действия компилятора. В противном случае на пользователей возлагается решение сложной обратной проблемы, когда в распределение или структуру цикла вносятся небольшие изменения в надежде на то, что это заставит компилятор сделать именно то, что от него в данном случае требуется.

В заключение авторы отмечают отсутствие терпения в сообществе пользователей. Действительно, High Performance Fortran был введен в производственный режим раньше времени, не достигнув должной зрелости, но если бы пользователи оказывали давление на разработчиков с целью совершенствования языка и его реализаций, а не просто переходили на использование MPI, можно было бы добиться того, чтобы обеспечивалась, по крайней мере, одна высокоуровневая программная модель для параллельного программирования. Как показывают работы в университете Rice и Японии, при использовании правильной технологии компиляции HPF может обеспечить высокую производительность, в особенности, при наличии средств, обеспечивающих контроль пользователей над производительностью. К сожалению, сообщество в Соединенных Штатах ждать не захотело. Федеральное правительство Соединенных Штатов могло бы помочь стимулировать терпение пользователей путем финансирования одного или нескольких фундаментальных прикладных проектов, направленных на использование новых инструментов, подобных HPF, а не просто добиваться как можно более быстрого выполнения приложений на параллельных платформах. Из-за этого отсутствия терпения и поддержки вторая волна разработчиков параллельных приложений не может получить пользу из опыта первой волны. Это является упущенной возможностью сообщества HPC.

8. Заключение

High Performance Fortran не смог достичь того уровня успеха, на который надеялись его создатели. Для этого имеется несколько причин: недостаточно зрелая технология компиляции, ведущая к плохой производительности; отсутствие гибких распределений данных; несогласованные реализации; отсутствие требуемых инструментальных средств, отсутствие терпения в сообществе пользователей. Тем не менее, HPF привнес ряд важных идей, которые будут использованы в следующем поколении высокопроизводительных компьютерных языков. К числу этих идей относятся однопотоковая модель выполнения с использованием глобального адресного пространства; интерперабельность с другими языковыми моделями; обширная библиотека примитивных операций для параллельных вычислений. Кроме того, в течение десятилетних исследований и разработок удалось преодолеть многие препятствия на пути эффективной реализации. Возможно, настало время для того, чтобы сообщество HPC еще раз попыталось воспользоваться новыми моделями программирования с распараллеливанием по данным, похожими на модель, поддерживаемую в HPF.