Модель программирования для гетерогенных платформ на базе архитектуры Intel x86

Введение

Клиентские компьютерные платформы развиваются по направлению к гетерогенной архитектуре, которая содержит скалярные ядра и набор высокопроизводительных ядер, которые обеспечивают высокую пропускную способность. Например, платформы настольных и переносных компьютеров могут включать один (или более) центральный процессор (CPU), главным образом ориентированный на скалярные вычисления, а также графический процессор (GPU), предназначенный для ускорения высокопараллельных вычислений. Такие гетерогенные платформы могут быть использованы для значительного увеличения производительности высокопараллельных неграфических заданий в области обработки изображений, визуализации в медицине, сбора данных и др. Некоторые компании создали средства программирования для таких платформ, например, как CUDA, CTM и OpenCL.

Гетерогенные платформы имеют следующий ряд архитектурных особенностей.

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

– Скалярные и высокопроизводительные ядра могут иметь различные операционные системы (ОС). Например, процессор Larrabee компании Intel, предназначенный для выполнения сложных графических задач, может содержать собственное ядро ОС. Это означает, что схемы перемещения виртуальной памяти (преобразование виртуальных адресов в физические) могут быть различными у разных видов ядер. Одни и те же виртуальные адреса могут быть одновременно распределены по двум различным физическим адресам, один из которых расположен в памяти CPU, а другой — в памяти процессора Larrabee. Это также означает, что системная среда (загрузчики, компоновщики и др.) может быть различной в разных ядрах.

– Скалярные и высокопроизводительные ядра могут иметь различную структуру системы команд (ISA) и, следовательно, один и тот же код нельзя запускать на ядрах различных типов.

Модель программирования для гетерогенных платформ должна обеспечивать решение всех вопросов, связанных с указанными ограничениями. К сожалению, существующие модели программирования, такие как Compute Unified Device Architecture (CUDA) от Nvidia и Close To the Metal (CTM) от ATI учитывают только гетерогенность ISA путем введения языковых аннотаций для отметки кода, который должен выполняться на GPU, и не обращают внимание на другие особенности такой платформы. Например, CUDA не разрешает вопросы управления памятью между CPU и GPU. Эта архитектура предусматривает, что CPU и GPU имеют раздельные адресные пространства и программист должен использовать разные функции распределения памяти для CPU и GPU. Кроме того, программист должен самостоятельно преобразовывать в последовательную форму структуры данных, выбирать протокол совместного пользования и обеспечивать передачу данных между ядрами.

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

В отличие от существующих моделей программирования системы CPU-GPU, предложена модель с совместно используемой памяти, т.к. эта модель открывает совершенно новые возможности построения системы программирования, которая улучшает общую производительность платформы. Модель с совместно используемой памятью позволяет системе указателей и структур данных быть совершенно незаметно для пользователя разделенной между разными ядрами (например, между ядрами CPU и Larrabee) без необходимости какой-либо трансляции. Рассмотрим, например, игровую подсистему, которая включает физическую модель, искусственный интеллект и визуализацию. Модель с совместно используемой памятью позволяет запускать на скалярных ядрах (CPU) физическую модель, искусственный интеллект и логику игры, а визуализацию — на высокопроизводительных ядрах (Larrabee). При этом как скалярные ядра, так и высокопроизводительных ядра совместно используют граф сцены. Такая модель программного исполнения невозможна в существующих средах программирования, т.к. граф сцены необходимо было бы преобразовывать из параллельной в последовательную форму, и наоборот.

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

Разработанная программная среда была портирована на симулятор гетерогенной платформы на базе архитектуры Intel x86, который моделирует систему, состоящую из CPU и соединенного с ним дискретного устройства PCI-Express на базе высокопроизводительных ядер Larrabee. Такая платформа была использована по двум причинам. Во-первых, ядро Larrabee представляет собой современное решение для высокопроизводительного графического процессора. Во-вторых, такая платформа предполагает решение более сложной проблемы гетерогенности системного программного стека, а не просто проблемы гетерогенности ISA.

Архитектура Larrabee

Архитектура Larrabee — это многоядерная x86-совместимая архитектура вычислений с активным применением графики на базе упорядоченных ядер, работающих с расширенной версией набора команд x86, включая векторные команды с большим числом разрядов и некоторые специализированные скалярные команды. Каждое из ядер содержит 32-Кбайт кэш команд и 32-Кбайт кэш данных уровня L1. Каждое ядро имеет доступ к собственной подсистеме когерентного кэша уровня L2, что обеспечивает широкополосный доступа к кэшу L2. Объем кэша L2 составляет 256 Кбайт; межсоединения выполнены широкополосной, встроенной в кристалл кольцевой шиной. Записываемые ядром CPU данные хранятся в собственной подсистеме кэша L2, куда они могут поступать и от других подсистем. Каждый кольцевой канал данных имеет разрядность 512 бит в каждом направлении. Блоки постоянных функций и контроллеры памяти распределены по кольцу для того, чтобы минимизировать загрузку канала.

Каждое ядро имеет четыре аппаратных потока с отдельными наборами регистров для каждого потока. Выдача предварительно обработанных команд осуществляется поочередно между потоками, в т.ч. в случаях, когда компилятор не способен распределять время исполнения кода без потери быстродействия. Ядро использует сдвоенный декодер, а правила сопряжения для первичных и вторичных каналов команд являются детерминированными. Все команды могут выдаваться в первичный канал, а вторичный канал поддерживает подсистему набора скалярных x86-совместимых команд, в т.ч. загрузку, хранение, простые команды АЛУ, векторное хранение и др. Ядро поддерживает 64-бит расширения и полный набор x86-совместимых команд для процессора Intel Pentium. Архитектура Larrabee состоит из 16-разрядных блоков обработки векторов, которые выполняют целочисленные команды, а также команды с плавающей точкой одинарной и двойной точности. Векторные блоки поддерживают команды сборки/разборки (gather-scatter) и маскируемые команды, а также команды, содержащие до трех операндов-источников.

Модель памяти

Модель памяти для разработанной системы обеспечивает окно совместно используемых ядрами CPU и Larrabee адресов, например как в языке PGAS, но с дополнительными аннотациями принадлежности (ownership annotations). Любая структура данных, которая разделяется между ядрами CPU и Larrabee, должна быть распределена программистом в этом пространстве. Система обеспечивает специальную функцию malloc, которая распределяет данные в этом пространстве. Статические переменные могут быть аннотированы с помощью спецификатора типа, так что они распределяются в совместно используемом окне адресов. Однако, в отличие от языков PGAS, в совместно используемом окне не существует понятия родства (affinity). Причина состоит в том, что данные в совместно используемом пространстве должны мигрировать между кэшами CPU и Larrabee, т.к. они используются каждым процессором. Кроме того, способ задания указателей не меняется в совместно используемом пространстве и в частной области памяти.

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

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

Рис. 1. Модель памяти системы CPU-процессор Larrabee

По ряду причин в предлагаемой модели используется консистентность по выходу (release consistency) в совместно используемом адресном пространстве. Во-первых, системе необходимо запомнить только все записи между последовательными точками выхода (release points), а не последовательность индивидуальных записей. Это облегчает групповую пересылку в точках выхода (например, несколько страниц одновременно), что особенно важно в дискретной конфигурации, т.к. массив данных эффективнее передается через шину PCI-Express. Во-вторых, консистентность по выходу допускает обновление памяти совершенно локально до точки выхода, что также важно в дискретной конфигурации. Итак, модель консистентности по выходу хорошо подходит для структур программирования в платформах на базе CPU-GPU, поскольку в таких программах имеется естественный выход (natural release) и точки захвата (acquisition points). Наконец, предложенная модель памяти для C/C++ может быть легко отображена на совместно используемое пространство.

Модель совместно используемой памяти была дополнена правами принадлежности (ownership rights), чтобы обеспечить дополнительную оптимизацию когерентности. В пределах окна совместно используемых виртуальных адресов CPU или процессор Larrabee может определить в конкретный момент времени, что он обладает определенным блоком адресов. Если диапазон адресов в совместно используемом окне принадлежит CPU, то он знает, что процессор Larrabee не может получить доступ к этим адресам и, следовательно, ему не следует поддерживать связь с этими адресами с помощью процессора Larrabee. То же самое верно для адресов, принадлежащих процессору Larrabee. Если адрес, принадлежащий CPU, выбирается процессором Larrabee, адрес теряет свои права принадлежности (с симметричным поведением для тех адресов, которые принадлежат процессору Larrabee).

Права принадлежности позволяют реализовать модель общего использования адресного пространства. Например, CPU вначале выбирает некоторые данные (инициализирует структуру данных), а затем передает их процессору Larrabee (обрабатывая структуру данных параллельным методом), затем CPU анализирует результаты вычислений и т.д. Права принадлежности позволяют приложению информировать систему о сосредоточенности нагрузки во времени и оптимизировать реализацию когерентности. Заметим, что права принадлежности служат только для оптимизации системы, и она может их игнорировать.

Языковые конструкции

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

Первая конструкция — это спецификатор совместно используемого типа, подобный тому, который используется в UPC. Он определяет переменную, которая совместно используется CPU и процессором Larrabee. Спецификатор может также быть связан с типами указателей. Это подразумевает, что адресат указателя находится в совместно используемом пространстве.

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

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

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

Третья предложенная конструкция обозначает функции, которые выполняются на CPU, но могут быть вызваны с процессора Larrabee. Они обозначаются с помощью аттрибута wrapper. Эти функции используются двумя путями. Во-первых, многие программы связаны с предварительно скомпилированными библиотеками, которые могут выполняться на CPU. Функции в этих библиотеках обозначаются как вызовы wrapper, поэтому исполняются на CPU при вызове из кода Larrabee. Во-вторых, при портировании крупных программ из режима запуска только на CPU в режим запуска на CPU и процессоре Larrabee весьма полезно портировать программу постепенно, шаг за шагом. Атрибут wrapper позволяет программисту останавливать портирование в любой точке дерева вызовов с помощью обратного вызова в CPU. Когда функция Larrabee вызывает функцию wrapper, компилятор инициирует динамический интерфейс прикладного программирования (API) для дистанционного вызова с процессора Larrabee на CPU. Выполнение вызова с процессора Larrabee на CPU в явном виде позволяет компилятору проверить, имеют ли какие-либо аргументы указателя тип коллективного использования.

Более подробно особенности применения языковых конструкций освещены в [1].

Реализация модели программирования1

Компилятор генерирует два двоичных файла — один для исполнения на процессоре Larrabee, а другой для исполнения на CPU, т.к. две ОС могут иметь разные форматы исполняемых файлов. Двоичный файл для процессора Larrabee содержит код, который будет выполняться на процессоре Larrabee (аннотируемый атрибутом Larrabee), а двоичный файл для CPU содержит функции CPU, которые включают все функции без аннотаций и функции с аннотацией wrapper. Библиотека рабочих программ имеет компоненты для CPU и Larrabee, которые связаны с двоичными файлами приложений для CPU и Larrabee для того, чтобы создать соответствующие исполняемые модули. Когда двоичный файл для CPU начинает исполнение, он вызывает динамическую функцию, которая загружает исполняемый модуль Larrabee. Двоичные файлы как для CPU, так и Larrabee создают поток демона, который используется для коммуникаций.

Реализация разделения памяти между CPU и процессором Larrabee

Предложенная модель использует идеи некоторых схем программного распределения совместно используемой памяти, но также имеет несколько значительных отличий. В отличие от распределенной совместно используемой памяти (DSM), в данном варианте реализации модели памяти CPU и процессор Larrabee могут иметь различные таблицы переадресации страниц и различные программы трансляции из виртуальной в физическую память.

Эта проблема была решена путем использования апертуры PCI (части диапазона адресов памяти PCI, отведенной под пространство адресов графической памяти) новым способом. Во время инициализации часть пространства апертуры PCI отображается на пользовательское пространство приложения и реализуется с помощью очереди задачи, очереди сообщений и буферов копий объектов. Когда требуется, например, скопировать страницы из CPU в процессор Larrabee, рабочая среда делает это в буферы копий апертуры PCI и отмечает буферы виртуальным адресом и идентификатором процесса. Со стороны Larrabee поток демона копирует содержимое буферов в адресное пространство, используя метку виртуального адреса. Таким образом, копирование осуществляется с помощью двухэтапного процесса: CPU копирует из своего адресного пространства общий буфер (апертуру PCI), который может быть выбран как CPU, так и процессором Larrabee, а процессор Larrabee получает страницы из общего буфера в свое адресное пространство. Копирование из процессора Larrabee в CPU выполняется аналогично.

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

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

Реализация прав принадлежности совместно используемой памяти

Каждая динамическая область памяти имеет соответствующие метаданные, которые идентифицируют страницы, принадлежащие динамической области памяти. Предположим, процессор Larrabee получает права на динамическую область памяти, делая соответствующие страницы недоступными для CPU. Производится копирование из исходного положения любых страницы из динамической области памяти, которые были обновлены с того момента, когда процессор Larrabee последний раз выполняя операцию запроса данных. Страницы устанавливаются в режим «только для чтения», так чтобы следующая запись в Larrabee вызвала ошибку и система могла записать, какие страницы процессора Larrabee были обновлены. В соответствующем каталоге отмечается, что процессор Larrabee — это домашний узел для страниц динамической области памяти. При выполнении операции выхода (release) страницы делаются доступными вновь со стороны CPU, и обновляется номер версии каталога страницы. Присвоение прав принадлежности для CPU выполняется аналогично. Такая реализация обеспечивает, в конечном итоге, более эффективное копирование страниц.

Реализация удаленных вызовов

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

В предложенной системе удаленные вызовы были реализованы с помощью комбинированного компиляторного и динамического подхода. Используемые языковые правила гарантируют, что любая функция, включенная в удаленные вызовы процедур (функции с атрибутом Larrabee или wrapper), аннотируется пользователем. При компилировании таких функций вызов добавляется в интерфейс прикладного программирования (API), что обеспечивает динамическую регистрацию адреса. Компилятор создает функцию инициализации для каждого файла, который задействует все вызовы других регистраций. Когда двоичный код загружен, в каждом файле вызывается функция инициализации. Пространство совместно используемых адресов содержит таблицу переходов, которая динамически заполняется с помощью функций регистрации. Таблица содержит один слот (область памяти, занимаемой страницей) для каждой аннотируемой функции.

Порядок трансляции выглядит следующим образом.

– Когда функция Larrabee (CPU) вызывается внутри функции Larrabee (CPU), генерируемый код выполняет вызов в том виде, как он есть.

– Когда функция Larrabee вызывается внутри функции CPU, генерируемый компилятором код выполняет удаленный вызов к процессору Larrabee:

– генерируемый компилятором код ищет в таблице переходов название функции и получает ее адрес;

– генерируемый код помещает аргументы в буфер аргументов в совместно используемом пространстве и вызывает подпрограмму размещения на стороне Larrabee, передавая адрес функции и адрес буфера аргумента.

Аналогичный процесс выполняется для функции wrapper: если она вызывается в коде Larrabee, то удаленный вызов выполняется в CPU.

Для инициирования указателя функции схема трансляции работает следующим образом. Когда присваивается указатель функции с аннотацией Larrabee, генерируемый компилятором код ищет в таблице переходов имя функции и назначает ее указатель с полученным адресом. Хотя поиск можно оптимизировать при назначении указателя функции внутри кода Larrabee, аннотируемого Larrabee, такая оптимизация не применялась для того, чтобы использовать единую стратегию для всех указателей функций. Если указатель функции Larrabee был вызван внутри функции Larrabee, то генерируемый компилятором код будет выполнять вызов как он есть. Если указатель функции Larrabee был вызван внутри функции CPU, генерируемый компилятором код будет выполнять удаленный вызов на сторону Larrabee. Процесс аналогичен для указателя функции wrapper: если он вызывается в функции Larrabee, удаленный вызов выполняется на стороне CPU.

В результате CPU и процессор Larrabee осуществляют взаимодействие в процессе распределения памяти в совместно используемой области. Каждый процессор распределяет память с обеих сторон окна совместно используемых адресов. Когда процессор расходует половину пространства, оба процессора заново организуют разделы в доступном пространстве.

Экспериментальная оценка производительности системы

Для измерения производительности различных рабочих заданий в разработанной среде программирования был использован симулятор гетерогенной платформы. Она моделирует нестандартный CPU и Larrabee-систему. При моделировании CPU использовалась конфигурация памяти и архитектура, подобная процессору Intel Core 2 Duo. Система Larrabee была смоделирована как дискретное устройство PCI-Express с задержкой соединения и полосой пропускания в соответствии с требованиями стандарта PCIExpress2.0, а набор команд был смоделирован на процессоре Intel Pentium. Симулятором был запущен программный стек на двух процессорах. На CPU была запущена ОС Windows Vista, а на процессоре Larrabee — ядро облегченной ОС.

Для оценки производительности системы было использовано несколько известных параллельных неграфических задач. В состав этих тестовых заданий входили: финансовая задача оценки стоимости опционов по методу Блэка-Шоулза (Black Scholes); быстрое преобразование Фурье (БПФ) с использованием алгоритма radix-2; задача Equake, которая выполняет моделирование землетрясений, и Art, которая выполняет распознавание изображений.

На рисунке 2 показана доля совместно используемых данных в общем числе обращений к памяти для перечисленных выше задач. Подавляющее большинство обращений было к частным данным. Заметим, что данные «только для чтения», которые выбирались несколькими потоками, были приватизированы вручную. Эта ручная приватизация помогла в некоторых тестах, подобных Black Scholes. Не удивительно, что большинство обращений зафиксировано к частным данным, т.к. вычислительные потоки в задании приватизируют данные, которые они обрабатывают, чтобы улучшить их расположение. Модель совместно используемой памяти с частично виртуальными адресами позволила использовать такую схему доступа за счет уменьшения объема данных, которые должны быть когерентными.

Рис. 2. Доля совместно используемых данных в общем числе обращений к памяти

Задания были запущены на моделирующей системе с одним ядром CPU и различным числом ядер Larrabee — от 6 до 24. Вычисления в задачах были разделены между ядрами CPU и Larrabee; задачи, требующие большой вычислительной мощности, выполнялись на ядрах Larrabee. Например, весь процесс ценообразования опционов в Black Scholes и моделирование землетрясений в Equake выполнялся на Larrabee. Был отмечено улучшение производительности по сравнению с одним ядром CPU и Larrabee.

Как и ожидалось, производительность приложений была выше при использовании вызовов прав принадлежности, чем без них.

На рисунке 3 представлены данные общей производительности системы. «Идеальная» полоска на гистограмме соответствует когерентности кэша с аппаратной поддержкой между ядрами CPU и Larrabee. Другими словами, это наилучшая производительность, которую может обеспечить данная модель реализации совместно используемой памяти. Для Equake можно отметить, что «идеальная» и «дискретная» полоска почти идентичны, т.к. количество переданных данных весьма мало по сравнению с вычислениями.

Рис. 3. Сравнение общей производительности системы

Во всех случаях данная реализация системы совместно используемой памяти имеет низкие непроизводительные издержки и работает почти так же, как в идеальном варианте. Задание Black Scholes показывает наивысший уровень непроизводительных издержек, т.к. оно имеет самую низкую плотность вычислений, т.е. объем данных, переданных за единицу времени вычислений был наибольшим. При выполнении Black Scholes было передано около 13 Мбайт данных за 1 с вычислений, а для Equake — около 0,42 Мбайт. Следовательно, непроизводительные издержки когерентности памяти ничтожно малы в Equake. Разница между идеальным сценарием и предложенной системой совместно используемой памяти увеличивается с ростом числа ядер, в основном, из-за потерь на синхронизацию. В данной реализации потери на синхронизацию возрастают нелинейно с увеличением числа ядер.

Альтернативные решения

Предложенная система программирования отличается от таких систем как CUDA, OpenCL и CTM несколькими особенностями. В отличие от этих программных сред, была определена модель коммуникаций между CPU и процессором Larrabee; обеспечена прямая связь на уровне пользователя между CPU и процессором Larrabee и предложен более широкий набор функций C, таких как указатели функций. Реализация подобной модели памяти на современных GPU затруднительна из-за свойственных им ограничениям.

Другой гетерогенной платформой является процессор Cell. Несмотря на то, что его процессорный модуль (power processor unit — PPU) подобен CPU, взаимно усиливающие процессорные блоки (synergistic processing units — SPU) намного проще ядра Larrabee. Так, например, они не работают на ядре ОС. В отличие от пары SPU-PPU, пара «CPU — процессор Larrabee» связана гораздо более гибко, т.к. процессор Larrabee может быть использован как дискретный GPU с любым CPU, на котором можно запустить ОС. В отличие от предложенной модели, программирование процессора Cell включает использование явно заданного прямого доступа к памяти (ПДП) между PPU и SPU. Разработанная модель памяти подобна той, которая используется в языке Unified Parallel C (UPC). Однако UPC не поддерживает ISA или гетерогенность ОС. Языки высокого уровня PGAS (например, X10) не поддерживают механизм прав принадлежности, что является весьма важным для масштабируемых когерентных решений в случае дискретной реализации системы.

Предложенная система имеет сходства с программно-распределенной совместно используемой памятью (software-distributed shared memory — S-DSM), которая также использует виртуальную память. Многие из этих S-DSM-систем также используют консистентность по выходу и могут копировать страницы по требованию. Основным отличием от S-DSM-систем является уровень гетерогенности. В отличие от S-DSM-систем, разработанная система предназначена для компьютерной платформы, в которой процессоры имеют различные ISA и системную среду. В частности, необходима поддержка различных процессоров с разным алгоритмом преобразования виртуальных страниц в физические. S-DSM-системы предназначены для крупных кластеров, а системы на базе CPU и процессора Larrabee — для небольших кластеров. Архитектура CUBA предлагает аппаратную поддержку для ускорения связи между CPU и GPU. Однако модель программирования предполагает, что CPU и GPU имеют отдельные адресные пространства.

Заключение

Гетерогенные компьютерные платформы, содержащие скалярные CPU общего назначения и высокопроизводительные ядра (такие как GPU), все шире используются в клиентских компьютерных системах. Эти платформы можно использовать для ускорения высокопараллельных задач. Для таких платформ было предложено несколько моделей программирования, но ни одна из них не решала вопросы, связанные с разработкой модели памяти CPU-GPU. В статье описана новая модель программирования для гетерогенных систем на базе Intel x86, обладающая следующими особенностями.

– Модель совместно используемой памяти для всех ядер платформы.

– Универсальная модель программирования для различных конфигураций.

– Аннотации пользователя позволяют разграничить код, выполняемый на CPU и процессоре Larrabee.

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

Литература

1. Bratin Saha, Xiaocheng Zhou, Hu Chen, Ying Gao, Shoumeng Yan, Sai Luo. A Programing Model for Heterogeneous Intel x86 Platforms//Intel Technology Journal. Volume 13.
Issue 4. 2009.