6. Последствия и воздействия HPF

Хотя проект HPF не является безоговорочно успешным, он оказал и оказывает огромное влияние на разработку высокоуровневых параллельных языков. В текущей базе данных CiteSeer насчитывается 827 ссылок на исходный технический проект 1993 года, который позже был опубликован в журнале Scientific Programming [50]. Это наиболее часто цитируемый в 21-м веке материал из области компьютерных наук (по данным CiteSeer). Кроме того, в более чем 1500 публикаций, сохраняемых в CiteSeer, упоминается «High Performance Fortran». Во многих этих статьях представлены различные подходы к реализации языка или его усовершенствованию, что показывает всплеск интеллектуальной активности в академических кругах, вызванный проектом HPF.

6.1. Последствия для языка Fortran и его вариантов

Fortran 95. В то время, когда происходили встречи, приведшие к определению HPF 1.1, организовывались и совещания комитета X3J3 ANSI с целью разработки стандарта Fortran 95 [1]. Эта группа долгое время отслеживала разработку HPF в надежде перенять наиболее удачные решения, и Джерри Вагенер (Jerry Wagener) исполнял роль неформального связного между двумя группами. Кен Кеннеди представил комитету X3J3 параллельные возможности HPF и убедился в том, что нет никаких проблем с авторскими правами, которые могли бы воспрепятствовать включению средств HPF в официальный стандарт языка Fortran. Когда стандарт Fortran 95 [1] был официально принят в 1996 г., он включал средства FORALL и PURE, почти дословно позаимствованные из HPF. Новый стандарт также включал менее существенные расширения MAXLOC и MINLOC, которые были перенесены в HPF Library из CM Fortran. В обеих группах HPFF и X3J3 это совместное использование наработок расценивалось как положительное явление.

HPF/JA. В 1999 г. ассоциация Japan Association for High Performance Fortran, консорциум японских компаний, включающих Fujitsu, Hitachi и NEC, выпустила спецификацию HPF/JA [86], которая включала ряд средств из предыдущих языков программирования для параллельно-векторных машин компаний Hitachi и NEC. Важным вкладом в HPF/JA явился язык HPF+ [11], разработанный и реализованный в рамках европейского проекта, который выполнялся венской группой с участием NEC в качестве партнера. В языке HPF+, созданном на основе анализа развитых индустриальных программ, обеспечивался раздел REUSE для указания независимых циклов, с помощью которого определялось утверждения о повторной используемости расписания коммуникаций, вычисляемого при первом исполнении цикла. В том же контексте была введена конструкция HALO языка HPF+, позволяющая функционально специфицировать доступ к нелокальным данным в процессорах и обеспечить контроль пользователей над копированием таких данных в границах региона.

Эти и другие средства обеспечивали улучшенное управление локальностью в программах HPF/JA. Например, можно было использовать директиву LOCAL для указания того, что в некоторых ситуациях, которые трудно различить компилятору, для доступа к данным не требуются коммуникации. Кроме того, в HPF/JA присутствовала директива REFLECT, соответствующая директиве HALO языка HPF+. HPF/JA был реализован в обсуждаемом ниже проекте Japanese Earth Simulator [86].

OpenMP. Наконец, авторы комментируют взаимосвязи между HPF и OpenMP [73, 33]. Спецификация OpenMP была предложена как расширение языков Fortran, C и C++, обеспечивающее набор директив, которые поддерживали хорошо обоснованный интерфейс переносимого программирования для архитектуры SMP, основанный на модели «разветвление/соединение» (fork/join) параллельных вычислений. В этом стандарте развивалась работа, выполненная группой Parallel Computing Forum (PCF) в составе комитета по стандартизации X3H5 [66], и расширялся набор директив компании SGI для программирования с использованием разделяемой памяти. Разработчики OpenMP следовали модели HPF, специфицируя все средства в форме директив, которые могли игнорироваться компиляторами для монопроцессоров. Большая часть средств OpenMP была полностью совместима с HPF: в действительности, конструкции организации параллельных циклов в основном являлись расширениями соответствующих конструкций HPF.

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

Этот недостаток скоро был осознан, и был предпринят ряд попыток интегрировать OpenMP с языковыми средствами, которые поддерживали программирование с учетом локальности [72, 13]. Однако в текущем стандарте OpenMP не поддерживается ни одно их этих предложений. На самом деле, недавняя разработка языков высокой производительности (High Productivity Languages) может привести к тому, что подобные попытки устареют, поскольку во всех этих языках многопотоковость и учет локальности искусным образом интегрируются.

В заключение интересно отметить, что группа по разработке OpenMP, которая начала свою работу после выпуска HPF 1.0, определила синтаксис своих директив таким образом, что он оказался несовместимым с синтаксисом HPF. (Со своей стороны, группу OpenMP, вероятно, могло сбить с толку то, что в HPF был определен собственный синтаксис, а не использовались существующие конструкции PCF.) Лидеры обеих групп несколько раз встречались для изучения возможности унификации языков, поскольку это обеспечило бы каждому из них требуемые функциональные возможности, но совместный проект по стандартизации так и не был начат.

Использование HPF. После исходного выпуска High Performance Fortran состоялись три собрания группы пользователей HPF: первый в Санта Фе (Santa Fe, NM, 24-26 февраля 1997 г.), второй в Порто, Португалия (25-26 июня 1998 г.) и третий в Токио, Япония (18-20 октября 2000 г.). Во время этих собраний был проведен опрос пользователей для определения способов использования HPF и путей его дальнейшего развития. Доклады, представленные на собрании в Токио, вошли в специальный сдвоенный выпуск журнала Concurrency, Practice and Experience (Volume 14, Number 8-9, August 2002). Собрание в Токио показало сохранение высокого уровня заинтересованности в HPF в Японии. Позже этот интерес был подтвержден установкой системы Japanese Earth Simulator [86] и началом ее использования для прогона приложений. В Earth Simulator присутствовала реализация HPF с поддержкой широкого набора функциональных возможностей, изначально основанная на компиляторе компании Portland Group, в котором поддерживались расширения HPF/JA. В специальном выпуске Concurrency, Practice and Experience описывались два приложения, которые были перенесены в среду Earth Simulator и достигли производительности около 10 Teraflops. Приложение Impact3D показало производительность почти в 15 Teraflops, что составило около 40% пиковой скорости машины [82]; за это достижение разработчики приложения были удостоены награды Gordon Bell Prize на конференции SC2002. Ни одно из этих приложений не содержало явного использования MPI.

6.2. Языки HPCS

Хотя HPF потерпел неудачу на переднем крае разработки параллельных приложений, идеи этого языка проникают в более новые языки программирования. Недавно агентство DARPA (Defense Advanced Research Projects Agency) профинансировало разработку тремя коммерческими компаниями прототипов аппаратных и программных систем для проектов High Productivity Computing Systems (HPCS). Основной целью этой работы является ослабление бремени программирования передовых систем, основанных на инновационных архитектурах. Эти три компании предложили три новых языка: Chapel (Cray) [17, 20, 36], Fortress (Sun) [90] и X10 (IBM) [22]. Во всех них присутствует некоторая форма параллелизма по данным.

Chapel, Fortress и X10 – это новые объектно-ориентированные языки, поддерживающие широкий набор средств программирования, параллелизм и безопасность. Во всех них поддерживаются глобальное пространство имен, явная многопотоковость и явные механизмы для работы с локальностью. Имеются средства для распределения массивов по вычислительным узлам системы, а также для установления связи между потоками управления и данными, которые ими обрабатываются. Наконец, в этих языках поддерживаются как параллелизм по данным, так и задачный параллелизм. Поскольку разработчики языков HPCS были знакомы с опытом создания HPF, они создали средства поддержки параллелизма по данным, в которых устранены многие недостатки, описанные в разд. 4.

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

X10 основан на языке Java; однако средства языка Java для поддержки параллелизма и массивов заменены средствами, более уместными для высокопроизводительных вычислений, такими как разделение глобального адресного пространства. В отличие от этого, Chapel – это полностью новый язык, основанный на идеях, которые считаются наиболее перспективными идеями в современном объектно-ориентированном подходе.

Управление локальностью. Во всех трех языках обеспечивается доступ пользователей к виртуальным единицам локальности, называемых локалями (locale) в Chapel, регионами (region) в Fortress и участками (place) в X10. Каждое выполнение программы привязывается к некоторому набору таких единиц локальности, которые отображаются операционной системой на физические сущности, такие как вычислительные узлы. Это обеспечивает пользователей механизмом для (1) распределения коллекций данных по единицам локальности, (2) выравнивания различных коллекций данных и (3) установления связи между вычислительными потоками управления и данными, над которыми они работают. Этот подход является очевидным обобщением ключевых элементов HPF.

В Fortress и X10 обеспечиваются обширные библиотеки встроенных распределений, а также имеется возможность порождения новых, определяемых пользователями распределений данных путем декомпозиции пространства индексов или комбинирования распределений в разных измерениях. В Fortress все массивы распределяются по умолчанию; если для некоторого массива никакое распределение не специфицировано, то ему назначается распределение по умолчанию. С другой стороны, в Chapel отсутствуют встроенные распределения, но обеспечивается обширная инфраструктура, которая поддерживает произвольные распределения данных, определяемые пользователями и являющиеся достаточно мощными для того, чтобы позволить работу с разреженными данными [36]. В X10 имеется «правило локальности» (Locality Rule), запрещающее в любой активности непосредственные чтение/запись по ссылкам на удаленные местоположения. В Chapel и Fortress на уровне исходного кода не проводится различие между локальными и удаленными ссылками.

Многопотоковость. В HPF параллельные циклы определяются с использованием атрибута независимости (independent attribute), который позволяет специфицировать утверждение о том, что цикл не содержит каких либо внутренних зависимостей. Это исключает ситуацию гонок данных. В Chapel различаются последовательные циклы «for» и параллельные циклы «forall», в которых итерации над элементами индексной области производятся без ограничений, аналогичных тем, которые в HPF вызывает наличие атрибута независимости. Таким образом, за избежание зависимостей, приводящих к гонкам данных, отвечают пользователи.

В Fortress цикл «for» по умолчанию является параллельным, так что, если итерации цикл выполняются над распределенным измерением массива, эти итерации будут группироваться по процессорам в соответствии с распределениями данных. Для сериализации цикла «for» можно использовать специальное «последовательное» распределение. Компилятор Fortress и система поддержки времени выполнения могут реорганизовывать исполнение программы для улучшения производительности, если при этом сохраняется ее смысл в рамках семантики организации циклов на основе распределения данных. В частности, распределение данных, по существу, приводит к суперазделению (overpartition) индексного пространства, так что операции можно динамически перемещать на свободные процессоры для балансировки нагрузки.

В X10 различаются два вида параллельных циклов: цикл «foreach», который ограничен единственной единицей локальности, и цикл «ateach», позволяющий выполнять итерации над несколькими единицами локальности. Как и по отношению к обсуждавшемуся выше «правилу локальности», разработчики X10 следуют здесь более консервативной стратегии, чем разработчики Chapel и Fortress, вынуждая программиста различать эти два случая.

6.3. Параллельные скриптовые языки Fortran и C

Хотя сообщества Fortan и C были склонны мириться с трудностями написания MPI-кода для масштабируемых параллельных машин, похоже, что к этому была не готова большая группа пользователей высокоуровневых скриптовых языков, таких как Matlab, R и Python. Популярность этих языков частично объясняется их простотой. Тем не менее, имеется реальный интерес к возможности написания на этих языках параллельных программ. В результате в ряде исследовательских и коммерческих проектов, включающих MathWorks, изучались возможности применения стратегий параллельного программирования, в особенности, в Matlab [76, 35, 55, 61]. В большинстве этих проектов стандартное представление массивов, принятое в Matlab, заменялось представлением глобальных распределенных массивов, и все стандартные операции над массивами заменялись распределенными операциями. Хотя это соответствует духу HPF, накладные расходы на создание вручную библиотек операций и коммуникаций ограничивает число разных распределений, которые могут поддерживаться в таких системах. Поэтому большинство текущих реализаций ограничивается распределениями, поддерживаемых ScaLAPACK, параллельной версией библиотеки LAPACK, который используется для реализации операций над массивами в продукте Matlab.

Проект, недавно начатый в университете Rice и возглавляемый Кеннеди, направлен на расширение технологии компиляции Rice HPF, описываемой в разд. 7, для обеспечения более обширного набора распределений массивов. Основная идея этой работы состоит в создании библиотеки операций над распределенными массивами в HPF и обеспечении возможности компилятору HPF адаптировать эти библиотечные подпрограммы ко всем поддерживаемым распределениям. В настоящее время в список поддерживаемых распределений входят sequential(*), block, block-cyclic и block(k) в каждом измерении плюс новое двухмерное распределение, называемое «multipartitioning», которое полезно для достижения максимально возможной производительности на эталонных тестовых наборах NAS Parallel Benchmarks. Однако обдумывается и ряд новых распределений, которые должны быть реализованы в ближайшем будущем.

Целью этих работ является обеспечение сообщества пользователей скриптовых языков, в особенности, пользователей Matlab простым методом достижения достаточно масштабируемого параллелизма при минимальном изменении их программ. Если усилия исследователей университета Rice окажутся успешными, то это позволит не только обосновать общий замысел работ, проводимых после неудачи с HPF, но также существенно расширить сообщество разработчиков приложений для масштабируемых параллельных машин.