Архитектура потока данных

редактировать

Архитектура потока данных - это архитектура компьютера, который прямо контрастирует с традиционной архитектурой фон Неймана или архитектурой потока управления. Архитектуры потока данных не имеют программного счетчика (концептуально): выполнимость и выполнение инструкций определяется исключительно на основе доступности входных аргументов инструкций, так что порядок выполнения инструкций непредсказуем, т. Е. поведение недетерминировано.

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

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

Между тем, существует конфликт терминологии, поскольку термин поток данных используется для подобласти параллельного программирования: для программирования потока данных.

Содержание
  • 1 История
  • 2 Темы архитектуры потока данных
    • 2.1 Статические и динамические машины потока данных
    • 2.2 Компилятор
    • 2.3 Программы
    • 2.4 Инструкции
  • 3 См. Также
  • 4 Ссылки
История

Аппаратные архитектуры для потока данных были основной темой в исследованиях компьютерной архитектуры в 1970-х и начале 1980-е гг. Джек Деннис из MIT был пионером в области архитектур статических потоков данных, в то время как Manchester Dataflow Machine и архитектура токенов MIT были главными проектами в области динамических потоков данных.

Однако исследование так и не помогло преодолеть проблемы, связанные с:

  • Эффективной трансляцией токенов данных в массивно-параллельной системе.
  • Эффективной отправкой токенов инструкций в массивно-параллельной системе.
  • Создание модулей CAM достаточно большого размера, чтобы вместить все зависимости реальной программы.

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

Тем не менее, выполнение вне очереди (OOE) стало доминирующей вычислительной парадигмой с 1990-х годов. Это форма ограниченного потока данных. Эта парадигма ввела идею окна выполнения. Окно выполнения следует последовательному порядку архитектуры фон Неймана, однако внутри окна инструкции могут выполняться в порядке зависимости данных. Это выполняется в процессорах, которые динамически маркируют зависимости данных кода в окне выполнения. Логическая сложность динамического отслеживания зависимостей данных ограничивает OOE ЦП небольшим количеством исполнительных блоков (2-6) и ограничивает размеры окна выполнения до 32 до 200 инструкций, что намного меньше, чем предусмотрено для машин с полным потоком данных.

Темы архитектуры потока данных

Машины статического и динамического потока данных

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

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

Компилятор

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

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

Программы

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

. Это называется активацией или увольнение инструкция. Как только инструкция завершается исполнительным блоком, его выходные данные отправляются (с его тегом) в CAM. Любые инструкции, которые зависят от этого конкретного элемента данных (идентифицированного его значением тега), затем помечаются как готовые к выполнению. Таким образом, последующие инструкции выполняются в правильном порядке, избегая состояний гонки. Этот порядок может отличаться от последовательного порядка, предусмотренного человеком-программистом, от запрограммированного порядка.

Инструкции

Инструкция вместе с ее обязательными операндами данных передается в исполнительный блок в виде пакета, также называемого токеном инструкции. Точно так же выходные данные передаются обратно в CAM как токен данных. Пакетирование инструкций и результатов позволяет параллельно выполнять готовые инструкции в большом масштабе.

Сети потока данных доставляют токены инструкций исполнительным блокам и возвращают токены данных в CAM. В отличие от традиционной архитектуры фон Неймана, токены данных не хранятся в памяти постоянно, а представляют собой временные сообщения, которые существуют только при передаче в хранилище команд.

См. Также
Ссылки
Последняя правка сделана 2021-05-17 14:12:25
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте