summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--Presentation/transcript.md114
1 files changed, 113 insertions, 1 deletions
diff --git a/Presentation/transcript.md b/Presentation/transcript.md
index a6d87bf..513656b 100644
--- a/Presentation/transcript.md
+++ b/Presentation/transcript.md
@@ -177,4 +177,116 @@
- Beispiel: $W_j = [0, 0, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3]$ wird zu $v = [1, 2, 0, 3]$, $z = [2, 0, 15, 2]$
- EIE: $v$'s und $z$'s aller Spalten werden zusammen als ein großes Array-Paar gespeichert, zusammen mit Vektor $p$, wobei $p_j$ ein Zeiger auf das erste Element der Spalte $W_j$ ist
-*nächste Folie* \ No newline at end of file
+*nächste Folie*
+
+## EIE Implementation
+
+- Ziel: Annäherung der Formel für jede Aktivierung $b_i = f(\sum\limits_{j=0}^{n-1} W_{ij} a_j) \overset{!}{=} \text{ReLU}(\sum\limits_{j \in X_i \cap Y} S[I_{ij}] a_j)$ möglichst effizient
+- $X_i$ Menge an Spalten, wobei 0-Einträge ausgelassen werden
+- $Y$ Menge an Einträgen im Inputvektor $a$, die nicht null sind
+- $I_{ij}$ 4-bit Index für die Lookup-Tabelle
+- $S$ Lookup-Tabelle
+
+*nächste Folie*
+
+- Segmentierung der Eingabematrix auf die verschiedenen processing elements
+- Auf dem SRAM-Block in jedem PE ist der für das PE vorgesehene Teil der Spalte $W_j$ gespeichert, jeweils in CSC-Format, mit Zeigern auf das erste Element der jeweiligen Spalte
+- Beispiel: In PE0 sind von Spalte $W_0$ die Elemente $w_{0,0}$, $w_{8,0}$, $w_{12,0}$ in $v$ gespeichert, die Nullen dazwischen für alle Elemente in PE0 in $z$, und die Zeiger die Spaltenanfänge
+- Farbliche Darstellung von $a$ nur Momentaufnahme, geht durchgehend weiter, $a_j$ werden gebroadcastet
+- Jedes PE multipliziert $a_j$ mit den Elementen seiner Zeile und schreibt das Ergebnis in Akkumulator-Register, worin die $b_i$'s gecached und in den SRAM geschrieben werden
+
+*nächste Folie*
+
+- HW Aufbau bestehend aus einem Knoten, der Nullen im Eingabevektor erkennt, und dem eigentlichen Processing Element
+- PEs sind jeweils in 4er-Gruppen aufgeteilt, wobei sich alle 4 PEs eine LNZD-Einheit teilen
+- PE besteht aus Pointer-Read-Unit (Für die Zeiger auf die Spalten), Sparse-Matrix-Access-Unit (Zum Lesen der Gewichtswerte aus der Matrix), Arithmetic Unit (Zur Multiplikation und Addition), und Read/Write-Unit (Puffern und Schreiben der Output-Werte)
+
+*nächste Folie*
+
+- LNZD-Unit
+- Die LNZD-Unit erkennt Nullen im Eingabevektor und überspringt diese
+- Bei nicht-null Werten werden diese zusammen mit dem Index an alle PEs gesendet
+
+*nächste Folie*
+
+- Pointer-Read-Unit
+- Lesen der Zeiger auf Start-Elemente der Spalten $W_j$
+- Elemente sind abwechselnd in zwei verschiedenen SRAM-Banken gespeichert
+- Somit können sie gleichzeitig ausgelesen werden
+
+*nächste Folie*
+
+- Sparse-Matrix-Read-Unit
+- Liest $v$ und $z$ Vektoren für die betreffende Spalte aus, auf Basis der Zeiger
+- Es werden nur 64-Bit Worte gleichzeitig ausgelesen, somit 8 Einträge pro Wort (4 bit Wert, 4 bit Index)
+
+*nächste Folie*
+
+- Arithmetic unit
+- Erhält Vektor $v$ und absoluten Zielregister-Index $x$
+- Berechnet $b_x = b_x + v \cdot a_j$
+- Akkumuliert Index $x$ und berechnet die tatsächliche Zieladresse
+
+*nächste Folie*
+
+- Beinhaltet Input und Output-Werte
+- Puffer für Input- und Output-Werte tauschen Rollen nach jeder Schicht (Output-Werte einer Schicht sind die Input-Werte der nächsten Schicht)
+- Puffer schreibt und liest nach Bedarf in den SRAM
+
+*nächste Folie*
+
+- ReLU und LNZD-Unit
+- Wendet die ReLU-Funktion auf die Output-Werte an
+- Führt lokale LNZD durch, und sendet das Ergebnis an die LNZD-Unit der Gruppe
+
+*nächste Folie*
+
+## Evaluation
+
+*obere Grafik*
+
+- Vergleich der Geschwindigkeit bei Berechnung verschiedener Schichten von verschiedenen Modellen
+- Standardverfahren
+- Alex steht für AlexNet, VGG für VGG-Net (Visual Geometry Group), NT für NeuralTalk
+- Als Datensatz zum testen wird ImageNet benutzt, als Framework das Caffe deep learning framework
+- Maß der Geschwindigkeit: Größe des Datensatzes geteilt durch den höchsten gemessenen Durchsatz, $[\text{Frames}/\text{s}]$
+- Immer nur ein Datensatz (Batch-Size 1), da das System zur Verwendung in Echtzeitszenarien ausgelegt ist
+- 1x ist CPU unkomprimiert
+- EIE ist 189x (Intel Core i7 5930k), 13x (NVIDIA GeForce GTX Titan X), 307x (NVIDIA Tegra K1) so schnell wie CPU, GPU and mGPU für komprimierte DNN
+- Markant ist: Kaum Verbesserung durch Komprimierung auf nicht-dedizierter Hardware (steht in keinem Verhältnis zur EIE, logarithmische Skala)
+- Durchsatz: 102 GOP/s unkomprimiert entsprechen 3 TOP/s komprimiert
+
+*untere Grafik*
+
+- Maß für Energieverbrauch: Durchschnittliche Leistungsaufnahme mal Dauer pro Datensatz, $[\text{Frames}/\text{J}]$
+- 1x ist wieder CPU unkomprimiert
+- EIE ist 24.000x, 3.400x, 2.700x energieeffizienter als CPU, GPU and mGPU
+- Auch hier: Kaum Verbesserung durch Komprimierung auf nicht-dedizierter Hardware
+- Gründe für hohe Effizienz: Zugriff auf SRAM anstatt DRAM, Kompressionsalgorithmus und Architektur reduziert Anzahl der Speicherzugriffe, Kodierung der spärlichen Matrix durch CSC
+
+*nächste Folie*
+
+- Vergleich der EIE mit verschiedenen Hardware-Acceleratoren
+- Modellgröße bei General Purpose Plattformen wie GPUs sehr groß, dafür in allen Effizienz-Parametern unterlegen
+- Auch im Vergleich zu anderen ASIC- und FPGA-Architekturen überlegen
+- A-Eye (FPGA) nutzt DDR3-DRAM für Speicherzugriffe
+- TrueNorth nutzt auch SRAM, aber keine dedizierte Architektur, um komprimierte DNN zu behandeln
+- Da-DianNao ist ASIC mit eingebettetem DRAM (also auf dem selben Chip)
+- Dafür: Unkomprimierte Implementation, nur kleine DNNs mit 18M Parametern
+- EIE besonders in 28nm Strukturbreite mit 256 PEs immer noch 3x so schnell vom Durchsatz und hat bessere Effizienz
+
+*nächste Folie*
+
+## Ausblick
+
+- EIE basiert hauptsächlich auf Algorithmen für die Verarbeitung von komprimierten DNNs, die vorher auf General Purpose Hardware implementiert wurden (GPUs), nur eben als Hardware-Architektur
+- Verschiedene Arten der Optimierung: Komprimierung, Kombination mit anderen (orthogonalen) Optimierungsmethoden, Optimierungen an der Hardware
+- Komprimierung: Huffman-Kodierung (35-49x Komprimierungsfaktor mit Pruning, Quantisierung, Huffman), HashNets (variable Komprimierungsrate bis zu 64x, je nach Anforderung an Präzision)
+- Kombination mit anderen Optimierungsmethoden: In-Memory computation (Berechnung ohne ALU direkt im Speicher), Approximierende Schaltungen (Berechnung mit Aufgabe der Exaktheit)
+- Hardware-Optimierungen: Neue Speichertechnologien (z.B. Memristoren)
+
+*nächste Folie*
+
+Literatur
+
+*Ende* \ No newline at end of file