Потоковая обработка - Stream processing

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

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

В течение 1980-х годов обработка потоков исследовалась в программирование потока данных. Примером является язык СИЗАЛ (Потоки и итерация на едином языке назначения).

Приложения

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

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

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

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

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

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

Сравнение с предшествующими параллельными парадигмами

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

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

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

Традиционная последовательная парадигма

для (int я = 0; я < 400; я++)    результат[я] = source0[я] + источник1[я];

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

Парадигма параллельного SIMD, упакованные регистры (SWAR)

для (int эль = 0; эль < 100; эль++) // для каждого вектора    vector_sum(результат[эль], source0[эль], источник1[эль]);

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

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

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

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

// Это вымышленный язык для демонстрационных целей.элементы = массив streamElement([количество, количество])[100]ядро = пример streamKernel("@ arg0 [@iter]")результат = ядро.вызывать(элементы)

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

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

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

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

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

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

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

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

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

Недостатком программирования SIMD была проблема Массив структур (AoS) и структура массивов (SoA). Программисты часто хотели создавать структуры данных с «реальным» значением, например:

 // Частица в трехмерном пространстве.структура частица_t {    плавать Икс, у, z;          // даже не массив!    беззнаковый байт цвет[3]; // 8 бит на канал, допустим, нас интересует только RGB    плавать размер;    // ... и многие другие атрибуты могут следовать за ...};

Случилось так, что эти конструкции были собраны в массивы чтобы все было хорошо организовано. Это массив структур (AoS). Когда структура размещается в памяти, компилятор будет создавать чередующиеся данные в том смысле, что все структуры будут смежными, но будет постоянное смещение, скажем, между атрибутом "size" экземпляра структуры. и тот же элемент следующего экземпляра. Смещение зависит от определения структуры (и, возможно, других вещей, которые здесь не рассматриваются, например, политики компилятора). Есть и другие проблемы. Например, три позиционные переменные не могут быть преобразованы в SIMD таким образом, потому что нет уверенности, что они будут размещены в непрерывном пространстве памяти. Чтобы гарантировать, что операции SIMD могут работать с ними, они должны быть сгруппированы в «упакованную ячейку памяти» или, по крайней мере, в массив. Другая проблема заключается в том, что как «цвет», так и «xyz» должны быть определены в трехкомпонентных векторных величинах. Процессоры SIMD обычно поддерживают только 4-компонентные операции (однако, за некоторыми исключениями).

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

структура частица_t {    плавать *Икс, *у, *z;    беззнаковый байт *красный цвет, *цвет синий, *цветЗеленый;    плавать *размер;};

Для читателей, не знакомых с C, "*" перед каждым идентификатором означает указатель. В этом случае они будут использоваться для указания на первый элемент массива, который будет выделен позже. Для Ява программисты, это примерно эквивалентно "[]". Недостатком здесь является то, что различные атрибуты могут быть распределены в памяти. Чтобы убедиться, что это не вызывает промахов в кэше, нам нужно обновить все «красные», затем все «зеленые» и «синие».

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

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

#включают <raft>#включают <raftio>#включают <cstdlib>#включают <string>класс Здравствуй : общественный плот::ядро{общественный:    Здравствуй() : плот::ядро()    {       вывод.addPort< стандартное::строка >( "0" );     }    виртуальный плот::kstatus бегать()    {        вывод[ "0" ].От себя( стандартное::строка( "Привет мир п" ) );        вернуть( плот::Стоп );     }};intосновной( int argc, char **argv ){    / ** создать экземпляр ядра печати ** /    плот::Распечатать< стандартное::строка > п;    / ** создать экземпляр ядра hello world ** /    Здравствуй Здравствуйте;    / ** создаем объект карты ** /    плот::карта м;    / ** добавляем ядра на карту, и hello, и p выполняются одновременно ** /    м += Здравствуйте >> п;    / ** выполнить карту ** /    м.исполняемый файл();    вернуть( EXIT_SUCCESS );}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

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

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

Языки, зависящие от поставщика, включают:

Обработка на основе событий

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

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

Услуги потоковой обработки:

Смотрите также

использованная литература

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

внешние ссылки

  1. ^ Чинтапалли, Санкет; Дагит, Дерек; Эванс, Бобби; Фаривар, Реза; Грейвс, Томас; Холдербо, Марк; Лю, Чжо; Нусбаум, Кайл; Патил, Кишоркумар; Пэн, Боян Джерри; Поулски, Пол (май 2016 г.). «Тестирование механизмов потоковых вычислений: Storm, Flink и Spark Streaming». IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW) 2016 г.. IEEE. С. 1789–1792. Дои:10.1109 / IPDPSW.2016.138. ISBN  978-1-5090-3682-0. S2CID  2180634.