From 337bcd20d5d5446e568b70374febdf0572bc2a05 Mon Sep 17 00:00:00 2001 From: Leonard Kugis Date: Sun, 8 Jan 2023 21:37:30 +0100 Subject: Finished transcript --- Presentation/transcript.md | 114 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 113 insertions(+), 1 deletion(-) (limited to 'Presentation/transcript.md') 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 -- cgit v1.2.1