technische universität dortmund fakultät für informatik informatik 12 Rechnerarchitektur (RA) Sommersemester 2015 Foliensatz 7: Non-Standard-Rechner Michael Engel Informatik 12 michael.engel@tu-.. http://ls12-www.cs.tu-dortmund.de/daes/ Tel.: 0231 755 6121 2014/04/27 Diese Folien enthalten Graphiken mit Nutzungseinschränkungen. Das Kopieren der Graphiken ist im Allgemeinen nicht erlaubt. 2.7 ASIPs Application-specific instruction set processor (ASIP): Befehlssatz aufgrund der Anwendung festgelegt. Einsatz: § U.a. für effiziente eingebettete Prozessoren Frühe Beispiele: § Yasuura et al. (Fukuoka, Japan): Generische Architektur, u.a. Datenwortbreiten anwendungsabhängig. § I.-J. Huang (USC): Weglassen nicht benötigter Befehle. Wissenschaftliche Fragestellung: § Wie konstruiert man systematisch „den besten“ Befehlssatz zu einer Anwendung? technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 2- Literatur § M. K. Jain, M. Balakrishnan, Anshul Kumar: ASIP Design Methodologies : Survey and Issues, VLSI Design, 2001 § M. Gries, K. Keutzer (Hrg.): Building ASIPs: The Mescal Methodology, Springer, 2005 § P. Ienne, R. Leupers (Hrg.): Customizable Embedded Processors, Morgan Kaufmann, 2006 § O. Schliebusch, H. Meyr, R. Leupers: Optimized ASIP Synthesis from Architecture Description Language Models, Springer, 2007 § T. Shiro, M. Abe, K. Sakanushi, Y. Takeuchi, M. Imai: A Processor Generation Method from Instruction Behavior Description Based on Specification of Pipeline Stages and Functional Units, ASP-DAC, 2007 § C. Wolinski, K. Kuchcinski: Automatic selection of application-specific reconfigurable processor extensions, DATE, 2008 § Laura Pozzi, Kubilay Atasu, Paolo Ienne: Exact and approximate algorithms for the extension of embedded processor instruction sets. IEEE Transactions on CAD, 2006. § Tensilica Inc.: The xpres compiler: Triple-threat solution to code performance challenges. Tensilica Inc. Whitepaper, 2005. technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 3- Existenznachweis der Energieeffizienz © Hugo De Man: From the Heaven of Software to the Hell of Nanoscale Physics: An Industry in Transition, Keynote Slides, ACACES, 2007 technische universität dortmund fakultät für informatik Close to power efficiency of silicon © marwedel/fink/engel informatik 12, 2015 - 4- 2.8 Abstrakte Maschinen Maschinen, die jeweils einen abstrakten Befehlssatz interpretieren. Programme werden in Befehle der abstrakten Befehlssätze übersetzt, nicht direkt in Maschinenbefehle realer Maschinen. Beispiele: abstrakte Befehlssätze zur Realisierung von Java, (UCSD-) Pascal, PROLOG, LISP, FORTH, Smalltalk usw.. Java Lediglich der Interpreter der abstrakten Befehlssätze muss für verschiedene Maschinen jeweils neu erzeugt werden. Nachteil: niedrigere Ausführungsgeschwindigkeit. technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 5- Java Virtual Machine Java: § Objektorientierte Programmiersprache § Datentypen: byte, short, int, long, float, double, char § Unterstützt Netzwerk-Programmierung § Im Hinblick auf Sicherheit entworfen: • keine Pointer-Manipulation wie in C, C++. • beschränkte Möglichkeit, Informationen über die momentane Umgebung zu erfahren § § § § Automatische Freispeicherverwaltung Multithreading Über Netze auf alle relevanten Maschinen zu laden. Java-Programme können dort ausgeführt werden, wo die JVM realisiert ist. technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 6- Eigenschaften der JVM § Die JVM ist eine Kellermaschine, § Operationscodes in einem Byte kodiert, § Typische Befehle: • lade integer auf den Keller, • addiere die obersten Kellerelemente, + • starte nebenläufige Ausführung, • synchronisiere nebenläufige Ausführung, • Befehle zur Realisierung der Objektorientierung § Byte-Code ist kompakt (≈ 1/3 der Größe von RISC-Code). Wichtig, wenn Code auf Prozessorchip zu speichern ist. § JVM verzichtet weitgehend auf Alignment-Beschränkungen technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 7- 3 Methoden der Realisierung von JVMs: 1. Durch Interpretation von JVM-Befehlen in Software, 2. Durch Übersetzung in den Maschinencode der aufrufenden Maschine unmittelbar vor der Ausführung; just-in-time compilation. 3. Durch Realisierung einer JVM als „echte” Maschine. F Exemplarische Betrachtung von Entwicklungszielen technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 © Microsoft Warum interessiert man sich für eine „echte“ Java-Maschine? - 8- PicoJava § Ziel v.a. Verbesserung der Performance und für den Einsatz in vernetzten eingebetteten Systemen (GPS, Mobiltelephon, Netzwerktechnik, Chipcard-Systeme ..) § PicoJava (I) (Sun, 1997): Spezifiziert, aber nie realisiert • Oberste Kellerelemente im Prozessor in schnellem Speicher • Häufigste Befehle in Hardware ausgeführt, CPI=1. • Komplexere Befehle: Mikroprogramm. • Ganz komplexe Befehle: Interrupt + Software § PicoJava II (Sun, 1999): Spec frei verfügbar (u.a. http://www1.pldworld.com/@xilinx/html/pds/HDL/picoJava-II/ DOCS/pj2-uarch-guide.pdf technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 9- PicoJava (2) DripplingMechanismus für stack Ausgangsbasis für Realisierungen in FPGAs etc. technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 © Graphik: Microsoft - 10 - Design: S. Uhrig (jetzt Fak. ET+IT, TU Dortmund!), Ungerer, .. § Schwergewicht auf Realzeitfähigkeit § Mehrfädig (engl. multi-threaded) § Thread-tag wird im Fließband mitgeführt § Prioritäten Manager selektiert nächsten Befehl: • Fixed Priority Preemptive (FPP): #(Prioritätsebenen) = #(Hardware-Threads) • Earliest Deadline First (EDF): Jedem HardwareThread muss eine 32-Bit Deadline zugeordnet werden. • Least Laxity First (LLF): Jedem Hardware-Thread 32-Bit Laxity = (Deadline-Laufzeit) zugeordnet. • Guaranteed Percentage (GP): Jeder Thread erhält Prozentanteil (genau, minimal oder maximal) technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 © Microsoft Komodo (1) - 11 - Komodo (2): Realzeitfähigkeit der Garbage-Collection Anforderungen: § Inkrementell § Zeitlich vorhersagbar (feste obere Zeitschranken) § Möglich (verfügbare Zeit nicht überschreiten) § Robust (wenige Fehlermöglichkeiten für Programmierer) § Effizient (wenig Prozessorzeit) § Wenig Synchronisation (keine Pausen für Anwendungen) § Nicht-kopierend Lösung § Ausnutzen der Multi-threading Möglichkeit § Anpassen eines existierenden Algorithmus an Real-TimeAnforderungen © Microsoft S. Fuhrmann, M. Pfeffer, J. Kreuzinger, Th. Ungerer, U. Brinkschulte: Real-Time Garbage Collection for a Multithreaded Java Microcontroller, 4th International Symposium on Object-Oriented Real-Time Distributed Computing, 2001 technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 12 - JOP - Java Optimized Processor § JOP is a processor designed to implement the JVM in hardware. § It is part of a PhD thesis at the Vienna University of Technology § Goal a simple and small processor optimized to execute Java § Thread support can simplify development of embedded systems § Common implementations of the JVM as interpreter or just-in-time compiler, are not practical. § http://www.jopdesign.com/ describes JOP (a Java Optimized Processor) is a hardware implementation of the JVM with predictable execution time for embedded real-time systems. § Due to the small size, it can be implemented in a low cost FPGA. For low volume systems, the flexibility of an FPGA can be important § Complete VHDL source and tools in Java are available for download from http://www.jopdesign.com/ . http://www.jopdesign.com/ technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 13 - Jazelle DBX (Direct Bytecode Execution) § Erlaubt es einigen ARM-Prozessoren Java Bytecode als 3. Betriebsmodus neben ARM und Thumb Modi § Gestartet mittels „branch to Java“ Befehl BXJ § Der erste Prozessor war der ARM926EJ-S § Häufig ausgeführte Codes werden in Hardware ausgeführt (gemäß ARM, 95% der Befehle in HW ausgeführt) § Andere Codes werden in SW ausgeführt § Basis: schnelle binary translation: JVM Codes werden während der Ausführung in ARM-Befehle übersetzt § just-in time translation nicht mehr notwendig http://en.wikipedia.org/wiki/Jazelle technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 14 - Nicht-Von-Neumann-Maschinen Wir geben die sequentielle Ausführung von Programmcode auf …. technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 15 - Rekonfigurierbare Logik Anwendungsspezifische HW zu teuer, SW zu langsam. Geschwindigkeit von HW mit Flexibilität von SW verbinden: F HW mit programmierbaren Funktionen und Interconnect. F Verwendung konfigurierbarer Hardware; Standard: field programmable gate arrays (FPGAs) Anwendungen: § § § § Algorithmen zur ver/entschlüsselung von Daten, pattern matching in der Bioinformatik, Sehr schnelle Filterung von Ereignissen (Hochenergie- Physik), Sehr schneller Spezialhardware. FPGAs verfügbar von diversen Herstellern, z.B. § XILINX, Actel, Altera und andere technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 16 - Floorplan von VIRTEX II FPGAs technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 17 - Interconnects des Virtex II Hierarchische RoutingRessourcen; Aktueller: Virtex 5, 6, 7 Deutlich komplexer, z.B. stacked silicon interconnects. technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 18 - Virtex 7 Configurable Logic Block (CLB) http://www.xilinx.com/support/documentation/ user_guides/ug474_7Series_CLB.pdf technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 19 - Virtex 7 Slice (vereinfacht) Speicher meist verwendet als lookup tables (Wertetabellen) zur Implementierung Boolescher Funktionen mit ≤ 6 Variablen. Prozessoren oft als “soft cores” (z.B. microblaze), aber auch “hard cores” (ARM, PPC) verfügbar technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 20 - Virtex 7 SliceM SliceM erlaubt die Verwendung von Speicher als Datenspeicher oder Schieberegister Ermöglicht die Implementierung vieler nichtstandard Architecturen F http://www.xilinx.com/support/documentation/ user_guides/ug474_7Series_CLB.pdf technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 © Xilinx - 21 - Zusammenfassung § Application Specific Instruction Set Processors § Abstrakte Maschinen § Field programmable gate arrays (FPGAs) § Weitere Architektur: Datenflussrechner technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 22 - Datenflussprinzip: Systolisches Feld A systolic array is a special-purpose parallel device, made out of a few simple cell types which are regularly and locally connected. [F H.T. Kung ] Beispiel: § Parallele Eingabe: à § Einfache Zellen („CondSwap“, „Nop“): § Reguläre Struktur: à à à à à technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 23 - Beispiel für ein systolisches Feld: odd-even transposition sort (OETS), n=8 8 7 → 7 8 7 5 5 → 3 → 3 5 3 1 1 1 → 5 → 7 5 3 5 6 → 6 3 8 3 → → → 1 → 7 1 2 2 → 2 3 → 3 → 8 7 5 4 5 → → → 7 → → 4 4 → 8 6 2 2 6 4 → 1 4 2 8 4 → 1 6 2 7 4 → 4 5 technische universität dortmund → 2 4 1 8 2 → → 6 1 → 3 6 6 → 8 → 6 fakultät für informatik 7 8 Daten werden synchron durch einoder zweidimensionale Felder "gepumpt" und dabei werden auf diesen Daten Berechnungen ausgeführt. Prozessoren führen feste Befehle aus. Sortieren mit Aufwand von n², Latenz n und Durchsatz ≈ O(1). © marwedel/fink/engel informatik 12, 2015 - 24 - Behauptung: systolisches Array für Matrixmultiplikation Wie kann man systolische Arrays systematisch konstruieren? technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 25 - Neuronale Netze § Neuronale Netze emulieren Netze von Neuronen in Lebewesen § Einsatz zur Klassifikation von Mustern und als nicht-lineare adaptive Filter ⎛ ⎞ yi = f ⎜⎜ ∑ wij y j ⎟⎟ ⎝ j ⎠ § Neuronale Netze erfordern eine Anlernphase zum Einstellen der Parameter § Sind geeignet, wenn sonst wenig Erfahrung zur Lösung des Problems vorliegt. technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 26 - 2.9 Datenflussmaschinen Verfügbarkeit von Daten veranlasst Ausführung von Operationen: Beispiel: z = (x + y) * (x - y); # x, y, z: Benennungen für Werte. x * y + z Die Operation beginnt, falls alle Argumente berechnet worden sind. Modellierung mit Marken: Gültige Daten werden als Marken dargestellt. Eine Operation kann ausgeführt werden, falls alle ihre Argumente markiert sind. Potenziell viele Operationen gleichzeitig! technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 27 - Darstellung der Befehle in der Maschine (Dennis) Als Tupel (Opcode, Plätze für Argumente, Ziel-Liste). Die Ziel-Liste ist die Liste der Tupel, die das Ergebnis als Argument benötigen. technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 28 - Komplizierterer Fall y := (IF x > 3 THEN x+2 ELSE x-1) * 4 Suche nach Treffern ähnlich „reservation stations“ bei Tomasulo Algorithmus (nächstes Kapitel) Statischer Datenfluss: Zuordnung Token/Operation sind fest technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 29 - Dynamischer Datenfluss § Es wird dynamisch nach zueinander passenden Daten gesucht § Erst im Fall eines Treffers werden die dazugehörigen Befehle geholt. § Erlaubt, für mehrere Daten Befehle gemeinsam zu nutzen, z.B. für alle Komponenten eines Arrays § Wegen der dynamischen Suche nach passenden Daten (über Assoziativspeicher) relativ hoher Aufwand technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 30 - Historie der Datenflussrechner § Euphorie Ende der 70er Jahre § Stille Ende der 80er Jahre § Prinzipien später teilweise in andere Systeme integriert • Datenflussrechner können leicht asynchron realisiert werden, benötigen so wenig Energie (z.B. Entwicklung . Sharp/U.Kochi/ U.Osaka für Videokameras) • Von-Neumann-Rechner mit dynamischen Scheduling (Scoreboarding, Tomasulo-Algorithmus) [Kap.3] haben das Datenflussprinzip intern übernommen. • Datenflusssprachen: LabView, Simulink, …. F „Datenflussrechner“ sind Realität, aber nicht in der ursprünglich angedachten Form technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 31 - At last …: Kommerzielles Angebot www.maxeler.com technische universität dortmund Benutzt u.a. zur Erderkundung (Ölsuche) und high speed trading fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 32 - +1 technische universität dortmund fakultät für informatik Pell, O.; Averbukh, V., "Maximum Performance Computing with Dataflow Engines," Computing in Science & Engineering , vol.14, no.4, pp.98,103, July-Aug. 2012 Beispiel für die Programmierung © marwedel/fink/engel informatik 12, 2015 © IEEE, 2012 - 33 - Vorteile der Datenflussrechner Vorteile § eingebaute Parallelität, eingebaute Synchronisation; vereinfachte Parallelisierung § Adressen sind nach außen nicht sichtbar § vorteilhaft bei gemeinsamen Teilausdrücken § beliebige Reihenfolge der Abarbeitung bereiter Befehle technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 34 - 2.10 Funktionale Programmierung und Reduktionsmaschinen § Maschinen unterstützen die Auswertung funktionaler Programme direkt. § Reduktionsmaschinen akzeptieren Ausdrücke einer funktionalen Sprache. § Auswertung mittels Baumtransformationen, bis ein Wert erhalten wird. § Die Bedeutung eines Programms = abgelieferter Wert. § Einfachere Verifikation § Vereinfachte Parallelverarbeitung technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 35 - Auswertungsstrategien 1. string reduction Jede Operation, die auf eine bestimmte Definition (auf einen bestimmten Teilbaum) zugreift, erhält und bearbeitet eine Kopie des Teilbaums. èerleichterte Realisierung, schnelle Bearbeitung skalarer Werte, ineffiziente Behandlung gemeinsamer Teilausdrücke. 2. graph reduction Jede Operation, die auf eine bestimmte Definition zugreift, arbeitet über Verweise auf der Original-Definition. è schwieriger zu realisieren, falls parallel bearbeitet wird; effizient auch für strukturierte Werte und gemeinsame Teilausdrücke; komplizierte Haldenverwaltung (garbage collection). technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 36 - Steuerung der Berechnungs-Reihenfolge 1. Die „outermost”- oder „demand driven”-Strategie: Operationen werden selektiert, wenn der Wert, den sie produzieren, von einer bereits selektierten Operation benötigt wird. Erlaubt lazy evaluation. Erlaubt konzeptuell unendliche Listen, solange nur endl. Teilmengen referenziert werden (vgl. Streams). 2. Die „innermost”- oder „data-driven” - Strategie: Operationen werden selektiert, wenn alle Argumente verfügbar sind. technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 37 - Vorteile § § § § § § § § § § Programmierung auf höherer Ebene kompakte Programme keine Seiteneffekte kein Aliasing, keine unerwartete Speichermodifikation keine Unterscheidung zwischen call-by-name, call-byvalue und call-by-reference notwendig einfachere Verifikation, da nur Funktionen benutzt werden das von-Neumann-Modell von Speicherzellen und Programmzählern ist überflüssig beliebige Berechnungsreihenfolge für Argumente (außer bei nicht-terminierenden Berechnungen) Debugging einfach: Trace des aktuellen Ausdrucks. Kommerziell bislang nicht erfolgreich technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 38 - Ansätze zur Nutzung von funktionaler Programmierung bei Multi-Core-Prozessoren § Verschiedene funktionale Sprachen § MapReduce (Google): Definition zweier Funktionen: • map: (key,value) → (intermediate key,intermed. value)* • reduce: (intermed. key,value*) → (intermed. key,value) Beispiel: • map: (buchtitel, inhalt) → (wort, 1)* • reduce erhält nach wort sortierte Tupel, zählt Worte und liefert Häufigkeit für ein bestimmtes Wort map und reduce sind Funktionen § CLOJURE: Lisp-Dialekt zur parallelen Programmierung auf der Basis der JVM technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 39 - 2.11 Maschinen zur Realisierung von Logischen Programmiersprachen (1) Direkte Realisierung von logischen Programmiersprachen § Beispiel: PROLOG-Maschinen § Realisierung: PROLOG-Maschinen basieren meist auf der Übersetzung von PROLOG in Warren Abstract Machine- (WAM) Code. § WAM-Realisierung: • WAM von Maschinenprogrammen interpretiert, • WAM-Befehle in Maschinencode übersetzt • WAM in Hardware technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 40 - Maschinen zur Realisierung von Logischen Programmiersprachen (2) Klassen von PROLOG-Maschinen: § Sequentielle Maschinen mit strenger Wahrung der PROLOG-Semantik Leiden meist unter Performanz-Problemen § Parallele Maschinen mit unterschiedlicher Semantik (basieren nicht mehr auf formaler Mathematik) Beispiele von Maschinen: § PRIPs = Entwurf der Projektgruppe PRIPs. § Entwürfe des 5th Generation Projekts. © M. Engel, 2012 Problem: mit Datenmengen zunehmende Inkonsistenzen technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 41 - Weitere Nicht-Von-Neumann-Maschinen: DNA-Rechner § Im DNA-Molekül erfolgt eine Kodierung von Informationen mit 4 verschiedenen Basen. § In einem Liter Flüssigkeit mit 6 g DNA ließen sich theoretisch ca. 3000 Exabyte an Informationen speichern. § Die Rechenleistung läge bei ca. 1015 Operationen/s. § Durch die Parallelverarbeitung könnten theoretisch kryptographische Schlüssel ermittelt werden. § Angeblich wurde ein traveling salesmen –Problem gelöst – nur das Auslesen dauert lange. § Referenz: K.H. Zimmermann, Z. Ignatova, I. MartinezPerez: DNA Computing Models, Springer, 2008 technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 [wikipedia] - 42 - Weitere Nicht-Von-Neumann-Maschinen: Quantenrechner § Überlagerung von 0 und 1 verschiedener Lösungen in 1 Register F parallele Berechnungen möglich. Parallelarbeit führt zu anderen Komplexitäten: - Algorithmus von Shor zur nicht-exponentiellen Faktorisierung auf einem Quantenrechner; Faktorisierung von 143 ist gelungen - Simulation von quantenmechanischen Vorgängen (bekannte Algorithmen sind schneller) - Datenbanksuche (beweisbar O-klassenmäßig schneller) - Berechenbarkeit bleibt unangetastet § Kein Ersatz für klassische Rechner technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 [wikipedia] - 43 - Weitere Nicht-Von-Neumann-Maschinen: Quantenkryptographie § Nutzung quantenmechanischer Effekte, um kryptographische Probleme zu lösen oder um kryptographische Systeme zu überwinden*. Beispiele: • Nutzung von Quantenrechnern, um kryptographische Codes zu knacken F Interesse der NSA an Quantencomputern (Snowden, 2014) • Quantenmechanische Kommunikation: Beobachtung eines Zustandes bewirkt Selektion unter Zuständen Übertragung per Glasfaserkabel z.B. über 250 km° Gedacht v.a. für den Austausch von Schlüsseln * Wikipedia, „Quantum computing“, Abfrage 16.4.2011 ° D Stucki, N Walenta, F Vannel, R T Thew, N Gisin, H Zbinden, S Gray, C R Towery, S Ten: High rate, longdistance quantum key distribution over 250 km of ultra low loss fibres, New Journal of Physics, Vol. 11, 2009 technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 44 - Zusammenfassung § Datenflussprinzip • Systolic arrays • Neuronale Netze • „Echte“ Datenflussmaschinen § Funktionale Programmierung und Reduktionsmaschinen § Realisierung logischer Programmiersprachen § DNA-Computing § Quantum Computing technische universität dortmund fakultät für informatik © marwedel/fink/engel informatik 12, 2015 - 45 -