Jump to content

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

(Перенаправлено из Stream Programming )

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

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

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

Приложения

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

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

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

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

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

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

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

Примеры кода

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

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

SELECT DataStream   Orders.TimeStamp, Orders.orderId, Orders.ticker,   Orders.amount, Trade.amountFROM OrdersJOIN 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 hoursACTION 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. [3] [4] Устранение сложных шаблонов данных делает большую часть этой дополнительной мощности доступной.

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

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

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

Исследовать

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

Проекты потоковой обработки Стэнфордского университета включали Стэнфордский проект программируемого затенения в реальном времени, начатый в 1999 году. [7] Прототип под названием Imagine был разработан в 2002 году. [8] Проект под названием Merrimac просуществовал примерно до 2004 года. [9] 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 миллионов бит в секунду.
  • Представлять себе, [10] возглавляемая профессором Уильямом Дэлли из Стэнфордского университета , представляет собой гибкую архитектуру, призванную быть одновременно быстрой и энергоэффективной. Проект, первоначально задуманный в 1996 году, включал архитектуру, программные инструменты, реализацию СБИС и плату разработки, финансировался DARPA , Intel и Texas Instruments .
  • Еще один Стэнфордский проект, под названием Мерримак, [11] направлена ​​на разработку потокового суперкомпьютера. 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++ и добавляют расширения, которые предоставляют специальные инструкции, позволяющие разработчикам приложений маркировать ядра и/или потоки. Это также относится к большинству языков шейдеров , которые в определенной степени можно считать потоковыми языками программирования.

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

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

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

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

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

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

Непрерывная обработка потока операторов [ нужны разъяснения ]

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

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

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

См. также

[ редактировать ]
  1. ^ КРАТКОЕ ВВЕДЕНИЕ В ПОТОКОВУЮ ОБРАБОТКУ
  2. ^ FCUDA: обеспечение эффективной компиляции ядер CUDA на FPGA
  3. ^ Журнал IEEE твердотельных схем: «Программируемый потоковый процессор 512 GOPS для обработки сигналов, изображений и видео» , Стэнфордский университет и Stream Processors, Inc.
  4. ^ Хайлани, Далли, Рикснер, Капаси, Оуэнс и Таулз: «Изучение масштабируемости потоковых процессоров VLSI» , Стэнфордский университет и Университет Райса.
  5. ^ Гуммараджу и Розенблюм, «Потоковая обработка в процессорах общего назначения» , Стэнфордский университет.
  6. ^ Капаси, Далли, Рикснер, Хайлани, Оуэнс, Ан и Мэттсон, «Программируемые потоковые процессоры» , Университеты Стэнфорда, Райса, Калифорнии (Дэвис) и Reservoir Labs.
  7. ^ Эрик Чан. «Стэнфордский проект программируемого затенения в реальном времени» . Сайт исследовательской группы . Проверено 9 марта 2017 г.
  8. ^ «The Imagine — процессор изображений и сигналов» . Веб-сайт группы . Проверено 9 марта 2017 г.
  9. ^ «Мерримак — Стэнфордский проект суперкомпьютера потокового вещания» . Веб-сайт группы . Архивировано из оригинала 18 декабря 2013 года . Проверено 9 марта 2017 г.
  10. ^ Представьте себе
  11. ^ Мерримак
  12. ^ Мемети, Суэйб; Планана, Сабри (октябрь 2018 г.). «HSTREAM: расширение языка на основе директив для гетерогенных потоковых вычислений». Международная конференция IEEE по вычислительной науке и технике (CSE) 2018 г. IEEE. стр. 138–145. arXiv : 1809.09387 . дои : 10.1109/CSE.2018.00026 . ISBN  978-1-5386-7649-3 .
  13. ^ PeakStream представляет решение для программирования многоядерных процессоров и процессоров/графических процессоров
  14. ^ TStreams: модель параллельных вычислений (технический отчет).
  15. ^ TStreams: Как написать параллельную программу (Технический отчет).
  16. ^ «GitHub — Walmartlabs/Mupd8: Маппет» . Гитхаб .


Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 77f0404c0bf34674f45e4d48fa1dd3ea__1722391500
URL1:https://arc.ask3.ru/arc/aa/77/ea/77f0404c0bf34674f45e4d48fa1dd3ea.html
Заголовок, (Title) документа по адресу, URL1:
Stream processing - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)