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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
-1 lesenswert
nicht 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)


Bewertung
1 lesenswert
nicht 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-)


Bewertung
1 lesenswert
nicht 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-)


Bewertung
1 lesenswert
nicht 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 Youtube-Video "Tesla Autonomy Day" 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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-)


Bewertung
1 lesenswert
nicht 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 Youtube-Video "Tesla Autonomy Day" 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-)


Bewertung
0 lesenswert
nicht 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.
Youtube-Video "Tesla Autopilot Neural Net"

Und weil man da beim Gucken viele Details übersieht gibt es auch schon 
Analysen dazu, hier ist eine:
Youtube-Video "Tesla Autopilot is better than you think! Here's why."

Ich finde das sehr beeindruckend und hoffe/wünsche mir doch sehr, dass 
deutsche Autobauer ähnlich weit sind.

von Markus K. (markus-)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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-)


Bewertung
1 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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-)


Bewertung
0 lesenswert
nicht 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-)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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/

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.

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