Stream-Verarbeitung - Wikipedia

Die Stream-Verarbeitung ist ein Computerprogrammierungsparadigma, das der Datenflussprogrammierung, der Ereignisstromverarbeitung und der reaktiven Programmierung entspricht. ^[1] ermöglicht es einigen Anwendungen, eine eingeschränkte Form der parallelen Verarbeitung leichter zu nutzen. Solche Anwendungen können mehrere Recheneinheiten verwenden, beispielsweise die Gleitkommaeinheit auf einer Grafikverarbeitungseinheit oder feldprogrammierbare Gate-Arrays (FPGAs) ^[2] ohne explizit die Zuordnung, Synchronisierung oder Kommunikation zwischen diesen Einheiten zu verwalten.

Das Stream-Processing-Paradigma vereinfacht parallele Software und Hardware, indem die durchzuführenden parallelen Berechnungen eingeschränkt werden. Bei einer Datensequenz (ein -Stream ) wird eine Reihe von Operationen ( Kernfunktionen ) auf jedes Element im Stream angewendet. Kernfunktionen werden in der Regel über ein Pipeline-Verfahren bereitgestellt, und es wird eine optimale lokale Wiederverwendung des Speichers auf dem Chip versucht, um den Bandbreitenverlust zu minimieren, der für die Interaktion mit dem externen Speicher anerkannt ist. Ein einheitliches Streaming bei dem eine Kernfunktion auf alle Elemente im Stream angewendet wird, ist typisch. Da die Kernel- und Stream-Abstraktionen Datenabhängigkeiten offenlegen, können Compiler-Tools On-Chip-Verwaltungsaufgaben vollständig automatisieren und optimieren. Stromverarbeitungshardware kann beispielsweise Scoreboarding verwenden, um einen direkten Speicherzugriff (Direct Memory Access, DMA) zu initiieren, wenn Abhängigkeiten bekannt werden. Durch den Wegfall des manuellen DMA-Managements wird die Softwarekomplexität reduziert, und für die durch Hardware zwischengespeicherten E / A-Einheiten entfällt die Datenbereichsausdehnung, die durch spezialisierte Recheneinheiten, wie z. B. arithmetische Logikeinheiten, in den Service einbezogen werden muss.

In den 1980er Jahren wurde die Stream-Verarbeitung in der Datenflussprogrammierung untersucht. Ein Beispiel ist die Sprache SISAL (Streams und Iteration in einer einzigen Zuweisungssprache).

Anwendungen [ edit ]

Die Stream-Verarbeitung ist im Wesentlichen ein Kompromiss, der von einem datenzentrischen Modell angetrieben wird, das sehr gut für traditionelle DSP- oder GPU-Anwendungen (wie z. B. Bild, Video- und digitale Signalverarbeitung), jedoch weniger für die allgemeine Verarbeitung mit mehr randomisiertem Datenzugriff (wie Datenbanken). Durch die Einbußen bei der Flexibilität des Modells ermöglichen die Auswirkungen eine einfachere, schnellere und effizientere Ausführung. Je nach Kontext kann das Prozessordesign auf maximale Effizienz oder einen Kompromiss für Flexibilität abgestimmt sein.

Die Stream-Verarbeitung eignet sich besonders für Anwendungen, die drei Anwendungseigenschaften aufweisen: ^{[ Zitat erforderlich ]}

• Compute Intensity Anzahl der Rechenoperationen pro E / A oder globaler Speicher Referenz. In vielen Signalverarbeitungsanwendungen liegt sie heute weit über 50: 1 und steigt mit der algorithmischen Komplexität.
• Datenparallelität existiert in einem Kernel, wenn dieselbe Funktion auf alle Datensätze eines Eingabestroms angewendet wird und mehrere Datensätze dies können gleichzeitig verarbeitet werden, ohne auf Ergebnisse aus früheren Datensätzen warten zu müssen.
• Data Locality ist eine bestimmte Art von zeitlicher Lokalität, die in Signal- und Medienverarbeitungsanwendungen üblich ist, wo Daten einmal erzeugt werden, ein oder zwei Mal später in der Anwendung gelesen werden und niemals Lies erneut. Zwischenströme, die zwischen Kerneln übertragen werden, sowie Zwischendaten in Kernelfunktionen können diese Lokalität direkt mit dem Programmiermodell für die Stream-Verarbeitung erfassen.

Beispiele für Datensätze in Streams sind:

• In Grafiken kann jeder Datensatz die Scheitelpunkt-, Normal- und Farbinformationen für ein Dreieck sein.
• Bei der Bildverarbeitung kann jeder Datensatz ein einzelner Bildpunkt aus einem Bild sein.
• In einem Videocodierer ist jeder Datensatz kann 256 Pixel sein, die einen Makroblock von Daten bilden; oder
• Bei der drahtlosen Signalverarbeitung könnte jeder Datensatz eine Folge von Abtastwerten sein, die von einer Antenne empfangen werden.

Für jeden Datensatz können wir nur vom Eingang lesen, Operationen daran ausführen und in den Ausgang schreiben. Es ist zulässig, über mehrere Eingänge und mehrere Ausgänge zu verfügen, aber niemals ein lesbarer und schreibbarer Speicher.

Vergleich mit früheren Parallelparadigmen [ edit ]

Grundlegende Computer gingen von einem sequentiellen Ausführungsparadigma aus. Herkömmliche CPUs basieren auf SISD, dh sie führen konzeptionell jeweils nur einen Vorgang aus. Mit den sich entwickelnden Anforderungen an die Datenverarbeitung der Welt stieg die zu verwaltende Datenmenge sehr schnell an. Es war offensichtlich, dass das sequentielle Programmiermodell den erhöhten Bedarf an Rechenleistung nicht bewältigen konnte. Es wurden verschiedene Anstrengungen unternommen, um alternative Wege zu finden, um riesige Mengen an Berechnungen durchzuführen, aber die einzige Lösung bestand darin, ein gewisses Maß an paralleler Ausführung zu nutzen. Das Ergebnis dieser Bemühungen war SIMD, ein Programmierparadigma, das die Anwendung eines Befehls auf mehrere Instanzen von (verschiedenen) Daten ermöglicht. Die meiste Zeit wurde SIMD in einer SWAR-Umgebung verwendet. Durch die Verwendung komplizierterer Strukturen könnte man auch MIMD-Parallelität haben.

Obwohl diese beiden Paradigmen effizient waren, wurden Realimplementierungen mit Einschränkungen von Speicherausrichtungsproblemen auf Synchronisationsprobleme und begrenzter Parallelität geplagt. Nur wenige SIMD-Prozessoren haben als eigenständige Komponenten überlebt. Die meisten waren in Standard-CPUs eingebettet.

Betrachten Sie ein einfaches Programm, das zwei Arrays addiert, die 100 4-Komponenten-Vektoren enthalten (d. H. Insgesamt 400 Zahlen).

Konventionelles, sequentielles Paradigma [ edit ]

 für   ( int   i   =   0 ;   <  100   *   4 ;   i  ++ )       Ergebnis  i  i ]   =   source0  [ i ]   +   + source1  [ i ] Dies ist das sequentielle Paradigma ist am vertrautesten. Es gibt Variationen (wie innere Schleifen, Strukturen und dergleichen), die sich letztendlich jedoch auf dieses Konstrukt beschränken. 
 
 Paralleles SIMD-Paradigma, gepackte Register (SWAR)  [ edit  
 
 für   ( int   el   =   0     el   <19659033] 100 ;   el  ++ ]   // für jeden Vektor       vector_sum  Ergebnis   el ]  source0  [ el   source1  el  el ]; 19659058] Dies ist eigentlich zu stark vereinfacht. Es nimmt die Anweisung  vector_sum  an. Obwohl dies mit den intrinsischen Anweisungen geschieht, werden hier viele Informationen nicht berücksichtigt, wie z. B. die Anzahl der Vektorkomponenten und das Datenformat. Dies geschieht aus Gründen der Klarheit. 
 Sie können jedoch sehen, dass diese Methode die Anzahl der dekodierten Anweisungen von  numElements * componentsPerElement  auf  numElements  reduziert. Die Anzahl der Sprungbefehle wird ebenfalls verringert, da die Schleife weniger oft ausgeführt wird. Diese Gewinne resultieren aus der parallelen Ausführung der vier mathematischen Operationen. 
 Was jedoch passiert ist, ist, dass das gepackte SIMD-Register eine bestimmte Datenmenge enthält, so dass es nicht möglich ist, mehr Parallelität zu erhalten. Die Beschleunigung ist etwas eingeschränkt durch die Annahme, dass wir vier parallele Operationen ausgeführt haben (bitte beachten Sie, dass dies sowohl für AltiVec als auch für SSE üblich ist). 
 
 Parallel-Stream-Paradigma (SIMD / MIMD)  [ edit ] 
 
 // Dies ist eine fiktive Sprache für Demonstrationszwecke.   =   array [19659031] streamElement  ([ Nummer   Nummer ]) [ 100    Kern   Beispiel   Beispiel   Beispiel   Beispiel    ( "@ arg0 [@iter]" )   Ergebnis   =   = Kernel .  Elemente  (19659046]).  
 
 In diesem Paradigma wird das gesamte Dataset definiert, anstatt dass jeder Komponentenblock separat definiert wird. Die Beschreibung des Datensatzes wird in den ersten beiden Zeilen angegeben. Danach wird das Ergebnis aus den Quellen und dem Kernel abgeleitet. Zur Vereinfachung gibt es eine 1: 1-Zuordnung zwischen Eingangs- und Ausgangsdaten, dies muss jedoch nicht sein. Angewandte Kernel können auch viel komplexer sein. 
 Eine Implementierung dieses Paradigmas kann eine Schleife intern "entrollen". Dadurch lässt sich der Durchsatz mit der Chipkomplexität skalieren und Hunderte von ALUs lassen sich leicht nutzen. [3][4]  Die Beseitigung komplexer Datenmuster macht einen großen Teil dieser zusätzlichen Energie verfügbar. 
 Die Stream-Verarbeitung ist zwar ein Zweig der SIMD / MIMD-Verarbeitung, darf aber nicht verwechselt werden. SIMD-Implementierungen können zwar oft "Streaming" arbeiten, ihre Leistung ist jedoch nicht vergleichbar: Das Modell sieht ein sehr unterschiedliches Nutzungsmuster vor, das eine weitaus höhere Leistung an sich erlaubt. 
 Es wurde festgestellt, dass bei generischen Prozessoren wie einer Standard-CPU nur eine Beschleunigung um das 1,5-fache erreicht werden kann. [5]  Im Gegensatz dazu erreichen Ad-hoc-Stream-Prozessoren leicht eine 10-fache Leistung, die hauptsächlich dem effizienteren Prozessor zugeschrieben wird Speicherzugriff und höhere Ebenen der parallelen Verarbeitung  [6]  
 Obwohl das Modell verschiedene Flexibilitätsgrade zulässt, haben Streamprozessoren normalerweise einige Einschränkungen für die Kern- oder Streamgröße. Beispielsweise fehlt der Consumer-Hardware häufig die Möglichkeit, hochpräzise Berechnungen durchzuführen, es fehlen komplexe Umleitungsketten oder die Anzahl der Befehle, die ausgeführt werden können, ist unterer Grenzen. 
 
 Forschung  [ edit ] 
 
 Zu den Stream-Verarbeitungsprojekten der Stanford University gehörte das Stanford Real-Time Programmable Shading Project, das 1999 gestartet wurde. [7]  Ein Prototyp namens Imagine wurde 2002 entwickelt. 19659133] Ein Projekt namens Merrimac lief bis etwa 2004. [9] AT & T untersuchte auch stromverbesserte Prozessoren, da sich Grafikverarbeitungseinheiten rasch sowohl in Bezug auf Geschwindigkeit als auch Funktionalität entwickelten. [1]  Seit diesen frühen Tagen wurden Dutzende von Streamverarbeitungssprachen entwickelt. sowie spezialisierte Hardware. 
 
 Anmerkungen zu Programmiermodellen  [ edit ] 
 
 Die unmittelbarste Herausforderung im Bereich der parallelen Verarbeitung liegt nicht so sehr in der Art der verwendeten Hardwarearchitektur, sondern in ihrer Einfachheit das betreffende System in einer realen Umgebung mit akzeptabler Leistung zu programmieren. Maschinen wie Imagine verwenden ein einfaches Single-Threaded-Modell mit automatisierten Abhängigkeiten, Speicherzuordnung und DMA-Planung. Dies ist an sich ein Ergebnis der Forschungen am MIT und Stanford, um eine optimale  Aufgabenverteilung  zwischen Programmierer, Werkzeugen und Hardware zu finden. Programmierer schlagen Werkzeuge bei der Abbildung von Algorithmen auf parallele Hardware, und Werkzeuge schlagen Programmierer bei der Ermittlung der intelligentesten Speicherzuweisungsschemata usw. besonders besorgniserregend sind MIMD-Entwürfe wie Cell, für die der Programmierer mit der Anwendungspartitionierung über mehrere Kerne und mit diesem umgehen muss Prozesssynchronisation und Lastverteilung. Effiziente Multi-Core-Programmierwerkzeuge fehlen heute stark. 
 Ein Nachteil der SIMD-Programmierung war die Ausgabe von Array-of-Structures (AoS) und Structure-of-Arrays (SoA). Programmierer wollten häufig Datenstrukturen mit einer 'echten' Bedeutung erstellen, zum Beispiel: 
 
  // Ein Teilchen in einem dreidimensionalen Raum.   struct   particle_t   {      float   x   y   z ;            // nicht einmal ein Array!       unsigniertes   Byte   color   3 ]   // 8 Bit pro Kanal, sagen wir wir kümmern uns nur um RGB       Float   Größe ;       // ... und viele andere Attribute können folgen ...  };  
 
 Was passiert ist, waren diese Strukturen damals in Arrays zusammengestellt, um die Dinge in Ordnung zu halten. Dies ist  Array von Strukturen  (AoS). Wenn die Struktur im Arbeitsspeicher angeordnet ist, erzeugt der Compiler verschachtelte Daten in dem Sinne, dass alle Strukturen zusammenhängend sind, zwischen dem Attribut "size" einer Strukturinstanz und dem gleichen Element jedoch ein konstanter Versatz besteht der folgenden Instanz. Der Versatz hängt von der Strukturdefinition ab (und möglicherweise von anderen Dingen, die hier nicht berücksichtigt werden, z. B. den Richtlinien des Compilers). Es gibt auch andere Probleme. Zum Beispiel können die drei Positionsvariablen nicht auf diese Weise SIMD-fähig sein, da sie nicht sicher sind, dass sie in einem kontinuierlichen Speicherbereich zugewiesen werden. Um sicherzustellen, dass SIMD-Operationen auf ihnen funktionieren können, müssen sie an einem 'gepackten Speicherort' oder zumindest in einem Array zusammengefasst werden. Ein weiteres Problem besteht darin, dass sowohl "Farbe" als auch "Xyz" in dreikomponentigen Vektormengen definiert werden. SIMD-Prozessoren unterstützen normalerweise nur 4-Komponenten-Operationen (mit einigen Ausnahmen). 
 Diese Art von Problemen und Einschränkungen machte die SIMD-Beschleunigung auf Standard-CPUs ziemlich unangenehm. Die vorgeschlagene Lösung  Struktur von Arrays  (SoA) sieht wie folgt aus: 
 
 struct   particle_t   {      float   *  x    y   z   z   z   z   z   z   z   z   z   z   z   z   z   z   z   z   z  z  z 
 
       unsigniertes   Byte   *  colorRed    *  colorBlue   * 19659046] colorgrreen ;   *  size ;  }  
 
 Für Leser, die nicht mit C vertraut sind, bedeutet "*" vor jedem Bezeichner einen Zeiger. In diesem Fall zeigen sie auf das erste Element eines Arrays, das später zugewiesen werden soll. Für Java-Programmierer entspricht dies ungefähr "[]". Der Nachteil hierbei ist, dass die verschiedenen Attribute im Speicher verteilt werden können. Um sicherzustellen, dass dies nicht zu Cache-Fehlern führt, müssen wir alle verschiedenen "Rottöne" und dann alle "Grüns" und "Blues" aktualisieren. 
 Für Stream-Prozessoren wird die Verwendung von Strukturen empfohlen. Aus Sicht der Anwendung können alle Attribute mit einiger Flexibilität definiert werden. Wenn Sie GPUs als Referenz verwenden, steht eine Reihe von Attributen (mindestens 16) zur Verfügung. Für jedes Attribut kann die Anwendung die Anzahl der Komponenten und das Format der Komponenten angeben (es werden jedoch nur primitive Datentypen unterstützt). Die verschiedenen Attribute werden dann an einen Speicherblock angehängt, der möglicherweise einen  -Schritt  zwischen "aufeinanderfolgenden" Elementen der gleichen Attribute definiert, wodurch effektiv verschachtelte Daten ermöglicht werden. Wenn die GPU mit der Stream-Verarbeitung beginnt,  werden alle verschiedenen Attribute in einem einzigen Satz von Parametern   gesammelt (normalerweise sieht dies aus wie eine Struktur oder eine "magische globale Variable"), führt die Operationen aus und  [Scatter]  die Ergebnisse in einen Speicherbereich zur späteren Verarbeitung (oder zum Abrufen). 
 Modernere Stream-Verarbeitungs-Frameworks bieten eine FIFO-ähnliche Schnittstelle, um Daten als Literal-Stream zu strukturieren. Diese Abstraktion bietet eine Möglichkeit, Datenabhängigkeiten implizit anzugeben, während Laufzeit / Hardware davon profitieren können Wissen für eine effiziente Berechnung. Eines der einfachsten  [ Zitat erforderlich ]  und das effizienteste  [ Zitat erforderlich ]  bisherige Verarbeitungsmodalitäten für C ++. ist RaftLib, das die Verknüpfung unabhängiger Rechenkerne als Datenflussdiagramm mithilfe von C ++ - Stream-Operatoren ermöglicht. Als Beispiel: 
 
 #include    #include    #include    #include     Klasse   hi  :   public   19659163] {  public :       hi  ()  :  : Floß :  Kern  
 (19659223) (19659223) (19659223)   addPort    std  ::  string  >  (  "0"  ); ] virtuelles   Floß  ::  kstatus   Lauf  ()       {          Ausgabe    0  ]. push  (  std  ::  string  (  "Hello World   n   ) 
" zurückkehren  (  Floß  ::  Stopp  );       }  ;    int   main  (  int   argc   char   **  argv  )   {[19659277] / ** instantiate print kernel ** /       raft  ::  print  <  std  ::  string  >   p [19659034];       / ** instantiate Hallo Weltkern ** /       hi   hallo ;       / ** ein Kartenobjekt erstellen ** /       raft  ::  map   m ;       / ** Kernel zur Karte hinzufügen, sowohl hallo als auch p werden gleichzeitig ausgeführt ** /       m   + =   hallo  >   p ;       / ** führt die Karte aus ** /       m .  exe  ();       return  (19659034] EXIT_SUCCESS  );  }  
 
 Berechnungsmodelle für die Stream-Verarbeitung  [ edit ] 
 
 Abgesehen von der Angabe von Streaming-Anwendungen in der Hochsprache. Berechnungsmodelle (MoCs) sind ebenfalls weit verbreitet, wie Datenflussmodelle und prozessbasierte Modelle. 
 
 Generische Prozessorarchitektur  [ edit ] 
 
 In der Vergangenheit begannen CPUs mit der Implementierung verschiedener Stufen von Speicherzugriffsoptimierungen aufgrund der ständig steigenden Leistung im Vergleich zu einer relativ langsam wachsenden externen Speicherbandbreite. Als sich diese Lücke vergrößerte, waren große Beträge der Chipfläche dazu gedacht, Speicherlatenzen zu verbergen. Da das Abrufen von Informationen und Opcodes zu diesen wenigen ALUs teuer ist, ist nur sehr wenig Werkzeugfläche für die eigentliche mathematische Maschinerie vorgesehen (als grobe Schätzung sollten weniger als 10% angenommen werden). 
 Eine ähnliche Architektur gibt es bei Stream-Prozessoren, aber dank des neuen Programmiermodells ist die Anzahl der für das Management bestimmten Transistoren tatsächlich sehr gering. 
 Aus der Sicht eines Gesamtsystems existieren Streamprozessoren normalerweise in einer kontrollierten Umgebung. GPUs sind auf einer Add-In-Karte vorhanden (dies scheint auch für Imagine zu gelten). CPUs erledigen den Dirty-Job, indem sie Systemressourcen verwalten, Anwendungen ausführen und dergleichen. 
 Der Stream-Prozessor ist normalerweise mit einem schnellen, effizienten proprietären Speicherbus ausgestattet (Crossbar-Switches sind mittlerweile üblich, in der Vergangenheit wurden bereits mehrere Busse eingesetzt). Die genaue Anzahl der Speicherebenen hängt vom Marktumfang ab. Da dies geschrieben wird, gibt es immer noch 64 Bit breite Verbindungen (Einstiegsebene). Die meisten Mittelklasse-Modelle verwenden eine schnelle 128-Bit-Crossbar-Switch-Matrix (4 oder 2 Segmente), während High-End-Modelle enorme Speicherkapazität (tatsächlich bis zu 512 MB) mit einer etwas langsameren Crossbar mit 256 Bit bereitstellen. Im Gegensatz dazu haben Standardprozessoren von Intel Pentium bis zu einigen Athlon 64 nur einen einzigen 64-Bit-Datenbus. 
 Speicherzugriffsmuster sind viel vorhersagbarer. Während Arrays existieren, ist ihre Dimension beim Kernelaufruf festgelegt. Die Sache, die einer Indirektion mit mehreren Zeigern am besten entspricht, ist eine Indirektionskette  die jedoch garantiert aus einem bestimmten Speicherbereich (innerhalb eines Streams) endlich lesen oder schreiben kann. 
 Aufgrund der SIMD-Natur der Ausführungseinheiten des Stream-Prozessors (ALUs-Clustern) werden Lese- / Schreibvorgänge voraussichtlich in großem Umfang ausgeführt, so dass Speicher eher für hohe Bandbreite als für niedrige Latenz optimiert werden (dies ist ein Unterschied zu Rambus und DDR.) SDRAM zum Beispiel). Dies ermöglicht auch effiziente Speicherbusverhandlungen. 
 Die meisten (90%) der Arbeit eines Stream-Prozessors werden auf dem Chip ausgeführt, sodass nur 1% der globalen Daten im Speicher abgelegt werden müssen. Hier zahlt es sich aus, die Kernel-Provisorien und Abhängigkeiten zu kennen. 
 Intern verfügt ein Stream-Prozessor über einige clevere Kommunikations- und Verwaltungsschaltungen. Interessant ist jedoch die  -Stream-Register-Datei  (SRF). Hierbei handelt es sich konzeptionell um einen großen Cache, in dem Stromdaten gespeichert werden, um in großen Mengen an einen externen Speicher übertragen zu werden. Als cacheartige, softwaregesteuerte Struktur für die verschiedenen ALUs wird die SRF von allen verschiedenen ALU-Clustern gemeinsam genutzt. Mit dem Imagine-Chip von Stanford ist das Schlüsselkonzept und die Innovation, dass der Compiler in der Lage ist, Speicher optimal zu automatisieren und zuzuordnen, der für den Programmierer völlig transparent ist. Die Abhängigkeiten zwischen Kernelfunktionen und Daten sind durch das Programmiermodell bekannt, durch das der Compiler eine Flussanalyse durchführen und die SRFs optimal packen kann. Normalerweise kann dieses Cache- und DMA-Management den Großteil des Zeitplans eines Projekts einnehmen, was der Stream-Prozessor (oder zumindest Imagine) vollständig automatisiert. In Stanford durchgeführte Tests haben gezeigt, dass der Compiler die Speicherplanung besser oder besser erledigt hat, als wenn Sie die Sache mit viel Aufwand manuell einstellen. 
 Es gibt Beweise; Es kann viele Cluster geben, da angenommen wird, dass die Kommunikation zwischen Clustern selten ist. Intern kann jedoch jeder Cluster eine wesentlich geringere Anzahl von ALUs nutzen, da die Kommunikation innerhalb eines Clusters häufig ist und daher sehr effizient sein muss. 
 Damit diese ALUs mit Daten abgerufen werden, ist jede ALU mit lokalen Registerdateien (LRFs) ausgestattet, die im Wesentlichen ihre verwendbaren Register sind. 
 Dieses dreistufige Datenzugriffsmuster macht es leicht, temporäre Daten von langsamen Speichern fernzuhalten, wodurch die Siliziumimplementierung sehr effizient und energiesparend ist. 
 
 Probleme mit der Hardware-in-the-Loop  [ edit ] 
 
 Obwohl eine Beschleunigung in der Größenordnung vernünftigerweise erwartet werden kann (selbst von Mainstream-GPUs bei der Streaming-Berechnung), nicht alle anwendungen profitieren davon. Kommunikationslatenzen sind eigentlich das größte Problem. Obwohl PCI Express dies bei der Vollduplex-Kommunikation verbessert hat, kann die Inbetriebnahme einer GPU (und möglicherweise eines generischen Stream-Prozessors) möglicherweise lange Zeit in Anspruch nehmen. Dies bedeutet, dass es normalerweise kontraproduktiv ist, sie für kleine Datensätze zu verwenden. Da das Wechseln des Kernels ein ziemlich teurer Vorgang ist, führt die Stream-Architektur auch zu Strafen für kleine Streams, ein Verhalten, das als  Short Stream-Effekt  bezeichnet wird. 
 Pipelining ist bei Streamprozessoren eine weit verbreitete und häufig angewandte Praxis. GPUs verfügen über Pipelines mit mehr als 200 Stufen. Die Kosten für das Umschalten der Einstellungen hängen von der Einstellung ab, die geändert wird, gelten jedoch jetzt immer als teuer. Um diese Probleme auf verschiedenen Ebenen der Pipeline zu vermeiden, wurden viele Techniken eingesetzt, z. B. "Über-Shader" und "Textur-Atlanten". Diese Techniken sind aufgrund der Natur von GPUs spielorientiert, aber die Konzepte sind auch für die Verarbeitung generischer Streams interessant. 
 
 Beispiele  [ edit ] 
 
 Der Blitter im Commodore Amiga ist ein früher (ca. 1985) Grafikprozessor, der drei Quellströme von 16 Komponentenbitvektoren auf 256 Arten kombinieren kann ein Ausgangsstrom, der aus 16 Komponentenbitvektoren besteht. Die gesamte Eingangsstrom-Bandbreite beträgt bis zu 42 Millionen Bits pro Sekunde. Die Bandbreite des Ausgabestroms beträgt bis zu 28 Millionen Bits pro Sekunde. 
 
 Imagine [10]  unter der Leitung von Professor William Dally von der Stanford University ist eine flexible Architektur, die sowohl schnell als auch energieeffizient sein soll. Das ursprünglich 1996 konzipierte Projekt umfasste Architektur, Softwaretools, eine VLSI-Implementierung und ein Entwicklungsboard und wurde von DARPA, Intel und Texas Instruments finanziert. 
 
 Ein weiteres Stanford-Projekt mit dem Namen Merrimac [11]  zielt auf die Entwicklung eines Projekts ab Stream-basierter Supercomputer. Merrimac beabsichtigt, eine Stream-Architektur und fortschrittliche Verbindungsnetze zu verwenden, um mehr Leistung pro Kosteneinheit bereitzustellen als Cluster-basierte wissenschaftliche Computer, die auf der gleichen Technologie basieren. 
 
 Die  Storm-1  -Familie von Stream Processors, Inc, Ein kommerzielles Spin-off-Projekt von Stanford  Imagine  wurde während einer Präsentation auf der ISSCC 2007 angekündigt. Die Familie besteht aus vier Mitgliedern, die von 30 GOPS bis hin zu 220 16-Bit-GOPS (Milliarden Operationen pro Sekunde) reichen Bei TSMC in einem 130-Nanometer-Prozess hergestellt. Die Geräte zielen auf das High-End-Segment des DSP-Marktes, einschließlich Videokonferenzen, Multifunktionsdrucker und digitale Videoüberwachungsgeräte. 
 
 GPUs sind weit verbreitete Stream-Prozessoren für Endverbraucher (19659344), die hauptsächlich von AMD und Nvidia entwickelt wurden. Verschiedene Generationen, die aus Sicht der Stream-Verarbeitung zu beachten sind: 
 Pre-R2xx / NV2x: Keine explizite Unterstützung für die Stream-Verarbeitung. Kerneloperationen waren in der API verborgen und boten zu wenig Flexibilität für die allgemeine Verwendung. 
 
 R2xx / NV2x: Kernelstromoperationen wurden explizit der Kontrolle des Programmierers unterworfen, jedoch nur für die Verarbeitung von Scheitelpunkten (Fragmente verwendeten immer noch alte Paradigmen). Keine Verzweigungsunterstützung behinderte die Flexibilität erheblich, aber einige Algorithmen könnten ausgeführt werden (insbesondere Fluidsimulation mit niedriger Genauigkeit). 
 
 R3xx / NV4x: flexible Verzweigungsunterstützung, obwohl einige Einschränkungen hinsichtlich der Anzahl der auszuführenden Operationen und der strengen Rekursion bestehen Tiefe sowie Array-Manipulation. 
 
 R8xx: Unterstützt das Anhängen / Verbrauchen von Puffern und atomare Operationen. Diese Generation ist Stand der Technik. 
 
 
 
 AMD FireStream-Markenname für die HPC-Produktlinie 
 
 Nvidia Tesla-Markenname für die HPC-Produktlinie 
 
 The Cell processor aus  STI eine Allianz von Sony Computer Entertainment, Toshiba Corporation und IBM, ist eine Hardwarearchitektur, die wie ein Stream-Prozessor mit entsprechender Software-Unterstützung funktionieren kann. Es besteht aus einem steuernden Prozessor, dem PPE (Power Processing Element, ein IBM PowerPC) und einem Satz von SIMD-Coprozessoren (SPEs (Synergistic Processing Elements)) mit jeweils unabhängigen Programmzählern und Anweisungsspeicher, die eigentlich eine MIMD-Maschine sind. Im nativen Programmiermodell bleibt die gesamte DMA- und Programmplanung dem Programmierer überlassen. Die Hardware bietet einen schnellen Ringbus zwischen den Prozessoren für die lokale Kommunikation. Da der lokale Speicher für Anweisungen und Daten begrenzt ist, erfordern die einzigen Programme, die diese Architektur effektiv nutzen können, entweder nur einen geringen Speicherbedarf oder benötigen ein Stream-Programmiermodell. Mit einem geeigneten Algorithmus kann die Leistung der Zelle mit der von reinen Stream-Prozessoren mithalten, was jedoch fast immer eine vollständige Neugestaltung von Algorithmen und Software erfordert. 
 Stream-Programmierungsbibliotheken und -sprachen  [ edit  
 
 Die meisten Programmiersprachen für Stream-Prozessoren beginnen mit Java, C oder C ++ und fügen Erweiterungen hinzu, die spezifische Anweisungen enthalten, mit denen Anwendungsentwickler Kernel und / oder Streams kennzeichnen können. Dies gilt auch für die meisten Shadingsprachen, die bis zu einem gewissen Grad als Programmiersprachen angesehen werden können. 
 Nichtkommerzielle Beispiele für Stream-Programmiersprachen umfassen: 
 
 Ateji PX Free Edition ermöglicht einen einfachen Ausdruck der Stream-Programmierung, des Actor-Modells und des MapReduce-Algorithmus auf JVM 
 
 Auto-Pipe aus dem Stream Based Supercomputing Lab der Washington University in St. Louis, einer Anwendungsentwicklung Umgebung für Streaming-Anwendungen, die das Authoring von Anwendungen für heterogene Systeme (CPU, GPGPU, FPGA) ermöglicht. Anwendungen können in jeder Kombination von C, C ++ und Java für die CPU entwickelt werden. Verilog oder VHDL für FPGAs. Cuda wird derzeit für Nvidia GPGPUs verwendet. Auto-Pipe übernimmt auch die Koordination von TCP-Verbindungen zwischen mehreren Rechnern. 
 
 ACOTES-Programmiermodell: Sprache der Polytechnischen Universität von Katalonien basierend auf OpenMP 
 
 BeepBeep, einer einfachen und schlanken Java-basierten Ereignisstromverarbeitungsbibliothek von Formal Computer Science Labor an der Université du Québec à Chicoutimi 
 
 Brook Language aus Stanford 
 
 CAL Actor Language: Eine hochrangige Programmiersprache für das Schreiben von (Datenfluss) -Actoren. Dabei handelt es sich um zustandsorientierte Operatoren, die Eingangsströme von Datenobjekten (Token) in Ausgaben umwandeln Streams. 
 
 Cal2Many ein Code-Generierungs-Framework von der Halmstad University, Schweden. Es verwendet CAL-Code als Eingabe und generiert verschiedene zielspezifische Sprachen, darunter sequentielles C, Meißel, paralleles C für die Epiphany-Architektur, Ajava & Astruct für die Ambric-Architektur usw. 
 
 DUP-Sprache der Technischen Universität München und der Universität von Denver [19659017] HSTREAM: Eine richtlinienbasierte Spracherweiterung für heterogenes Stream-Computing  [12]  
 
 RaftLib - Open Source-C ++ - Stream-Verarbeitungsvorlagenbibliothek, die ursprünglich aus dem Stream Based Supercomputing Lab der Washington University in St. Louis 
 
 stammt ] SPar - C ++ - domänenspezifische Sprache zum Ausdruck von Stream-Parallelismus aus der Application Modeling Group (GMAP) der Päpstlichen Katholischen Universität von Rio Grande do Sul 
 
 Sh-Bibliothek der University of Waterloo 
 
 Shallows, ein Open Source-Projekt [19659017] S-Net-Koordinationssprache von der University of Hertfordshire, die eine Trennung von Koordination und algorithmischer Programmierung ermöglicht 
 
 Strea mIt von MIT 
 
 Siddhi von WSO2 
 
 WaveScript Funktionale Stream-Verarbeitung, auch von MIT. 
 
 Funktionale reaktive Programmierung könnte als Stream-Verarbeitung im weitesten Sinne betrachtet werden. 
 Kommerzielle Implementierungen sind entweder allgemein verwendbar oder spezifisch Hardware von einem Anbieter. Beispiele für Mehrzwecksprachen sind: 
 
 AccelerEyes 'Jacket, eine Kommerzialisierung einer GPU-Engine für MATLAB 
 
 Ateji PX-Java-Erweiterung, die einen einfachen Ausdruck der Stream-Programmierung, des Actor-Modells und des MapReduce-Algorithmus 
 
 Embiot, eines leichtgewichtigen Streaming-Analyse-Agenten, ermöglicht von Telchemy 
 
 Floodgate, ein Stream-Prozessor, der mit der Gamebryo-Game-Engine für PlayStation 3, Xbox360, Wii und PC 
 
 OpenHMPP, einer "Direktive" -Version der Many-Core-Programmierung 
 
 PeakStream, [13]  a bereitgestellt wird Ausgliederung des Brook-Projekts (Übernahme durch Google im Juni 2007) 
 
 Deklarative Engine für IBM Spade - Stream-Verarbeitungsanwendungen (B. Gedik, et al. SPADE: die deklarative Stream-Processing-Engine des Systems. ACM SIGMOD 2008.) 
 
 RapidMind, eine Vermarktung von Sh (erworben von Intel im August 2009) 
 
 TStreams, [14][15]  Hewlett-Packard Cambridge Research Lab 
 Zu den anbieterspezifischen Sprachen gehören: 
 
 Ereignisbasierte Verarbeitung 
 
Batch File-Based Processing (emulates some of actual stream processing, but much lower performance in general[clarification needed][citation needed]) 
 
Continuous Operator Stream Processing[clarification needed]
 
Stream Processing Services: 
 
See also[edit]
 
References[edit]
 
 
^ A SHORT INTRO TO STREAM PROCESSING 
 
^ FCUDA: Enabling Efficient Compilation of CUDA Kernels onto FPGAs 
 
^ IEEE Journal of Solid-State Circuits:"A Programmable 512 GOPS Stream Processor for Signal, Image, and Video Processing", Stanford University and Stream Processors, Inc. 
 
^ Khailany, Dally, Rixner, Kapasi, Owens and Towles: "Exploring VLSI Scalability of Stream Processors", Stanford and Rice University. 
 
^ Gummaraju and Rosenblum, "Stream processing in General-Purpose Processors", Stanford University. 
 
^ Kapasi, Dally, Rixner, Khailany, Owens, Ahn and Mattson, "Programmable Stream Processors", Universities of Stanford, Rice, California (Davis) and Reservoir Labs. 
 
^ Eric Chan. "Stanford Real-Time Programmable Shading Project". Research group web site. Retrieved March 9, 2017. 
 
^ "The Imagine - Image and Signal Processor". Group web site. Retrieved March 9, 2017. 
 
^ "Merrimac - Stanford Streaming Supercomputer Project". Group web site. Archived from the original on December 18, 2013. Retrieved March 9, 2017. 
 
^ Imagine 
 
^ Merrimac 
 
^ Memeti, Suejb; Pllana, Sabri (October 2018). HSTREAM: A Directive-Based Language Extension for Heterogeneous Stream Computing. IEEE. doi:10.1109/CSE.2018.00026. Retrieved 30 December 2018. 
 
^ PeakStream unveils multicore and CPU/GPU programming solution 
 
^ TStreams: A Model of Parallel Computation (Technical report). 
 
^ TStreams: How to Write a Parallel Program (Technical report). 
 
 
External links[edit]