Совместный Центр МГУ-Intel по высокопроизводительным вычислительным технологиям

Введение

В конце мая в Гамбурге, на международной конференции ISC'10 компания "Интел" анонсировала серию продуктов Intel Knights Ferry и Knights Corner. Эти продукты представляют собой продолжение разработок, ранее именовавшихся Intel Larrabee. В отличие от Larrabee, данная серия продуктов предназначена исключительно для суперкомпьютерного рынка; архитектура процессора осталась прежней. Уже имеются инженерные образцы процессора, которые доступны некоторым исследовательским организациям, а также лабораториям компании "Интел". На конференции SC'10 в Новом Орлеане работающий инженерный образец был впервые показан публике.

Knights Ferry будет иметь 32 ядра (Knights Corner — 50) с поддержкой системы команд x86_64. В отличие от ядер в традиционных процессоров, ядра Knights Ferry не поддерживают спекулятивного исполнения команд, что позволяет сократить площадь ядра на кристалле и таким образом повысить общее число ядер. Каждое ядро имеет кэш данных 1-го уровня размером 32 КБ, и кэш кода 1-го уровня такого же размера. Кэш данных второго уровня имеет размер 256 КБ. Поддерживается аппаратная многопоточность, что позволяет исполнять по 4 потока на ядро. Каждое ядро, помимо стандартных команд x86_64, поддерживает систему векторных команд с операндами размером 512 бит. Таким образом, одна такая векторная команда сможет обрабатывать 16 32-битных или 8 64-битных чисел. Если будет реализована поддержка 64-битных вещественных чисел (double), то один процессор Knights Corner с 50 ядрами на частоте 1.2 ГГц будет иметь пиковую производительность 960 ГФлоп/с с двойной точностью. При условии, что процессор Knights Corner будет выпускаться по 22-нанометровому техпроцессу и выйдет в конце 2011 — начале 2012 года, с такими характеристиками он сможет составить конкуренцию графическим процессорным устройствам (ГПУ), которые выйдут примерно в то же время.

В данной статье мы попытаемся проанализировать основные проблемы, с которыми может столкнуться Knights Ferry. Причём анализироваться будут проблемы не только технические, связанные с архитектурой и программированием, но и конъюнктурные.

Доступность

Доступность, или скорее её отсутствие, является основной проблемой, почему Knights Ferry редко упоминается в новостях и научных статьях — в среднем несколько новостей в месяц, не считая повторений. Конечно, пока процессор ещё не вышел, но и после его выхода доступность процессора будет оставаться проблемой.

Здесь следует заметить, что именно "демократичность" является основной причиной популярности конкурентов Knights Ferry. Видеокарту ГПУ NVidia с поддержкой CUDA и OpenCL можно купить менее чем за 100 $, стоимость видеокарт ГПУ AMD аналогична. Их можно установить в любой ПК. Инструменты для разработки на ГПУ также распространяются бесплатно. В результате получается очень низкий порог для вхождения в число ГПУ-разработчиков — порог, вполне доступный отдельным студентам.

Именно демократичность стала причиной широкого использования процессоров Cell BE. И хотя этот процессор также используется в суперкомпьютерах и даже установлен в Roadrunner, который в ноябрьском Top500 в 2008 году был суперкомпьютером №1, для решения вычислительных задач с помощью Cell BE чаще всего используется игровая консоль PlayStation 3, где он установлен в качестве ЦПУ. Более низкое распространение процессоров Cell BE по сравнению с ГПУ NVidia обуславливается более высокой сложностью программирования.

Практически все используемые в суперкомпьютерах процессоры и ускорители — будь то ГПУ AMD и NVidia, процессоры Cell BE, или процессоры с архитектурой x86_64 — имеют более "демократичные" аналоги.

И в этом смысле Knights Ferry оказывается в невыгодном положении. С одной стороны, стоимость одной карточки Knights Ferry будет составлять, очевидно, 2-3 тыс. $ — столько же, сколько стоит серверный ГПУ NVidia Tesla или FireStream. С другой стороны, эта же цена и будет "порогом вхождения". Отказавшись выпустить Larrabee в 2009 году в виде ГПУ, "Интел" отказалась от возможности использования "демократичности" процессора для создания сообщества пользователей. Конечно, скорее всего, продукт получился бы сырой, а его производительность как видеокарты уступала бы конкурентам. Но для создания сообщества разработчиков даже "сырой" продукт в сочетании с хорошим маркетингом был бы лучше, чем отсутствие продукта вообще.

Конечно, существуют архитектуры, ориентированные исключительно на северный сегмент, как PowerPC. Но во-первых, их доля среди суперкомпьютеров в списке Top500 невелика, и в последнее время только падает. Во-вторых, в случае PowerPC компания IBM, которая является производителем этих процессоров, поставляет готовые суперкомпьютеры — например, BlueGene. Вряд ли "Интел" будет предлагать готовые суперкомпьютеры на базе Knights Ferry.

Векторные команды

Как одно из достоинств Knights Ferry часто позиционируется поддержка архитектуры x86_64, из чего делается вывод, что он будет без значительных усилий исполнять приложения для этой архитектуры. Однако это верно только частично. Даже если для начала абстрагироваться от того, что Knights Ferry будет вспомогательным процессором, сидящим на PCI-Express-карточке со своей памятью (об этом будет ниже), он всё равно будет "не совсем" х86_64.

Если более конкретно, то Knights Ferry имеет векторные устройства шириной 16 элементов (c 32-разрядной точностью). И для эффективного исполнения программ на этом процессоре они должны эти векторные устройства использовать. И здесь есть две сложности.

Сложность первая связана со сложностью программирования. Векторные процессоры программировать всегда сложнее, чем скалярные. Пожалуй, вторым из секретов успеха ГПУ NVidia среди разработчиков является отказ от векторности и переход к скалярным потоковым процессорам. Точнее, фактически архитектура векторная — варпы, состоящие из 32-64 потоков, работали в режиме ОКМД. Но эта векторность скрыта от программиста (по крайней мере до тех пор, пока он не пытался реализовать на ГПУ семафор): он пишет код как для скалярного процессора. Расхождения при исполнении условных операторов или по адресам обращений в память полностью на уровне аппаратуры. Таким образом, писать первоначальный вариант программы становится значительно проще. И часто так оказывается, что даже этот вариант уже даёт достаточное ускорение по сравнению с ЦПУ, чтобы вкладывать в оптимизацию программ для ГПУ. Надо отметить, что процессоры Cell BE, а также ГПУ AMD пошли по пути векторных ядер — и это, на мой взгляд, тоже внесло вклад в их "популярность".

У Knights Ferry же имеется векторное устройство шириной 16 32-битных чисел. Можно, конечно, понадеяться на компилятор, но я бы этого делать не стал. Во-первых, у компиляторов, даже самых лучших, есть проблемы с векторизацией чего-то сложнее циклов вида a[i] = b[i] + c[i]. Разработки по векторизации ведутся, в том числе и в компании "Интел", но я сильно сомневаюсь, что к 2012 году в этом направлении произойдёт прорыв. Потом, помимо векторизации кода требуется изменение расположения данных, в том числе выравнивание выделенных в динамической памяти массивов — а это сложнее.

Основным способом получения векторных команд будет оставаться ручная векторизация. Здесь преимущество будет у приложений, в которых уже реализована векторизация для расширений SSE. С использованием шаблонов в C++ можно будет даже создавать общий код, который будет при компиляции параметризоваться размером вектора под конкретную архитектуру. Облегчит векторизацию и наличие команды одновременной выборки по вектору адресов. Но ручная векторизация по-прежнему будет оставаться трудоёмким процессом, требующим в ряде случаев по крайней мере частичного изменения архитектуры приложения. Ручную векторизацию могли бы облегчить полуавтоматические системы преобразования кода — однако это направление в последнее время не пользуется популярностью.

Второй сложностью векторизации является сложность создания эффективных приложений. Векторизация циклов наиболее эффективна, когда на соседних итерациях выполняются одни и те же команды. Если векторизируемый фрагмент линейный, т. е. не содержит условных операторов, то здесь дополнительной сложности нет. Но если есть расходящиеся условные операторы, или обращения в память по далеко отстоящим друг от друга адресам — эффективность векторных процессоров падает. Причём подобное падение эффективности имеет место даже в том случае, когда векторность процессора неявная, как в ГПУ NVidia. Для борьбы с этим существуют отдельные приёмы — замена условных переходов присваиванием по маске или переупорядочение данных. Но эффективность их использования очень сильно зависит от конкретной задачи. Здесь следует лишь сказать, что это общая проблема, характерная для всех современных процессоров, как традиционных, так и ускорителей.

Работа с памятью

Ещё одним вопросом является эффективность работы процессора Knights Ferry с собственным ОЗУ. Именно в эффективности работы с памятью заключается третья составляющая успеха ГПУ. Шина памяти ГПУ обеспечивает пропускную способность в 100-200 ГБ/с, а аппаратная многопоточность в сочетании с намного большим количестве потоков по сравнению с количеством ПП позволяет скрывать задержки. Помимо этого, ГПУ умеют исполнять операции записи асинхронно, а несколько последовательных операций чтения могут выполняться параллельно. В совокупности это приводит к тому, что даже на простейшей задаче сложения двух массивов автоматически достигается 80-90% пропускной способности без дополнительных затрат труда со стороны программиста.

Про работу с памятью в Knights Ferry сейчас информации сравнительно немного. Известно, что есть аппаратная многопоточность. Но 4 аппаратных потока на ядро — это мало по сравнению с ГПУ, где число потоков на ядро может достигать нескольких десятков. Во-вторых, ничего не известно о пропускной способности шины памяти и задержках чтения из памяти. В-третьих, про асинхронные операции информации тоже нет.

С другой стороны, существующая технология Quick Path Interconnect (QPI) позволяет выполнять обмены данными на скорости до 48 ГБ/с. Кроме того, на Knights Ferry планируется устанавливать память GDDR5, которая поддерживает более высокие частоты работы, и которая используется сейчас в высокопроизводительных ГПУ. В компании "Интел" наверняка знают о существовании этой проблемы, так что будут предприняты шаги для её решения.

Наконец, в Knights Ferry присутствует кэш 1-го и 2-го уровней. Эксперименты с архитектурой NVidia Fermi показывают, что наличие кэшей позволяют значительно улучшить производительность по сравнению с ГПУ предыдущего поколения. Эффект наличия кэшей является значительным даже несмотря на их небольшой размер.

Архитектура и поддержка x86

Поддержка x86_64 позиционируется как одно из преимуществ процессора Knights Ferry, однако и здесь имеется ряд проблем. Во-первых, и об этом было написано выше, нужно научиться использовать векторные команды.

Во-вторых, Knights Ferry является не ЦПУ, а ускорителем, подключаемым по технологии PCI-Express, и имеющим свою память. А значит, при его программировании встанут те же проблемы, что и при программировании любого такого ускорителя. Данные нужно будет синхронизировать между основной памятью и ОЗУ Knights Ferry. Программы на Knights Ferry нельзя будет запустить просто как процедуру на обычном процессоре — придётся использовать API для работы с ускорителем. Даже если переложить всё это на директивы компилятора, как в PGI Accelerator Fortran или CAPS HMPP, всё равно потребуется частичная переработка исходных кодов программ.

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

Наконец, качество генерации машинного кода для C или Fortran для аппаратных архитектур ГПУ NVidia уже достигло высокого уровня эффективности. Кроме того, система команд этих процессоров проще. Это также снижает эффект от поддержки архитектуры x86_64.

Более важным моментом, на наш взгляд, является не поддержка x86_64, а гибкость Knights Ferry по сравнению с уже существующими ГП. Он может быть эффективно использован для алгоритмов с параллелизмом по задачам (или рекурсивным параллелизмом) — на существующих ГПУ они не так эффективны. Кроме того, на него можно переносить целые программы и процессы ОС (а не только ядра), и использовать библиотеки ввода/вывода (системные вызовы, MPI, работа с фалами). Более того, можно организовать взаимодействие с ЦПУ без прерывания исполнения программы ускорителя — на современных ГПУ это возможно лишь в ограниченном объёме.

Итоги

Итак, мы рассмотрели возможные проблемы процессоров Knights Ferry. Ориентация исключительно на суперкомпьютерный сегмент снижает распространённость процессора, а использование векторной системы команд усложняет его программирование. Кроме того, программирование усложняется и за счёт реализации систем на основе Knights Ferry в форм-факторе ускорителя, а не самостоятельного процессора. С другой стороны, процессор имеет высокую пиковую производительность, поддерживает систему команд x86_64, и скорее всего, будет иметь хорошую подсистему работы с памятью. Кроме того, Knights Ferry представляется более гибким по сравнению с существующими ГПУ.

Есть ли у процессора Knights Ferry перспективы? Безусловно. Он может использоваться для решения тех же задач, что и ГПУ, и даже для более широкого круга задач. Лидерство "Интел" в технологиях производства микрочипов позволит выпускать Knights Ferry по более тонкому техпроцессу. В свою очередь, это приведёт к большей энергоэффективности продукта, что в настоящее время является ключевым фактором на пути создания высокопроизводительных систем.

Основной проблемой Knighs Ferry, на наш взгляд, является создание критической массы разработчиков и пользователей данного продукта. И ключевую роль здесь играет упрощение адаптации существующих приложений и создания новых. Кроме того, важной является поддержка стандартных технологий программирования. При этом сюда относятся как специфические технологии программирования ускорителей, как OpenCL, так и традиционные технологии программирования процессоров, такие как C, C++, Fortran и OpenMP.