Forum: FPGA, VHDL & Co. Deep Learning in GPUs - Addierer oder MACs?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von A. S. (rava)


Lesenswert?

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?

von Beschleunigter Fall (Gast)


Lesenswert?

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

von A. S. (rava)


Lesenswert?

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 ;)

von wer (Gast)


Lesenswert?

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.

von wer (Gast)


Lesenswert?

Das ist übrigens nicht das erste Paper zu genau der Idee, aber ein 
Weiteres ohne Performance Vergleich.

Wars wohl bisher keinem wert.

von Markus K. (markus-)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Christoph Z. (christophz)


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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.

von Axel L. (axel_5)


Lesenswert?

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.

von Markus K. (markus-)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Markus K. (markus-)


Lesenswert?

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.

von Christoph Z. (christophz)


Lesenswert?

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.

von A. S. (rava)


Lesenswert?

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...

von A. S. (rava)


Lesenswert?

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.

von Markus K. (markus-)


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von sergo (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

Jürgen S. schrieb:
> (was kam noch gleich nach "Terra"?)

Nach "Terra" kommt "incognita" ;)

Du meinst "Tera" und da kommt "Peta"...

von Markus K. (markus-)


Lesenswert?

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.

von Markus K. (markus-)


Lesenswert?

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.

von Christoph Z. (christophz)


Lesenswert?

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/

von A. S. (rava)


Lesenswert?

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?

von Markus K. (markus-)


Lesenswert?

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.

von Gustl B. (gustl_b)


Lesenswert?

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.

von Markus K. (markus-)


Lesenswert?

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"

von Gustl B. (gustl_b)


Lesenswert?

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
von Markus K. (markus-)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Markus K. (markus-)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.