Аппаратный параллелизм и программисты: кто когоПервую обзорную статью тематической подборки, озаглавленную «Параллелизм на основе использования многопотоковых и многоядерных процессоров» (Parallelism via Multithreaded and Multicore CPUs), написали Анжела Содан (Angela Sodan), Джекоб Мэчина (Jacob Machina), Араш Десмех (Arash Deshmeh), Кевин Макнотон (Kevin Macnaughton) и Брайан Исбауф (Bryan Esbaugh). В статье сравниваются многоядерные и многопотоковые процессоры, присутствующие на сегодняшнем рынке, и анализируются проблемы создания программного обеспечения для достижения требуемых характеристик работы приложений и необходимой загрузки.

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

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

Сначала появились многопотоковые процессоры, в которых на аппаратном уровне поддерживалось переключение контекстов между потоками, что позволяло сократить время простоя ресурсов в сложных суперскалярных процессорах. Вскоре удалось интегрировать в одном кристалле несколько процессорных ядер, и теперь имеются уже восьмиядерные процессоры. В предположении, что закон Мура остается в силе, можно ожидать удвоения числа ядер в чипе каждые два года.

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

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

Разработчики могут опираться на широко распространенную в области высокопроизводительных вычислений модель программирования c использованием общей памяти OpenMP (openmp.org/wp). Другим перспективным направлением является использование транзакционной памяти, упрощающей координацию доступа к данным на основе автоматических механизмов установки контрольных точек и откатов транзакций. Во многих случаях наиболее экономичным подходом оказывается применение библиотек уже распараллеленных программ, например, BLAS (Basic Linear Algebra Subprograms).

Группа авторов из корпорации Intel – первым в списке указан Мойше Бах (Moshe Bach) – представила статью «Анализ параллельных программ с использованием Pin» (Analyzing Parallel Programs with Pin).

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

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

Pin2 (www.pintool.org) – программная система бинарной инструментовки во время выполнения приложений для Linux и Windows. Целью Pin является обеспечение платформы инструментовки для построения разнообразных средств анализа, называемых pintool. Во время выполнения приложений Pin устраняет потребность в изменении и повторной компиляции исходного кода приложений. Инструментовка производится с применением динамически генерируемого кода.

Название следующей статьи – «Auto-Pipe: организация потокового выполнения приложений в архитектурно разнотипных системах» (Auto-Pipe: Streaming Applications on Architecturally Diverse Systems). Ее написали авторы из Вашингтонского университета в Сент-Луисе, и первым в длинном списке авторов стоит Роджер Чемберлейн (Roger Chamberlain).

Выявление и последующее применение потоковой семантики данных в приложениях может упростить процесс разработки, позволяет полнее использовать возможности параллелизма, сократить число конфликтов и ошибок синхронизации и с меньшими усилиями добиться корректного выполнения приложений. Примерами языков, поддерживающих непосредственное выражение семантики потоковых данных, являются Brook (graphics.stanford.edu/projects/brookgpu/lang.html) и StreamIt (groups.csail.mit.edu/cag/streamit). Вычислительные блоки, называемые ядрами (kernel) в Brook и фильтрами (filter) в StreamIt, связываются посредством явно определенных соединений (edge), через которые перемещаются блоки данных в некой фиксированной топологии, заданной во время компиляции. Семантика потоковых данных свойственна многим, хотя и не всем приложениям.

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

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

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

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

Авторами последней статьи тематической подборки «Инструментальные средства для очень быстрого сопоставления регулярных выражений» (Tools for Very Fast Regular Expression Matching) являются исследователи из IBM Давиде Пасетто (Davide Pasetto), Фабрицио Петрини (Fabrizio Petrini) и Вират Агарвал (Virat Agarwal).

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

В разработанном авторами программном средстве DotStar обеспечивается алгоритмическое решение и набор программных инструментов, которые могут преобразовать набор задаваемых пользователями регулярных выражений в последовательность промежуточных представлений и организовать автоматический поиск соответствий за один проход без возвратов. В DotStar поддерживается расширенный синтаксис регулярных выражений в соответствии со стандартом POSIX.

При создании DotStar ставилась цель разработать практичные алгоритмы, которые бы масштабировались как по скорости обработки, так и по сложности исходных данных и которые могли использоваться на существующих и ожидаемых компьютерных архитектурах, в частности на многоядерных мультипроцессорах с поддержкой векторных инструкций. В большинстве современных массовых процессоров имеется от 2 до 64 ядер и обеспечивается некоторая поддержка векторной обработки данных. При использовании многоядерных процессоров совместно с тщательно разработанными алгоритмами удалось добиться скорости обработки, более чем на порядок превышающей скорость традиционных последовательных алгоритмов.

Вне тематической подборки опубликованы две большие статьи. Статья «Верификация контрактов интерфейсов Web-сервисов во время выполнения» (Runtime Verification of Web Service Interface Contracts) представлена Сильвайном Халле, Тевфиком Бултаном, Грехэмом Хафсом, Муатом Алкалафом и Роджером Виллимейром (Sylvain Hallй, Tevfik Bultan, Graham Hughes, Muath Alkhalaf, Roger Villemaire).

AJAX (Asynchronous JavaScript and XML) – набор технологий, используемых для разработки развитых интерактивных Web-приложений. Типичный AJAX-клиент локально выполняется в браузере пользователя и обновляет свой интерфейс на лету в соответствии с данными, вводимыми пользователем. Популярные AJAX-приложения, такие как Google Maps и Facebook, общаются с сервером в фоновом режиме. Когда пользователь вводит информацию на портал Facebook, приложение должно послать ее в свою удаленную базу данных. Когда пользователь перемещается по карте Google Maps, приложение требует от сервера новую часть изображения.

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

Авторы статьи экспериментировали с сервисом Amazon E-Commerce Service (см. рис). Эти эксперименты продемонстрировали преимущества модельного подхода к тестированию и отслеживанию Web-сервисов во время их выполнения. После создания формальной модели поведения Web-сервиса можно выполнять различные аналитические задачи без вмешательства пользователей. На первом шаге можно убедиться в правильности понимания документации путем автоматической генерации тестовых последовательностей, выполняемых над реальной реализацией Web-сервиса. Затем разработанный авторами легковесный монитор AJAX-приложений (beepbeep.sourceforge.net) обеспечивает соблюдение контрактов интерфейсов на стороне клиента, предупреждая пользователей о нарушениях контракта и препятствуя отправке ошибочных сообщений серверу.

Использование этого метода по отношению к AWS-ECS позволило автоматически сгенерировать тестовые последовательности и менее чем за три минуты тестирования выявить два отклонения в реализации сервиса от соответствующей документации. Кроме того, разработана инфраструктура, позволяющая отслеживать соблюдение контракта со стороны и клиента, и сервера с минимальными изменениями существующего кода AJAX-приложения. Накладные расходы составили примерно 10 микросекунд на каждое входящее и исходящее сообщение. Разработанные инструментальные средства позволяют применить данный подход к любому клиенту и сервису.

Последняя статья мартовского номера написана Суманом Мандалом (Suman Mandal), Раби Нахапатрой (Rabi Mahapatra), Правеном Бхожвани (Praveen Bhojwani) и Сараджу Моханти (Saraju Mohanty) и называется «IntellBatt: на пути к более интеллектуальным батареям» (IntellBatt: Toward a Smarter Battery).

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

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

Авторы разработали новую батарею IntellBatt, экономящую больше энергии и более безопасную, чем традиционные. Для IntellBatt характерно наличие «интеллектуального массива элементов батареи» (intelligent battery cell array, IBCA) с менеджером, функции которого выходят за пределы простого мониторинга. Этот менеджер активно планирует использование элементов для оптимизации времени жизни батареи, а также обеспечивает надежность и устойчивость питания:

  • тщательно отслеживает состояние элементов;
  • динамически выбирает элементы в соответствии с потребностями устройства;
  • использует эффекты восстановления заряда в элементах, что обеспечивает преимущество над монолитными батареями.

Батарея IntellBatt пригодна для любого переносного электронного оборудования. Ее можно использовать в автономном режиме или с применением метода BATS для повышения эффективности.

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

Удачи всем, до новой встречи, Сергей Кузнецов (kuzloc@ispras.ru).

Рис. Взаимодействие между AJAX-приложением и Amazon E-Commerce Service