Динамические потоковые вычислительные системы

Слайд 2
Напоминаю, что в статической dataflow-архитектуре набор и количество операций
фиксировано – каждый вычислительный узел представлен в единственном экземпляре,
число узлов и число токенов, циркулирующих в системе, заранее известно. В качестве
реализации можно привести MIT Static Dataflow Machine, которая состояла из множества
обрабатывающих элементов, связанных коммуникационной сетью. В качестве устройства
сопоставления использовалась память взаимодействий (activity store). В ней хранились
пары токенов вместе с адресом узла назначения, флагами готовности и кодом операции.
Любой вычислительный узел в этой архитектуре имел только два входа и состоял из
одного оператора. При обнаружении готовности обоих операндов устройство
выборки(fetch unit) считывало код операции, и данные отправлялись на обработку в
исполнительное устройство (operation unit).
Слайд 3
Но статическая архитектура имеет довольно много ограничений: например, непонятно,
как быть в случае с рекурсией, когда процедура должна вызвать себя же, но с другими
параметрами. В динамической dataflow-архитектуре каждый узел может иметь
множество экземпляров в памяти. Для того, чтобы различать разные экземпляры, в
структуру токена вводится дополнительное поле – контекст исполнения. Тогда
сопоставление токенов можно вести не только по меткам узлов, но и по значению
контекста. По сравнению со статической архитектурой появляется много новых
возможностей:
Рекурсия. Узел может направлять данные в свою копию, которая будет отличаться
контекстом (но при этом иметь ту же метку).
Поддержка процедур. Процедурой в рамках данной модели вычислений будет
последовательность узлов, связанных между собой и имеющая входы и выходы. Можно
одновременно вызывать несколько экземпляров одной и той же процедуры, которые
будут отличаться контекстом.
Распараллеливание циклов. Если между итерациями цикла нет зависимости по данным,
можно обрабатывать сразу все итерации одновременно. Номер итерации будет
содержаться в поле контекста.
Слайд 4
Рассмотрим, как может выглядеть контекст в случае циклов на двух примерах –
вычисление последовательности Фиббоначи и сложения матриц. Последовательность
фиббоначи из MAX_I элементов вычисляется стандартным способом – первые 2 элемента
равны единице, затем каждый следующий элемент вычисляется как сумма 2-х
предыдущих.
Слайд 5
На рисунке показан вычислительный граф такой программы. Этот граф состоит из MAX_I
одинаковых узлов. Единственная разница между ними – контекст, т.е. номер итерации.
Тогда для одного узла логика работы выглядит так – получить значение счетчика из
контекста токена, сложить 2 числа из полей данных токена. Получившиеся значение
отправляется с меткой хост и конекстом I – это аналог запись в массив по индексу. Также
для вычисления следующих элементов последовательности нужно отправить 2 токена на
2 следующих узла с конекстом I+1 и I+2
Слайд 6
Второй пример – сложение матриц. Здесь используется M*N (ширина на высоту)
одинаковых узлов каждый узел выполняет сложение двух элементов матрицы и
отправляет результат. Т.к. отсутствует зависимость по данным, то все операции
теоретически можно выполнять паралельно, практически, степень паралелизма зависит
от числа исполнительных устройств. Для старта вычислений нужно отправить N*M
токенов с значениями исходных элементов матриц.
Dataflow-системы очень эффективны для обработки разреженных данных, так как
фактически пересылаются и обрабатываются только значимые элементы.
Слайд 7
«Чистые» потоковые архитектуры, подобные описанным MIT Static Dataflow Machine и
Manchester Dataflow Machine, к сожалению, имели много слабых мест:
Dataflow-машины давали огромные возможности для параллелизма выполнения.
Обратной стороной этого преимущества было то, что на последовательных участках
вычислительного графа они показывали резкое падение производительности.
Загрузка исполнительных устройств была далека от максимально возможной. Большая
часть машинного времени тратилась на поиск соответствия операндов, выборку
инструкций, а исполнительное устройство все это время простаивало, выполняя лишь по
одной инструкции на каждую пару токенов.
Трудным было конструирование устройств сопоставления. Ассоциативная память
сложнее, дороже, медленнее, занимает больше места и потребляет больше энергии, по
сравнению с обычной оперативной памятью такого же объема.
Сам принцип управления потоком данных не позволял организовать эффективный
конвейер. Почти все устройства работали асинхронно, требовались буферы и очереди в
линиях связи.
По сравнению с классической многопроцессорной архитектурой, в dataflow-машинах
значительно выше была нагрузка на коммутационную сеть. Ведь фактически, каждая
операция требовала пересылки двух токенов.
Слайд 8
Поэтому для решения проблем чистых dataflow-архитектур появилось несколько
модификаций.
Threaded dataflow. Суть данного подхода состоит в том, чтобы последовательные участки
вычислительного графа, которые невозможно распараллелить,
заменить тредами (threads) — наборами последовательно выполняемых инструкций.
Сразу исчезают «лишние» промежуточные токены, и растет загрузка исполнительных
устройств. Принципы threaded dataflow были воплощены «в железе» в процессоре
Epsilon [21] в 1989 году.
Крупнозернистая архитектура потока данных
Дальнейшим развитием threaded dataflow стали так
назыаемые крупнозернистые потоковые архитектуры (large-grain dataflow). Когда стало
ясно, что параллелизм «чистого» dataflow во многих случаях избыточен, возникло
решение строить потоковый граф не из отдельных операторов, а из блоков. Таким
образом, в крупнозернистой архитектуре каждый узел представляет собой не одну
инструкцию, а классическую последовательную программу. Взаимодействие между
узлами по-прежнему осуществляется по принципу потока данных. Одним из преимуществ
такого подхода стала возможность использовать в качестве исполнительных устройств
обычные фон-неймановские процессоры. Следует отметить, что несмотря на название
«крупнозернистая», блоки, на которые разбивается задача, все равно намного мельче,
чем, скажем, в кластерных системах. Типичный размер блока составляет 10-100
инструкций и 16-1К байт данных.
Векторная dataflow-архитектура
В векторных потоковых системах токен содержит не одно значение, а сразу множество.
Соответственно, и операции выполняются не над парами операндов, а над парами
векторов. В качестве примера такой системы можно привести машину SIGMA-1
(1988) [22]. Иногда векторный режим поддерживается только частью исполнительных
устройств системы. Часто также применяются гибридные архитектуры, объединяющие
сразу несколько подходов, например крупнозернистая архитектура с возможностью
выполнения векторных операций.
Реконфигурируемые системы
Развитие технологий ПЛИС сделало возможным принципиально новый подход к
архитектуре dataflow. Что, если собрать машину, ориентированную на решение одной
конкретной задачи? Если реализовать непосредственно на схемотехническом уровне
нужный вычислительный граф, можно добиться потрясающих результатов. Вместо
устройств сложных и медленных сопоставления можно использовать безусловное
перенаправление данных от одного функционального модуля к другому. Сами
исполнительные устройства тоже можно «заточить» под нужную задачу: выбрать тип
арифметики, разрядность, нужный набор поддерживаемых операций.
Разумеется, подобная машина будет очень узкоспециализированной, но ведь
достоинство ПЛИС как раз в возможности неоднократного перепрограммирования. Таким
образом, под каждую отдельную задачу собирается нужная архитектура. Некоторые
системы позволяют даже осуществлять перенастройку прямо в процессе работы.
Реконфигурируемые системы на базе FPGA-микросхем в настоящее время выпускаются
серийно в самых разных форматах — от блока «ускорителя» для ПК до системы
производительностью порядка нескольких Тфлопс [31].
Из недостатков реконфигурируемых архитектур можно выделить следующие:
Принципиальная однозадачность. Для запуска новой задачи требуется остановка системы
и перепрограммирование ПЛИС, входящих в ее состав.