hi, ich habe vor einigen Tagen ein Paper gefunden, in dem vorgeschlagen wird, CNNs durch reine Additionen zu ersetzen. https://arxiv.org/pdf/1912.13200.pdf Die Autoren zeigen, dass man fast alle Multiplikationen in neuronalen Netzen (in MAC = Multiply-Accumulate) durch reine Additionen ersetzen kann, ohne groß Genauigkeit zu verlieren. Wirkliche Laufzeitmessungen sind derzeit noch schwierig, wegen fehlender Optimierungen. Deswegen wollte ich mal eure Schätzungen abfragen. Ich sehe zwei Effekte: 1. Additionen sind laufzeitmäßig schneller als Multiplikationen, da die Signallaufzeit kürzer ist. In FPGAs ist das sicherlich ausschlaggebend, aber für GPUs konnte ich dazu nichts finden. Dauern Additionen länger als Multiplikationen? Was ist hier ein realistischer Speedup, wenn ich n Additionen und n Multiplikationen durch 2n Additionen ersetzen möchte? 2. Additionen brauchen flächenmäßig weniger Platz auf dem Chip. Wenn also die Hersteller anfangen, Multiplizierer wegzulassen, haben eine größere Zahl an Kernen Platz. Wie viel mehr wäre da drin, nach eurer Einschäzung. Mir ist klar, dass das vom Datentyp abhängt. Typisch im Bereich Deep Learning inferenz sind int8, int16, float16, float32 Seht ihr da große Unterschiede? Intuitiv würde ich schätzen, dass eine float16-Multiplikation einfacher ist als eine int16 Multiplikation. Bei den Additionen ist es umgekehrt. Wäre diese Maßnahme also nur interessant, wenn man sich auf ints beschränkt?
A. S. schrieb: > 1. Additionen sind laufzeitmäßig schneller als Multiplikationen, da > die Signallaufzeit kürzer ist. Nein, die carry chain ist nicht wesentlich länger, geschätzt Faktor 1.41 (Wurzel 2) >2. Additionen brauchen flächenmäßig weniger Platz auf dem Chip. Wenn >also die Hersteller anfangen, Multiplizierer wegzulassen, Das wohlallerdings ist es heute kein problem tausende Multiplizierer in einen FPGA unterzubringen. Ferner ist es nicht nötig, das ein neuronales netz eine Latenz von 1 aufweist, also lässt man die Layer taktweise durchrutschen, anstatt die layer zu parallesieren. Und ohnehin sind KNN lediglich trainierte Idioten, deren Ausgabe durch Harware beschleunigt aber nicht 'richtiger' wird. https://www.heise.de/select/ct/2018/24/1542703490220001
Beschleunigter Fall schrieb: > geschätzt Faktor 1.41 doch, ein Faktor 1.4 wäre schonmal ein Anfang Beschleunigter Fall schrieb: > Das wohlallerdings ist es heute kein problem tausende Multiplizierer in > einen FPGA unterzubringen. und wie viele Addierer könnte man unterbringen, wenn man keine Multiplizierer bräuchte? Ich nehme gerne auch ne Million... Beschleunigter Fall schrieb: > Layer taktweise durchrutschen pipelining könnte man sich dann natürlich sparen. Du sagst also, die Fläche wird bereits gut genutzt? Das stimmt aber nur, wenn Multiplikatoren und Addierer gleich viel Platz brauchen. Hat da jemand Zahlen? Beschleunigter Fall schrieb: > Und ohnehin... ich spreche nicht von Intelligenz. War auch nicht die Frage ;)
A. S. schrieb: > doch, ein Faktor 1.4 wäre schonmal ein Anfang Die bisher gewachsenen Architekturen bei gleichem Ergebnis auf ADD umzustellen würde wohl deutlich länger dauern, als einfach zu warten, bis der Fortschritt der Technik 40% mehr Rechenleistung pro Sekunde/Watt/Euro/m³/kg liefert.
Das ist übrigens nicht das erste Paper zu genau der Idee, aber ein Weiteres ohne Performance Vergleich. Wars wohl bisher keinem wert.
A. S. schrieb: > und wie viele Addierer könnte man unterbringen, wenn man keine > Multiplizierer bräuchte? Vielleicht hilft Dir das als erste Info: https://web.archive.org/web/20141023233409/http://www.andraka.com/multipli.htm https://www.elektronik-kompendium.de/sites/dig/0209031.htm > Ich nehme gerne auch ne Million... Was würdest Du denn damit machen? Typischerweise haben FPGAs zu wenig internes RAM für die Parameter/Zwischenergebnisse des Netzes. Diese Werte kommen also aus einem externen RAM. Du kannst ja mal ausrechnen, welche Datenrate Du bräuchtest und ob HBM2-Speicher dafür schnell genug wäre.
Markus K. schrieb: > Typischerweise haben FPGAs zu wenig internes RAM für die > Parameter/Zwischenergebnisse des Netzes. Und genau da hat Tesla angesetzt. https://en.wikichip.org/wiki/tesla_(car_company)/fsd_chip Mehr Details: https://fuse.wikichip.org/news/2707/inside-teslas-neural-processor-in-the-fsd-chip und hier das Video https://www.youtube.com/watch?v=Ucp0TTmvqOE beginnt bei ca. 1h 12m Vor allem die Speicherbandbreite ist gigantisch. 256Byte + 128Byte werden je Cycle (was auch immer das ist) gelesen. 786 GB/s und zwar auf SRAM, also nicht HBM2 mit DRAM und Latenz das nur wirklich schnell ist wenn man viel am Stück liest. Man kann auf den Bildern auch schön erkennen, dass das MAC Array im vergleich zum SRAM eher wenig Platz braucht und selbst die Anbindung vom SRAM braucht mehr Platz wie das MAC Array selbst.
Generell muss hier in der Diskussion unterschieden werden, wo es implementiert werden soll. Von GPU Architekturen habe ich leider auch keine Ahnung. In FPGAs sind seit Jahren schnelle Multiplizierer bzw. MAC Einheiten drin, wieso also nicht nutzen. Die ganzen NN-Beschleuniger laufen aber bei den grossen Firmen in Custom-ASICs und da zahlt man ja pro Transistor bzw. pro Fläche. Denke für Massen-(Consum/Auto)-Markt macht das einen grossen Unterschied, wenn man die Multiplikatoren ganz weglassen könnte oder auch nur schon in Teilen vom Netzwerk. A. S. schrieb: > 2. Additionen brauchen flächenmäßig weniger Platz auf dem Chip. Wenn > also die Hersteller anfangen, Multiplizierer wegzulassen, haben eine > größere Zahl an Kernen Platz. Wie viel mehr wäre da drin, nach eurer > Einschäzung. Ja, deine Einschätzung ist richtig. Ein 1 Zyklus Addierer ist viel kleiner als ein 1 Zyklus Multiplizierer. Habe aber keine Erfahrung mit den effektiven Transistor-counts von schnellen Addierern (z. B. carry-look ahead) verglichen zu schnellen Multiplizierern (z. B. barrel-multiplier) und wie viel höher die Taktfrequenz dann des Addierers ist im Vergleich. > Mir ist klar, dass das vom Datentyp abhängt. Typisch im Bereich Deep > Learning inferenz sind int8, int16, float16, float32 > Seht ihr da große Unterschiede? Intuitiv würde ich schätzen, dass eine > float16-Multiplikation einfacher ist als eine int16 Multiplikation. Bei > den Additionen ist es umgekehrt. Wäre diese Maßnahme also nur > interessant, wenn man sich auf ints beschränkt? Float-Rechenwerke sind immer viel aufwändiger als Integer Rechenwerke. Darum gab es früher (TM) die FPU ja als separaten Chip zu kaufen für deinen PC, FPGAs mit Float zu nutzen ist immer noch verpönt und selten anzutreffen und man sieht es auch wenn man die Preise vergleicht von Fix-point zu Floating point DSPs.
Markus K. schrieb: > Was würdest Du denn damit machen? > Typischerweise haben FPGAs zu wenig internes RAM für die > Parameter/Zwischenergebnisse des Netzes. Diese Werte kommen also aus > einem externen RAM. Du kannst ja mal ausrechnen, welche Datenrate Du > bräuchtest und ob HBM2-Speicher dafür schnell genug wäre. Kommt auf das FPGA an, aber bei den Klassikern ist das BRAM einfach 'schlecht' verteilt, um die NN optimal dicht plazieren/routen zu koennen. Andere Implementierungen arbeiten gar nicht mit DSP multipliern, da reichen 4-6 bit. Ansonsten ist das Ding mit Addition nicht neu, gibt auch einige interessante Dithering-Ansaetze, die ohne teure Multiplikation aehnlich gut performen. Latenz ist dann nicht so ein Thema. Und das Thema uebrigens schon 20 Jahre alt.. Lattice Semi hat ein paar pfiffige Implementierungen am Laufen, wie sie's mit den Tools hinkriegen, ist mir allerdings unbekannt. Ansonsten hat Renesas ein paar anstaendig gereifte Kaefer, die erstaunlich gute Objektklassifizierung hinkriegen. Konnte man auch regelmaessig an der Embedded World begutachten, frei von Marketing bullshit. Schlussendlich ist wohl die grosse Krux fuer unsereiner die Werkzeuge, denn in klassischer HDL will man keine CNN designen.
Beschleunigter Fall schrieb: > A. S. schrieb: >> 1. Additionen sind laufzeitmäßig schneller als Multiplikationen, da >> die Signallaufzeit kürzer ist. > > Nein, die carry chain ist nicht wesentlich länger, geschätzt Faktor 1.41 > (Wurzel 2) > 40% wäre ja schon ganz ordentlich. >>2. Additionen brauchen flächenmäßig weniger Platz auf dem Chip. Wenn >>also die Hersteller anfangen, Multiplizierer wegzulassen, > > Das wohlallerdings ist es heute kein problem tausende Multiplizierer in > einen FPGA unterzubringen. Ein Multilplizierer ist dramatisch grösser als ein Addierer. Dazu kommt, dass die Laufzeiten vor allem von der Fläche abhängt, der Addierer ist als 40% schneller wegen der Logik und nochmal 50% aufgrund der geringeren Grösse.
Gustl B. schrieb: > Markus K. schrieb: >> Typischerweise haben FPGAs zu wenig internes RAM für die >> Parameter/Zwischenergebnisse des Netzes. > > Und genau da hat Tesla angesetzt. > https://en.wikichip.org/wiki/tesla_(car_company)/fsd_chip Danke für die Info. 20MB SRAM (bzw. eigentlich ja 40MB) onchip findet man selten. Ich kann nur nicht so richtig einschätzen, ob das reicht. So ein SSD-Mobilenet V2 hat 15 Mio Parameter, da scheinen mir 20MB RAM nicht so extrem viel zu sein. > und hier das Video https://www.youtube.com/watch?v=Ucp0TTmvqOE beginnt > bei ca. 1h 12m Sehr interessant und mit vielen Details. Insbesondere gibt es bei 1:26:47 eine schöne Aufstellung vom Energieverbrauch pro Rechenoperation. Integer: Add 8Bit: 0.03pJ Add 32Bit: 0.10pJ Mul 8Bit: 0.20pJ Mul 32Bit: 3.00pJ Floating Point: Add 16Bit: 0.40pJ Add 32Bit: 0.90pJ Mul 16Bit: 1.00pJ Mul 32Bit: 4.00pJ Wenn man jetzt mal annimmt, dass der Energieverbrauch linear mit der Anzahl Transistoren steigt, dann kann man damit schön umrechnen: Das wäre dann bei 8Bit Integer etwa die 6-7fache Anzahl an Transistoren für Mul vs Add. > Vor allem die Speicherbandbreite ist gigantisch. 256Byte + 128Byte > werden je Cycle (was auch immer das ist) gelesen. 786 GB/s und zwar auf > SRAM, Ja, schon beindruckend. Aber man stelle sich mal vor, die Recheneinheiten wären deutlich umfangreicher. Wenn das - wie weiter im Thread gewünscht - 1 Mio Einheiten wären, dann hätten die eben auch den 100fachen Bedarf an Bandbreite. > also nicht HBM2 mit DRAM und Latenz das nur wirklich schnell ist > wenn man viel am Stück liest. Gerade bei einem NN kann man aber die Zugriffsmuster vorhersagen und in gewissem Rahmen auch festlegen. In dem Video erzählt er ja auch, dass ihr NN-Compiler SRAM-Bänke berücksichtigt.
Markus K. schrieb: > Aber man stelle sich mal vor, die Recheneinheiten wären deutlich > umfangreicher. Wenn das - wie weiter im Thread gewünscht - 1 Mio > Einheiten wären, dann hätten die eben auch den 100fachen Bedarf an > Bandbreite. Das wird eine Abwägung sein. Im Auto darf man nicht irre Strom ziehen und man muss das auch kühlen. Und vielleicht ist es schlicht gut genug. Markus K. schrieb: > Gerade bei einem NN kann man aber die Zugriffsmuster vorhersagen und in > gewissem Rahmen auch festlegen. In dem Video erzählt er ja auch, dass > ihr NN-Compiler SRAM-Bänke berücksichtigt. Ah ok, danke. Ich kenne mich da nicht aus und bin leicht zu beeindrucken (-: Noch was zu Tesla: Da gab es vor ein paar Tagen dieses Video das leider nur eine recht geringe Auflösung hat. https://www.youtube.com/watch?v=5FITJg4KlMc Und weil man da beim Gucken viele Details übersieht gibt es auch schon Analysen dazu, hier ist eine: https://www.youtube.com/watch?v=zRnSmw1i_DQ Ich finde das sehr beeindruckend und hoffe/wünsche mir doch sehr, dass deutsche Autobauer ähnlich weit sind.
Martin S. schrieb: > Markus K. schrieb: >> Was würdest Du denn damit machen? >> Typischerweise haben FPGAs zu wenig internes RAM für die >> Parameter/Zwischenergebnisse des Netzes. Diese Werte kommen also aus >> einem externen RAM. Du kannst ja mal ausrechnen, welche Datenrate Du >> bräuchtest und ob HBM2-Speicher dafür schnell genug wäre. > > Kommt auf das FPGA an, aber bei den Klassikern ist das BRAM einfach > 'schlecht' verteilt, um die NN optimal dicht plazieren/routen zu > koennen. Bei Xilinx bedeutet NN zur Zeit etwa max 4MB Blockram und das sind bereits die relativ großen Modell (z.B. Zynq Ultrascale ZU9). Sind bei 8Bit pro Parameter also 4 Mio Parameter. Man würde also viele Netze da gar nicht reinbekommen -> man braucht also doch externen Speicher. Klar kann man die Parameter auch noch kleiner machen, aber 8Bit sind schon nicht so völlig problemlos. > Ansonsten hat Renesas ein paar anstaendig gereifte Kaefer, die > erstaunlich gute Objektklassifizierung hinkriegen. Konnte man auch > regelmaessig an der Embedded World begutachten, frei von Marketing > bullshit. Natürlich gabs auch schon vor dem NN-Hype Fußgängererkennung und so. Laut den Experten sind die NN aber viel besser bei sowas. > Schlussendlich ist wohl die grosse Krux fuer unsereiner die Werkzeuge, > denn in klassischer HDL will man keine CNN designen. Xilinxs DPU ist ja auch nur so eine Art Prozessor für NN. Ich hätte aber schon gehofft, dass man da hinterher (wenn man sich auf ein Netz festgelegt hat) das händisch implementieren kann.
Markus K. schrieb: > Ich hätte aber > schon gehofft, dass man da hinterher (wenn man sich auf ein Netz > festgelegt hat) das händisch implementieren kann. Ja, händisch implementieren wollen wir das schon, aber nicht mit VHDL/Verilog :-) Ein NN besteht ja aus sehr regelmässigen Strukturen bzw. eine Handvoll bekannter Bauweisen, die möchte man mit relativ wenig Code implementieren und für die Anwendung optimieren können. Kling nach Bedarf für eine Domain-Specific-Language die dann hinten wieder (wohl ziemlich langen) VHDL/Verilog Code ausgibt. Das sind ahnliche Bedürfnisse wie in anderen Bereichen der Signalverarbeitung (Regelungstechnik, Bildverarbeitung, digitale Filter), wo es verschiedene (bessere und schlechtere) Werkzeuge gibt um die Enwickler zu unterstützen bzw. Prototyping/Benchmarking zu beschleunigen.
Markus K. schrieb: > Wenn das - wie weiter im Thread gewünscht - 1 Mio > Einheiten wären das war nur so dahingeredet, weil der Schreiber die Diskussion zu früh zerlegen wollte. Die Vergangenheit hat gezeigt, dass verfügbare Recheneinheiten früher oder später auch genutzt werden. Das "brauchen wir nicht" brauch ich nicht. Markus K. schrieb: > Laut den Experten sind die NN aber viel besser bei sowas. Sind sie. Stell dich vor so einem Ding auf ein Bein, setz dich auf einen (Roll)stuhl, heb die Arme und schau, was es noch erkennt. Ich fürchte die deutschen Autobauer sind da im Schnitt ein wenig hinter den Amerikanischen Kollegen im Rückstand. Aber genau wissen tu ich's natürlich auch nicht. Haben nicht ausschließlich Tesla (und vermutlich Waymo) eigene ECUs dafür gemacht? Benutzen nicht die meisten anderen einfach NVidia Kisten? Das ist doch schonmal ein deutliches Zeichen, oder? Markus K. schrieb: > Ich kann nur nicht so richtig einschätzen, ob das reicht. So ein > SSD-Mobilenet V2 hat 15 Mio Parameter, da scheinen mir 20MB RAM nicht so > extrem viel zu sein. das reicht bestimmt nicht für das ganze Netz, gerade da auch noch Zwischenergebnisse und I/O Daten gespeichert werden müssen. Aber ich kann mir vorstellen, dass man damit eine ganz brauchbare Pipeline aufbauen kann, auch wenn man nebenher von außen rankopieren muss. Mich wundert zwar, das eine optimierte SSD-Variante so groß sein soll, aber selbst wenn nicht Das Tesla-Ding tut ja noch viel mehr als nur Objekte erkennen...
wer schrieb: > Das ist übrigens nicht das erste Paper zu genau der Idee, aber ein > Weiteres ohne Performance Vergleich. upsa, ganz übersehen. Die Autoren argumentieren zurecht, dass der Vergleich nicht möglich ist, denn man müsste ja erstmal einen ASIC dafür bauen, um die Laufzeiten messen zu können. Wäre aber trotzdem interessiert, welche anderen Paper du zu dem Thema empfehlen kannst. Vielleicht mache ich mal eine Gegenüberstellung.
Zu den FPGA-Größen nochmal: Ich bin nicht sicher, ob es die Xilinx Versal schon zu kaufen gibt, aber die haben deutlich mehr RAM und NN-Performance. Der große VC1902 hat 12.5MB "AI Engine Data Memory" und 11.3MB sonstiges SRAM (Distributed/Block/Ultra). Die "AI Engine Peak SRAM Bandwidth" liegt bei 66TB/s, während das klassische SRAM nur eine Gesamtbandbreite von 23.5TB/s hat. Die Peak Rechenleitung für Int8 liegt bei 133TOPS (also doppelt so viel wie die beiden NN-Einheiten in dem Tesla zusammen haben). Diese Peak-Performance-Angaben erinnern mich immer etwas an die PMPO-Angaben bei den PC-Lautsprechern, aber was anderes haben wir hier ja nicht. A. S. schrieb: > Mich wundert zwar, das eine optimierte SSD-Variante so groß sein soll, Quelle (in grauer Schrift unterhalb des ersten Absatzes) für die 15Mio Parameter: https://resources.wolframcloud.com/NeuralNetRepository/resources/SSD-MobileNet-V2-Trained-on-MS-COCO-Data Hier (Abschnitt 4.2) steht dagegen, dass SSD 14.8M Parameter habe und SSDLite 2.1M Parameter. Damit kommen Mobilenet V2 + SSDLite auf 4.3M Parameter. https://towardsdatascience.com/review-mobilenetv2-light-weight-model-image-classification-8febb490e61c Damit scheinen die 15 Mio Parameter zwar an sich korrekt, aber ob man das so benutzen würde kann ich nicht sagen.
Gustl B. schrieb: > 786 GB/s und zwar auf SRAM Solange das 'en bloc' ist oder extern, kommt man da nicht groß weiter. Wichtiger wäre, die Architektur dahingehend aufzubohren, dass es mehr Register-RAM gibt und zwar dezentral dort, wo die Daten entstehen und weiterverarbeitet werden. Dann können insbesondere die Teile, die als pipeline arbeiten, sehr effektiv mit dem Speicher umgehen, weil es mehrfach gelesen werden kann und mit voller Bandbreite arbeitet. Als Beispiel nehme ich immer meinen Synthie her, der komplett als pipe läuft und bei dem allemöglichen Daten in Registern liegen. Wenn ich nur die minimal benötigten FFs nehme, die nicht deshalb drin sind, um das timing zu treffen, sondern wirklich Werte speichern, komme ich bei dem Artix 200 und rund 100.000 beteiligten Registerzellen auf 20.000 Gbps. Da sie gleichzeitig geschrieben und gelesen werden, es oftmals ein Mehrfachlesen, Rückschauen in der Zeit und bei IIR-Filtern eine Mehrfachverwendung als Rechengröße und Parameter gibt, werden viele Register 2-3 fach benutzt. In Bytes umgerechnet entspricht das einer Bandbreite von 7500 GBps, also dem Zehnfachen des Wertes von oben. Wollte man die Funktion mit einem CPU-System abbilden, müssten diese Lese-und Speicheraktionen alle sequentiell über das externe RAM laufen, was noch mehr Bandbreite erfordert, wegen Dynamik und dem gleichzeitigen Zugriff mehrerer Teilnehmer. Bei den BRAMs sind es noch extremer aus. Mein fast 10 Jahre altes Spartan 6 75 hatte über 100GB/s. Man bräuchte die Bandbreite von etwa 20-30 DDR3-Controllern eines Intel-Prozessors, jenachdem welche Funktion man realisert und wieviel davon gecached und optimiert werden kann. Ganz zu schweigen von heutigen FPGAs: Ein gut ausgebauter Kintex kommt allein mit den BRAMs auf etwa 5.000 TBps! (was kam noch gleich nach "Terra"?) Auf die GPUs übertragen heisst das, dass die einzelnen Blöckchen vorort mehr eigenes RAM brauchen also z.B. 128 parallel beschreibare 32-Bit-Register, die man kaskadieren oder parallelisieren kann, um 256Bit-Register zu haben und nochmal ein weiteres RAM an den Grenzen, die per Bus auch unterschiedlichen Zellen schlagartig zugänglich gemacht werden können. Dann entfällt die Laderei und Speicherei, um Zwischenergebnisse zwischen Knoten zu transportieren. Ich hatte das ansatzweise hier mal synthetisch aufgezogen: http://www.96khz.org/htm/scalableaudiodsp.htm Markus K. schrieb: > Der große VC1902 hat 12.5MB "AI Engine Data Memory" und > 11.3MB sonstiges SRAM (Distributed/Block/Ultra). Die Kintexe kommen da auch schon zu 50% hin.
Was war oder ist eigentlich die ursprüngliche Idee hinter der Trennung zwischen Recheneinheiten und Speichereinheiten? Ist das also einfach so gewachsen oder gibt es gute Gründe dafür Operations und Speichereinheiten räumlich zu trennen? In der Evolution ist es entweder einfach nie zufällig passiert oder es gibt keinen Vorteil für eine räumlich starke Trennung zwischen Operations und Speichereinheiten.
Jürgen S. schrieb: > (was kam noch gleich nach "Terra"?) Nach "Terra" kommt "incognita" ;) Du meinst "Tera" und da kommt "Peta"...
Jürgen S. schrieb: > Gustl B. schrieb: >> 786 GB/s und zwar auf SRAM > Solange das 'en bloc' ist oder extern, kommt man da nicht groß weiter. > Wichtiger wäre, die Architektur dahingehend aufzubohren, dass es mehr > Register-RAM gibt und zwar dezentral dort, wo die Daten entstehen und > weiterverarbeitet werden. Aktuell haben FPGAs einfach zu wenig Multiplizierer. Man muss sie also mehrfach benutzen. Netze gibt es natürlich in allen Größen und Formen, aber Faktor 1000 oder 10000 scheint nicht unüblich zu sein, also z.B. (willkürlich gewählt) 1000 Multiplizierer und 4 Mio Gewichte = Faktor 4000. Dann hat man im Mittel 4KB Daten (bei 8bit Gewichten) pro Multiplizierer. Also 1 Blockram pro Multiplizierer. Ich nehme an, das ist schnell genug dafür. Man braucht natürlich dann auch 1000 Blockrams. Der nächste Punkt ist, dass das z.Zt. automatisch umgesetzt wird. Man entwickelt sein Netz zB mit Tensorflow und der Compiler setzt das dann automatisch auf den FPGA um. Das ist mit etwas CPU-artigem wahrscheinlich einfacher.
sergo schrieb: > Was war oder ist eigentlich die ursprüngliche Idee hinter der Trennung > zwischen Recheneinheiten und Speichereinheiten? > Ist das also einfach so gewachsen oder gibt es gute Gründe dafür > Operations und Speichereinheiten räumlich zu trennen? Die Hardware hat typischerweise zu wenig Ressourcen, so dass man sie mehrfach benutzen muss. Also zu wenig Recheneinheiten und zu wenig internes RAM. Anderseits ist die Hardware sehr schnell. Wenn das gesamte Netz gleichzeitig in Hardware vorliegt, dann könnte man ja Objekterkennung in unter 1µs machen. Dafür gibts wohl nicht so viele Anwendungen. > In der Evolution ist es entweder einfach nie zufällig passiert Genau. Es muss ja schließlich einen Weg dahin geben. Wie viele Kaninchen muss man in den Vulkan werfen, bis sie feuerfest werden? > oder es > gibt keinen Vorteil für eine räumlich starke Trennung zwischen > Operations und Speichereinheiten. Das kommt halt auf die Ressourcenlage an. Im Gehirn hat man langsame Datenleitungen aber es ist billig, die Gewichte anzuwenden. Das ist aber auch langsam. In der Elektronik ist es halt andersrum: Datenleitungen und Multiplizierer sind schnell, aber nur in begrenzter Anzahl verfügbar.
sergo schrieb: > Was war oder ist eigentlich die ursprüngliche Idee hinter der Trennung > zwischen Recheneinheiten und Speichereinheiten? > Ist das also einfach so gewachsen oder gibt es gute Gründe dafür > Operations und Speichereinheiten räumlich zu trennen? Fabrikationsprozesse von Silizium Chips. Ganz früher, konnten noch gar nicht genug Transistoren auf einen Chip gepackt werden, da bestand eine CPU noch aus zig separaten Chips (Darum war der i4004 damals so Medienwirksam). Es gibt für jeden Typ Anwendung spezielle Prozesse, die darauf optimiert sind. Z. B. möglichst viel speicher pro Fläche, was sowieso DRAM bedeutet. Da steht die Siliziumgitterstruktur schon mal 60°(?) anders herum (Trench DRAM), als es für Logikprozesse genutzt wird. Für Flash und Analog gibt es auch spezialisierte Prozesse und solche die alles können, aber halt nicht für alles optimal sind. Darum gibt es keine 3 GHz CPU mit eingebautem Flash und ADC. Jürgen S. schrieb: > Solange das 'en bloc' ist oder extern, kommt man da nicht groß weiter. > Wichtiger wäre, die Architektur dahingehend aufzubohren, dass es mehr > Register-RAM gibt und zwar dezentral dort, wo die Daten entstehen und > weiterverarbeitet werden. Ja, ist ja auch seit längerem als Trend bei den Start-ups zu beobachten. Scheint mir aber das übliche Problem zu sein, dass bestehende Entwickler/Tools nicht mehr nutzbar sind und das ganze wieder verschwindet obwohl technisch sinnvoll. Mathstar war sowas, das ich interessant fand. Auch Micron hatte da mal was spannendes angefangen, jetzt findet man nichts mehr dazu auf ihrer eigenen Webseite, nur noch anderswo: https://thememoryguy.com/micron-announces-processor-in-memory/
Markus K. schrieb: > Aktuell haben FPGAs einfach zu wenig Multiplizierer. Man muss sie also > mehrfach benutzen. Markus K. schrieb: > Die Hardware hat typischerweise zu wenig Ressourcen, so dass man sie > mehrfach benutzen muss. ich muss gestehen, bei den FPGA-Diskussionen bin ich etwas verloren. Das war ja auch nicht mein ursprünglicher Fokus mit der Frage. Um trotzdem etwas beizutragen: Gerade dreht sich die Argumentation darum, dass es zu wenig Recheneinheiten gibt. Das würde mein ursprüngliches Argument ja stützen: "Addierer sind viel kleiner und somit kann man mehr davon in das Gerät bauen". Das löst aber das Speicherproblem noch nicht. Und auch wenn das aus der Diskussion nicht ganz klar ist, habe ich schon das Gefühl, dass hier das Hauptproblem liegt - auch in FPGAs, oder? Vermutlich muss man auf die genaue Aufgabenstellung schauen. Also welche Form haben die Daten, wie groß sind die Inputs, etc. ConvNets werden ja in der Regel breadth-first gerechnet, also layer für layer. Und dafür braucht man schon eher zusammenhängende Speicherblöcke, oder? Offensichtlich sind wir hier gerade an der Stelle im Designspace, wo nicht von vornherein klar ist, was das bottleneck ist? Und es klingt auch nicht so, als hätten die AdderNets so viel Einfluss, dass wir uns ganz klar in den Bereich bringen können, wo es nur noch um schnellen Speicher geht, oder?
A. S. schrieb: > Um trotzdem etwas beizutragen: Gerade dreht sich die Argumentation > darum, dass es zu wenig Recheneinheiten gibt. Das würde mein > ursprüngliches Argument ja stützen: > "Addierer sind viel kleiner und somit kann man mehr davon in das Gerät > bauen". Ja, genau. > Das löst aber das Speicherproblem noch nicht. Und auch wenn das aus der > Diskussion nicht ganz klar ist, habe ich schon das Gefühl, dass hier das > Hauptproblem liegt - auch in FPGAs, oder? Nicht unbedingt. Die Netze im Zynq Ultrascale ZU9EG machen laut pg338-dpu.pdf (I/O Bandwidth Requirements, max 3xB4096) eine durchschnittliche Last von 6-9GB/s (Peak 15-20GB/S). Mit 64Bit DDR4-2400 bekommt man Brutto etwa 19GB/s. Da wäre also schon noch etwas Luft. Die Last der Netze hat Xilinx examplarisch für 4 Netze angegeben. Es ist natürlich gut möglich, dass andere Netze sich da ganz anders verhalten. An der Stelle muss aber man auch berücksichtigen, dass ein großer FPGA eher teuer ist. Bei Digikey ist der FPGA mit 2500€ für Einzelstückzahlen gelistet. Selbst wenn man bei größeren Stückzahlen nur 10% davon zahlt sind das immer noch 250€. Wenn man aber einen kleineren FPGA nimmt, dann läuft das Netz dort aber auch deutlich langsamer. So ein ZU2EG hat nur 10% der theoretischen Peakrechenleistung des ZU9EG. Damit sinken natürlich auch die Ansprüche an die Speicherbandbreite massiv. Wenn man da Multiplikationen durch Additionen ersetzen könnte, dann könnte man das Netz wahrscheinlich schon deutlich schneller machen. > Vermutlich muss man auf die genaue Aufgabenstellung schauen. Also welche > Form haben die Daten, wie groß sind die Inputs, etc. ConvNets werden ja > in der Regel breadth-first gerechnet, also layer für layer. Und dafür > braucht man schon eher zusammenhängende Speicherblöcke, oder? Ich bin automatisch davon ausgegangen, dass da immer ein Layer nach dem anderen gerechnet wird. Wenn man fully connected layer hat würde man ja sonst nicht glücklich werden. Bei Teslas NN wurden die 8 Befehle im Vortrag vorgestellt und statt normaler Load+Stores hat sie DMA-Transfers. Das deutet ja schon deutlich darauf hin, dass man typischerweise Blocktransfers macht. > Offensichtlich sind wir hier gerade an der Stelle im Designspace, wo > nicht von vornherein klar ist, was das bottleneck ist? Mir scheint, für Objekterkennung in einem kleinen Gerät sind die Recheneinheiten das Bottleneck. Es gibt aber natürlich noch viele andere Anwendungsfälle. "Designspace" klingt dabei so, als ob man da völlig frei die Möglichkeiten ausschöpfen würde. Ich glaube aber, die meisten Anwender nehmen einfach nur fertige Netze und wandeln die vielleicht noch etwas ab. > Und es klingt auch nicht so, als hätten die AdderNets so viel Einfluss, > dass wir uns ganz klar in den Bereich bringen können, wo es nur noch um > schnellen Speicher geht, oder? Ich habe das Paper nicht gelesen, aber es sollte klar sein, dass selbst die Beschränkung auf Int8-MULs nicht problemlos ist, denn sonst würde ja keiner mehr was anderes verwenden.
Markus K. schrieb: > Die Netze im Zynq Ultrascale ZU9EG machen laut pg338-dpu.pdf (I/O > Bandwidth Requirements, max 3xB4096) eine durchschnittliche Last von > 6-9GB/s (Peak 15-20GB/S). Wie kommst du auf diese Datenraten? Der hat 912 BRAMs mit je 36 kBit. Von denen kann jedes 64 Bit Breite (ohne das ECC Bit). Sind also 912*64/8=7296 Byte Breite. Wie schnell kann man das so takten? Nehmen wir mal moderate 300 MHz dann sind wir bei 2188800 MByte/s oder 2,1888 TByte/s.
Gustl B. schrieb: > Markus K. schrieb: >> Die Netze im Zynq Ultrascale ZU9EG machen laut pg338-dpu.pdf (I/O >> Bandwidth Requirements, max 3xB4096) eine durchschnittliche Last von >> 6-9GB/s (Peak 15-20GB/S). > > Wie kommst du auf diese Datenraten? Wie ich bereits geschrieben habe: Das steht so im pg338-dpu.pdf von Xilinx. https://www.xilinx.com/support/documentation/ip_documentation/dpu/v3_1/pg338-dpu.pdf Kapitel I/O Bandwidth Requirements. In der aktuellen Version (3.1) steht das auf Seite 31. In den ZU9EG passen maximal 3x B4096 rein, also muss man noch die Werte aus der Tabelle mit 3 Multiplizieren. "The I/O bandwidth is mainly used for accessing data though the AXI master interfaces"
Ah OK, ja gut, das ist dann wohl die Bandbreite zwischen den ARM Kernen und dem FPGA. Edit: Ne auch das nicht. Naja ... vielleicht limitieren da ja die Multiplizierer und nicht die BRAM Bandbreite.
:
Bearbeitet durch User
Gustl B. schrieb: > Ah OK, ja gut, das ist dann wohl die Bandbreite zwischen den ARM Kernen > und dem FPGA. > > Edit: > Ne auch das nicht. Naja ... vielleicht limitieren da ja die > Multiplizierer und nicht die BRAM Bandbreite. Ich denke, das BRAM ist einfach zu klein. Wie weiter oben erwähnt hat z.B. ein Mobilenet V2 + SSDLite 4,3Mio Parameter. Sind bei 8Bit Gewichten also 4.3MB. Dazu kommen noch die Zwischenergebnisse und außerdem noch die Netzstruktur. Das passt also selbst beim ZU9 nicht in die BRAMs rein und natürlich sowieso nicht bei den kleineren Modellen. Außerdem will man mit dem FPGA vielleicht noch etwas anderes machen als nur das NN rechnen, also sollte man auch noch Resourcen für andere Anwendungen übrig lassen. Man muss die Werte also im externen DDR-RAM halten. Dazu müssen sie über den Bus.
Markus K. schrieb: > Wenn man aber einen kleineren FPGA nimmt, dann > läuft das Netz dort aber auch deutlich langsamer. Meine Erfahrung ist da eher umgekehrt. Je kleiner das FPGA, desto schneller läuft das Design, weil die Routingwege zwangsweise kürzer werden... Duke
Duke Scarring schrieb: > Markus K. schrieb: >> Wenn man aber einen kleineren FPGA nimmt, dann >> läuft das Netz dort aber auch deutlich langsamer. > Meine Erfahrung ist da eher umgekehrt. Je kleiner das FPGA, desto > schneller läuft das Design, weil die Routingwege zwangsweise kürzer > werden... Ja, der Effekt scheint hier etwa 10% auszumachen. Auf den kleinen Chips läuft das mit 370MHz, auf den großen nur mit 333Mhz. Allerdings haben die großen Chips auch die 10fache Menge an Ressourcen, was den Effekt mehr als aufwiegt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.