Потоковая обработка

В информатике , обработка потоков (также известная как обработка потоков событий , обработка потоков данных или обработка распределенных потоков ) — это парадигма программирования которая рассматривает потоки или последовательности событий во времени как центральные объекты ввода и вывода вычислений . Потоковая обработка включает в себя программирование потоков данных , реактивное программирование и распределенную обработку данных . Системы потоковой обработки стремятся обеспечить параллельную обработку потоков данных и полагаются на алгоритмы потоковой передачи для эффективной реализации. Стек программного обеспечения для этих систем включает такие компоненты, как модели программирования и языки запросов для выражения вычислений; системы управления потоками для распределения и планирования ; и аппаратные компоненты для ускорения, включая модули с плавающей запятой , графические процессоры и программируемые пользователем вентильные матрицы .

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

В 1980-е годы обработка потоков изучалась в рамках программирования потоков данных . Примером может служить язык SISAL (потоки и итерации в одном языке присвоения).

Приложения

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

Потоковая обработка особенно подходит для приложений, которые обладают тремя характеристиками:

• Интенсивность вычислений — количество арифметических операций на единицу ввода-вывода или ссылку на глобальную память. Сегодня во многих приложениях обработки сигналов оно значительно превышает 50:1 и увеличивается с увеличением сложности алгоритма.
• Параллелизм данных существует в ядре, если одна и та же функция применяется ко всем записям входного потока и несколько записей могут обрабатываться одновременно, не дожидаясь результатов от предыдущих записей.
• Локальность данных — это особый тип временной локальности, распространенный в приложениях обработки сигналов и мультимедиа, где данные создаются один раз, считываются один или два раза позже в приложении и никогда не считываются снова. Промежуточные потоки, передаваемые между ядрами, а также промежуточные данные внутри функций ядра могут захватывать эту локальность напрямую, используя модель программирования обработки потоков.

Примеры записей в потоках включают в себя:

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

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

Примеры кода

В качестве иллюстрации следующие фрагменты кода демонстрируют обнаружение шаблонов в потоках событий. Первый представляет собой пример обработки потока данных с использованием непрерывного SQL- запроса (запрос, который выполняет постоянную обработку поступающих данных на основе временных меток и продолжительности окна). Этот фрагмент кода иллюстрирует СОЕДИНЕНИЕ двух потоков данных: одного для заказов на акции, а другого для результирующих сделок с акциями. Запрос выводит поток всех ордеров, соответствующих сделке, в течение одной секунды после размещения ордера. Выходной поток сортируется по временной метке, в данном случае по временной метке из потока Orders.

SELECT DataStream
   Orders.TimeStamp, Orders.orderId, Orders.ticker,
   Orders.amount, Trade.amount
FROM Orders
JOIN Trades OVER (RANGE INTERVAL '1' SECOND FOLLOWING)
ON Orders.orderId = Trades.orderId;

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

WHEN Person.Gender EQUALS "man" AND Person.Clothes EQUALS "tuxedo"
FOLLOWED-BY
  Person.Clothes EQUALS "gown" AND
  (Church_Bell OR Rice_Flying)
WITHIN 2 hours
ACTION Wedding

с предыдущими

Базовые компьютеры начинались с парадигмы последовательного выполнения. Традиционные процессоры основаны на SISD , что означает, что они концептуально выполняют только одну операцию за раз. По мере развития мировых вычислительных потребностей объем данных, которыми нужно управлять, очень быстро увеличивался. Было очевидно, что модель последовательного программирования не может справиться с возросшей потребностью в вычислительной мощности. Были потрачены различные усилия на поиск альтернативных способов выполнения огромных объемов вычислений, но единственным решением было использование некоторого уровня параллельного выполнения. Результатом этих усилий стала SIMD — парадигма программирования, которая позволяла применять одну инструкцию к множеству экземпляров (разных) данных. Большую часть времени SIMD использовался в среде SWAR . Используя более сложные структуры, можно также обеспечить параллелизм MIMD .

Хотя эти две парадигмы были эффективны, реальные реализации имели ограничения — от проблем с выравниванием памяти до проблем синхронизации и ограниченного параллелизма. Лишь немногие процессоры SIMD сохранились как автономные компоненты; большинство из них были встроены в стандартные процессоры.

Рассмотрим простую программу, складывающую два массива, содержащие 100 4-компонентных векторов (т.е. всего 400 чисел).

Традиционная

for (int i = 0; i < 400; i++)
    result[i] = source0[i] + source1[i];

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

SIMD, упакованные регистры (SWAR

for (int el = 0; el < 100; el++) // for each vector
    vector_sum(result[el], source0[el], source1[el]);

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

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

Однако произошло следующее: упакованный регистр SIMD содержит определенный объем данных, поэтому добиться большего параллелизма невозможно. Ускорение несколько ограничено тем, что мы сделали предположение о выполнении четырех параллельных операций (обратите внимание, что это характерно как для AltiVec , так и для SSE ).

Парадигма параллельного потока (SIMD/MIMD)

// This is a fictional language for demonstration purposes.
elements = array streamElement([number, number])[100]
kernel = instance streamKernel("@arg0[@iter]")
result = kernel.invoke(elements)

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

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

Хотя потоковая обработка является ветвью обработки SIMD/MIMD, их не следует путать. Хотя реализации SIMD часто могут работать «потоковым» образом, их производительность несопоставима: модель предполагает совершенно другой шаблон использования, который сам по себе обеспечивает гораздо большую производительность.

Было отмечено, что при применении к универсальным процессорам, таким как стандартный ЦП, можно достичь ускорения только в 1,5 раза. Напротив, одноранговые потоковые процессоры легко достигают десятикратного увеличения производительности, главным образом благодаря более эффективному доступу к памяти и более высокому уровню параллельной обработки.

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

Исследования

Проекты потоковой обработки Стэнфордского университета включали Стэнфордский проект программируемого затенения в реальном времени, начатый в 1999 году. Прототип под названием Imagine был разработан в 2002 году. Проект под названием Merrimac просуществовал примерно до 2004 года. AT&T также исследовала процессоры с улучшенной потоковой передачей, поскольку графические процессоры быстро развивались как по скорости, так и по функциональности. ^[1] С тех пор были разработаны десятки языков потоковой обработки, а также специализированное оборудование.

Примечания к модели программирования

Самая неотложная проблема в области параллельной обработки заключается не столько в типе используемой аппаратной архитектуры, сколько в том, насколько легко будет запрограммировать рассматриваемую систему в реальной среде с приемлемой производительностью. Такие машины, как Imagine, используют простую однопоточную модель с автоматическими зависимостями, распределением памяти и DMA планированием . Это само по себе является результатом исследований Массачусетского технологического института и Стэнфорда по поиску оптимального распределения задач между программистом, инструментами и оборудованием. Программисты превосходят инструменты в сопоставлении алгоритмов с параллельным оборудованием, а инструменты превосходят программистов в определении наиболее разумных схем распределения памяти и т. д. Особую озабоченность вызывают конструкции MIMD, такие как Cell , для которых программисту приходится иметь дело с разделением приложений по нескольким ядрам и иметь дело с синхронизация процессов и балансировка нагрузки.

Недостатком программирования SIMD была проблема массивов структур (AoS) и структур массивов (SoA) . Программисты часто создают в памяти представления объектов, например расположение частицы в трехмерном пространстве, цвет шара и его размер, как показано ниже:

 // A particle in a three-dimensional space.
struct particle_t {
    float x, y, z;          // not even an array!
    unsigned byte color[3]; // 8 bit per channel, say we care about RGB only
    float size;
    // ... and many other attributes may follow...
};

Когда в памяти существует несколько таких структур, они размещаются встык, образуя массивы в топологии массива структур (AoS). Это означает, что если какой-либо алгоритм будет применен к местоположению каждой частицы по очереди, он должен будет пропустить ячейки памяти, содержащие другие атрибуты. Если эти атрибуты не нужны, это приводит к расточительному использованию кэша ЦП. Кроме того, инструкция SIMD обычно ожидает, что данные, с которыми она будет работать, будут непрерывными в памяти; элементы также могут нуждаться в выравнивании . Перемещая область памяти данных из структуры, данные можно лучше организовать для эффективного доступа в потоке и для выполнения инструкций SIMD. Структура массивов (SoA), как показано ниже, позволяет это сделать.

struct particle_t {
    float *x, *y, *z;
    unsigned byte *colorRed, *colorBlue, *colorGreen;
    float *size;
};

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

Для потоковых процессоров приветствуется использование структур. С точки зрения приложения все атрибуты могут быть определены с некоторой гибкостью. Если взять за основу графические процессоры, то имеется набор атрибутов (не менее 16). Для каждого атрибута приложение может указать количество компонентов и формат компонентов (но на данный момент поддерживаются только примитивные типы данных). Различные атрибуты затем прикрепляются к блоку памяти, возможно, определяя шаг между «последовательными» элементами одних и тех же атрибутов, что эффективно позволяет чередовать данные. Когда графический процессор начинает обработку потока, он собирает все различные атрибуты в один набор параметров (обычно это выглядит как структура или «магическая глобальная переменная»), выполняет операции и распределяет результаты в некоторую область памяти для дальнейшего использования. обработка (или извлечение).

Более современные платформы потоковой обработки предоставляют интерфейс типа FIFO для структурирования данных в виде буквального потока. Эта абстракция предоставляет средства для неявного указания зависимостей данных, позволяя среде выполнения/аппаратному обеспечению в полной мере использовать эти преимущества. знания для эффективных вычислений. Один из самых простых и наиболее эффективный современные методы потоковой обработки для C++, — это RaftLib , который позволяет связывать независимые вычислительные ядра вместе в виде графа потока данных с помощью потоковых операторов C++. В качестве примера:

#include <raft>
#include <raftio>
#include <cstdlib>
#include <string>

class hi : public raft::kernel
{
public:
    hi() : raft::kernel()
    {
       output.addPort<std::string>("0"); 
    }

    virtual raft::kstatus run()
    {
        output["0"].push(std::string("Hello World\n"));
        return raft::stop; 
    }
};

int main(int argc, char **argv)
{
    /** instantiate print kernel **/
    raft::print< std::string > p;
    /** instantiate hello world kernel **/
    hi hello;
    /** make a map object **/
    raft::map m;
    /** add kernels to map, both hello and p are executed concurrently **/
    m += hello >> p;
    /** execute the map **/
    m.exe();
    return EXIT_SUCCESS;
}

Модели вычислений для потоковой обработки

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

Общая архитектура процессора

Исторически процессоры начали реализовывать различные уровни оптимизации доступа к памяти из-за постоянно растущей производительности по сравнению с относительно медленно растущей пропускной способностью внешней памяти. По мере того, как этот разрыв увеличивался, большие площади кристалла были отведены для сокрытия задержек памяти. Поскольку получение информации и кодов операций в эти несколько ALU обходится дорого, под реальные математические машины выделяется очень небольшая площадь кристалла (по грубой оценке, считайте, что она составляет менее 10%).

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

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

Потоковый процессор обычно оснащен быстрой и эффективной собственной шиной памяти (в настоящее время широко распространены перекрестные переключатели, раньше использовались несколько шин). Точное количество полос памяти зависит от рыночного диапазона. На момент написания этой статьи все еще существуют 64-битные соединения (начального уровня). В большинстве моделей среднего класса используется быстрая 128-битная перекрестная матрица переключателей (4 или 2 сегмента), а в моделях высокого класса используются огромные объемы памяти (фактически до 512 МБ) с немного более медленной перекрестной матрицей шириной 256 бит. Напротив, стандартные процессоры от Intel Pentium до некоторых Athlon 64 имеют только одну шину данных шириной 64 бита.

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

Из-за SIMD-природы исполнительных блоков потокового процессора (кластеров ALU) ожидается, что операции чтения/записи будут выполняться массово, поэтому память оптимизируется для обеспечения высокой пропускной способности, а не низкой задержки (в этом отличие от Rambus и DDR SDRAM , поскольку пример). Это также обеспечивает эффективное согласование шины памяти.

Большая часть (90%) работы потокового процессора выполняется на кристалле, поэтому в памяти требуется хранить только 1% глобальных данных. Здесь полезно знать временные параметры ядра и зависимости.

Внутри потокового процессора имеется несколько умных схем связи и управления, но что интересно, так это файл регистрации потока (SRF). Концептуально это большой кеш, в котором хранятся потоковые данные для массовой передачи во внешнюю память. Являясь программно-управляемой структурой, напоминающей кэш, для различных ALU , SRF совместно используется всеми различными кластерами ALU. Ключевая концепция и новшество, реализованное с помощью чипа Imagine из Стэнфорда, заключается в том, что компилятор способен автоматизировать и распределять память оптимальным способом, полностью прозрачным для программиста. Зависимости между функциями ядра и данными известны через модель программирования, которая позволяет компилятору выполнять анализ потока и оптимально упаковывать SRF. Обычно управление кешем и DMA может занимать большую часть расписания проекта, что полностью автоматизирует потоковый процессор (или, по крайней мере, Imagine). Тесты, проведенные в Стэнфорде, показали, что компилятор справился с планированием памяти не хуже, а то и лучше, чем если бы вы настроили его вручную с большими усилиями.

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

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

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

Проблемы с аппаратным обеспечением

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

Конвейерная обработка — очень распространенная и часто используемая практика в потоковых процессорах, при этом графические процессоры имеют конвейеры, превышающие 200 этапов. Стоимость переключения настроек зависит от изменяемой настройки, но теперь считается, что она всегда дорогая. Чтобы избежать этих проблем на различных уровнях конвейера, было использовано множество методов, таких как «сверхшейдеры» и «атласы текстур». Эти методы ориентированы на игры из-за особенностей графических процессоров, но эти концепции интересны и для общей потоковой обработки.

Примеры

• Blitter — в Commodore Amiga это ранний (около 1985 года) графический процессор, способный объединять три исходных потока из 16 векторов компонентных битов 256 способами для создания выходного потока, состоящего из 16 векторов компонентных битов. Общая пропускная способность входного потока составляет до 42 миллионов бит в секунду. Пропускная способность выходного потока составляет до 28 миллионов бит в секунду.
• Представлять себе, возглавляемая профессором Уильямом Дэлли из Стэнфордского университета , представляет собой гибкую архитектуру, призванную быть одновременно быстрой и энергоэффективной. Проект, первоначально задуманный в 1996 году, включал архитектуру, программные инструменты, реализацию СБИС и плату разработки, финансировался DARPA , Intel и Texas Instruments .
• Еще один Стэнфордский проект, под названием Мерримак, направлена ​​на разработку потокового суперкомпьютера. Merrimac намерен использовать потоковую архитектуру и развитые сети межсоединений, чтобы обеспечить большую производительность на единицу стоимости, чем научные компьютеры на базе кластеров, созданные на основе той же технологии.
• Семейство Storm-1 от Stream Processors, Inc , коммерческого дочернего проекта Стэнфордского проекта Imagine , было анонсировано во время презентации функций на ISSCC 2007. Семейство включает четыре члена с диапазоном от 30 GOPS до 220 16-битных GOPS (миллиарды операций). в секунду), все они производятся в TSMC по 130-нанометровому процессу. Устройства ориентированы на верхний сегмент рынка цифровой обработки сигналов , включая видеоконференции , многофункциональные принтеры и для цифрового видеонаблюдения . оборудование
• Графические процессоры — это широко распространенные потоковые процессоры потребительского уровня. ^[2] разработан в основном AMD и Nvidia . Следует отметить различные поколения с точки зрения обработки потока:
  • До R2xx/NV2x: нет явной поддержки потоковой обработки. Операции ядра были скрыты в API и обеспечивали слишком мало гибкости для общего использования.
  • R2xx/NV2x: потоковые операции ядра стали явно контролироваться программистом, но только для обработки вершин (фрагменты все еще использовали старые парадигмы). Отсутствие поддержки ветвления серьезно ограничивало гибкость, но некоторые типы алгоритмов можно было запускать (в частности, моделирование жидкости с низкой точностью).
  • R3xx/NV4x: гибкая поддержка ветвления, хотя все еще существуют некоторые ограничения на количество выполняемых операций и строгую глубину рекурсии, а также манипулирование массивами.
  • R8xx: поддерживает буферы добавления/потребления и атомарные операции. Это поколение представляет собой современное состояние.
• AMD FireStream для линейки продуктов, ориентированных на HPC Торговая марка
• Nvidia Tesla для линейки продуктов, ориентированных на HPC Торговая марка
• Процессор Cell от STI , альянса Sony Computer Entertainment , Toshiba Corporation и IBM , представляет собой аппаратную архитектуру, которая может функционировать как потоковый процессор при соответствующей программной поддержке. Он состоит из управляющего процессора, PPE (Power Processing Element, IBM PowerPC ) и набора сопроцессоров SIMD, называемых SPE (синергетические элементы обработки), каждый из которых имеет независимые программные счетчики и память команд, по сути, MIMD- машину. В модели собственного программирования весь DMA и планирование программ оставляются на усмотрение программиста. Аппаратное обеспечение обеспечивает быструю кольцевую шину между процессорами для локальной связи. Поскольку локальная память для инструкций и данных ограничена, единственные программы, которые могут эффективно использовать эту архитектуру, либо требуют минимального объема памяти , либо придерживаются модели потокового программирования. При наличии подходящего алгоритма производительность Cell может конкурировать с производительностью чисто потоковых процессоров, однако это почти всегда требует полной переработки алгоритмов и программного обеспечения.

Библиотеки и языки потокового программирования

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

Некоммерческие примеры языков потокового программирования включают:

• Ateji PX Free Edition обеспечивает простое выражение потокового программирования, модели актера и алгоритма MapReduce на JVM.
• Auto-Pipe, из Лаборатории суперкомпьютеров на основе потоков Вашингтонского университета в Сент-Луисе , среда разработки приложений для потоковых приложений, позволяющая создавать приложения для гетерогенных систем (CPU, GPGPU , FPGA). Приложения могут разрабатываться на любой комбинации C, C++ и Java для ЦП. Verilog или VHDL для FPGA. Cuda в настоящее время используется для графических процессоров Nvidia. Auto-Pipe также обеспечивает координацию TCP-соединений между несколькими компьютерами.
• Модель программирования ACOTES: язык Политехнического университета Каталонии на основе OpenMP.
• BeepBeep, простая и легкая библиотека обработки потоков событий на основе Java из Лаборатории формальных компьютерных наук Университета Квебека в Шикутими.
• Язык Брука из Стэнфорда
• CAL Actor Language : язык программирования высокого уровня для написания актеров (потоков данных), которые представляют собой операторы с отслеживанием состояния, преобразующие входные потоки объектов данных (токенов) в выходные потоки.
• Cal2Many — платформа генерации кода от Хальмстадского университета, Швеция. Он принимает код CAL в качестве входных данных и генерирует различные целевые языки, включая последовательный C, Chisel, параллельный C, ориентированный на архитектуру Epiphany, ajava и astruct, ориентированный на архитектуру Ambric, и т. д.
• Язык DUP от Мюнхенского технического университета и Денверского университета.
• HSTREAM: расширение языка на основе директив для гетерогенных потоковых вычислений.
• RaftLib — библиотека шаблонов потоковой обработки C++ с открытым исходным кодом, созданная в Лаборатории суперкомпьютеров на основе потоков Вашингтонского университета в Сент-Луисе.
• SPAr — предметно-ориентированный язык C++ для выражения потокового параллелизма, разработанный Группой моделирования приложений (GMAP) Папского католического университета Риу-Гранди-ду-Сул.
• Ш Библиотека Университета Ватерлоо
• Shallows, проект с открытым исходным кодом
• Язык координации S-Net от Университета Хартфордшира , обеспечивающий разделение координации и алгоритмического программирования.
• StreamIt от Массачусетского технологического института
• Сиддхи из WSO2
• Функциональная потоковая обработка WaveScript, также от MIT.
• Функциональное реактивное программирование можно рассматривать как потоковую обработку в широком смысле.

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

• AccelerEyes 'Jacket, коммерциализация движка графического процессора для MATLAB.
• Расширение Ateji PX Java, позволяющее простое выражение потокового программирования, модели актеров и алгоритма MapReduce.
• Embiot, легкий встроенный агент потоковой аналитики от Telchemy.
• Floodgate, потоковый процессор, поставляемый с игровым движком Gamebryo для PlayStation 3, Xbox360, Wii и ПК.
• OpenHMPP , «директивный» взгляд на многоядерное программирование.
• ПикСтрим, ответвление проекта Brook (приобретено Google в июне 2007 г.)
• IBM Spade — декларативный механизм приложений потоковой обработки (Б. Гедик и др. SPADE: механизм декларативной потоковой обработки системы S. ACM SIGMOD 2008.)
• RapidMind , коммерциализация Sh (приобретена Intel в августе 2009 г.)
• TStreams, Кембриджская исследовательская лаборатория Hewlett-Packard

Языки, специфичные для конкретного поставщика, включают:

• Brook+ (аппаратно-оптимизированная реализация Brook от AMD ) от AMD / ATI
• CUDA (унифицированная архитектура вычислительных устройств) от Nvidia
• Intel Ct -C для вычислений с высокой пропускной способностью
• StreamC от Stream Processors, Inc , коммерциализация работы Imagine в Стэнфорде.

Обработка событий

• Apama — комбинированный механизм обработки сложных событий и потоков от Software AG.
• Валлару
• Потоковый процессор WSO2 от WSO2
• Апач НиФи

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

• Апач Кафка
• Апач Шторм
• Апач Апекс
• Апач Спарк

Непрерывная обработка потока операторов

• Апач Флинк
• Walmartlabs Mupd8
• Eclipse Streamsheets — электронная таблица для потоковой обработки

Сервисы потоковой обработки:

• Веб-сервисы Amazon — Kinesis
• Google Cloud – поток данных
• Microsoft Azure — потоковая аналитика
• Datastreams — платформа аналитики потоковой передачи данных
• IBM потоки
  • Потоковая аналитика IBM
• Eventador SQLStreamBuilder

См. также

• Интеллектуальный анализ потока данных
• Система управления потоками данных
• Уменьшение размеров
• Программирование на основе потока
• Аппаратное ускорение
• Молекулярное моделирование на GPU
• Параллельные вычисления
• Разделенное глобальное адресное пространство
• Вычисления в реальном времени
• Протокол потоковой передачи в реальном времени
• СМЫСЛ
• Алгоритм потоковой передачи
• Векторный процессор