Archiv verlassen und diese Seite im Standarddesign anzeigen : 1024-core 70 GFLOP/W Floating Point Manycore Microprocessor
Godmode
2012-03-20, 14:13:13
Interessante CPU, ka ob mit GK110 vergleichbar: http://www.adapteva.com/images/stories/papers/adapteva_hpec11.pdf
AnarchX
2012-03-20, 14:16:23
... verschoben, da es überhaupt nichts mit Nvidia oder GK110 zu tun hat.
Skysnake
2012-03-20, 14:20:40
Das ist sozusagen ein Cluster on Chip mit einem Grid Interconnect.
Die Dinger gibts schon ne weile in der einen oder anderen Form. Gibt eigentlich nur 3 Probleme:
1. Du hast wenig Cache/Core
2. Die ganzen Cores müssen sich die Speicherbandbreite teilen :ugly:
3. Um so weiter Cores innen sind, um so höher werden die Latenzen zum Speicher, und desto eher hungern diese aus, weil der IC voll belegt ist von den äußeren Cores.
Bei Applikationen, die fast keine Daten haben, damit aber rechnen wie blöd ist das super, für Applikationen die aber Bandbreite brauchen ist es der Tod.
Mit so was kannste eher wie mit nem FPGA/StreamProzessor arbeiten, der nacheinander gewisse Aufgaben abarbeitet und auf der einen Seite die Daten rein geprügelt werden und auf der anderen halt wieder raus kommen.
Für mich sind die Dinger durch die kleinen Caches/Bandbreitenlimitierung aber nur extreme Nieschenlösungen, die sich dann gegen FPGAs behaupten müssen.
Godmode
2012-03-20, 14:33:08
... verschoben, da es überhaupt nichts mit Nvidia oder GK110 zu tun hat.
Danke!
Das ist sozusagen ein Cluster on Chip mit einem Grid Interconnect.
Die Dinger gibts schon ne weile in der einen oder anderen Form. Gibt eigentlich nur 3 Probleme:
1. Du hast wenig Cache/Core
2. Die ganzen Cores müssen sich die Speicherbandbreite teilen :ugly:
3. Um so weiter Cores innen sind, um so höher werden die Latenzen zum Speicher, und desto eher hungern diese aus, weil der IC voll belegt ist von den äußeren Cores.
Bei Applikationen, die fast keine Daten haben, damit aber rechnen wie blöd ist das super, für Applikationen die aber Bandbreite brauchen ist es der Tod.
Mit so was kannste eher wie mit nem FPGA/StreamProzessor arbeiten, der nacheinander gewisse Aufgaben abarbeitet und auf der einen Seite die Daten rein geprügelt werden und auf der anderen halt wieder raus kommen.
Für mich sind die Dinger durch die kleinen Caches/Bandbreitenlimitierung aber nur extreme Nieschenlösungen, die sich dann gegen FPGAs behaupten müssen.
Habe die 70 GFlop/s/W beeindruckend gefunden, aber die sind dann wohl nur theoretischer Natur, bzw. nur bei sehr speziellen Aufgaben erreichbar (FFT, SGEMM).
Nighthawk13
2012-03-20, 14:56:24
Keine Wurzel/Division und Nichteinhaltung des float-Standards machen das Teil für wissenschaftliche Berechnungen eher unbrauchbar.
Schade, mit Divider wäre das Teil evtl. für Raytracing interessant(Mit der Speicheranbindung zu haushalten wäre die Herausforderung für den Programmierer).
Skysnake
2012-03-20, 15:50:53
Danke!
Habe die 70 GFlop/s/W beeindruckend gefunden, aber die sind dann wohl nur theoretischer Natur, bzw. nur bei sehr speziellen Aufgaben erreichbar (FFT, SGEMM).
SGEMM eben nicht. Weiste wie Bandbreitenhungrig das Ding ist? :ugly: Selbst DGEMM wird auf GPUs durch die Bandbreite des Speichers limitiert.
Da musste also schon schwerere Geschütze auffahren, wo deutlich mehr gerechnet wird je Speicherzugriff.
Keine Wurzel/Division und Nichteinhaltung des float-Standards machen das Teil für wissenschaftliche Berechnungen eher unbrauchbar.
Schade, mit Divider wäre das Teil evtl. für Raytracing interessant(Mit der Speicheranbindung zu haushalten wäre die Herausforderung für den Programmierer).
Wenn dein Problem eine gewisse Granularität hat, dann kannste daran nichts ändern...
Ist ja nicht so, als ob man da nicht eh schon immer drauf optimiert... :rolleyes:
Godmode
2012-03-20, 15:57:39
SGEMM eben nicht. Weiste wie Bandbreitenhungrig das Ding ist? :ugly: Selbst DGEMM wird auf GPUs durch die Bandbreite des Speichers limitiert.
Da musste also schon schwerere Geschütze auffahren, wo deutlich mehr gerechnet wird je Speicherzugriff.
Wenn dein Problem eine gewisse Granularität hat, dann kannste daran nichts ändern...
Ist ja nicht so, als ob man da nicht eh schon immer drauf optimiert... :rolleyes:
Ok wusste ich nicht. Hab schon lange nix mehr mit GPGPU gemacht und bin da recht weit weg vom Fenster.
Skysnake
2012-03-20, 16:25:59
Das war eigentlich bereits die gesamte GPGPU-Zeit so.
Du hast einfach zu kleine Caches, und kannst so nicht groß genügende Slices nehmen, um genug Datenreuse zu haben.
Ich nehm mal an dass das Ding keinerlei automatische Cache-Kohärenz sicherstellt?
mboeller
2012-03-23, 09:26:45
Approaching Peak Theoretical Performance with Standard C:
http://www.adapteva.com/index.php?option=com_content&view=article&id=47&Itemid=69
http://www.adapteva.com/images/stories/papers/approaching_peak_theoretical_performance_with_standard_c.pdf
http://www.adapteva.com/images/stories/papers/benchmarks.tar (source-code)
Gaestle
2012-03-23, 12:37:18
mal anders gefragt:
Soweit ich das verstehe, werden hier vor allem Nachteile aufgezählt. Was ist aber der Vorteil von so einem Chip? Warum setzt sich jemand hin und entwickelt sowas? Wofür ist so ein Ding gut?
Skysnake
2012-03-23, 13:08:39
ClusteronChip ist das halt. Die Weiterentwicklung eines SoCs halt. Das ist vor allem Forschung in meinen Augen.
Gaestle
2012-03-25, 13:42:39
Ah. Danke.
airbag
2012-03-26, 08:34:23
Keine Wurzel/Division und Nichteinhaltung des float-Standards machen das Teil für wissenschaftliche Berechnungen eher unbrauchbar.
Schade, mit Divider wäre das Teil evtl. für Raytracing interessant(Mit der Speicheranbindung zu haushalten wäre die Herausforderung für den Programmierer).
Theoretisch bräuchte man nur logische Operatoren um es sich selber zu implementieren.
GloomY
2012-04-09, 20:22:32
Theoretisch bräuchte man nur logische Operatoren um es sich selber zu implementieren.Multiplikation und Addition sollten es schon sein, ansonsten wird es zu aufwändig. Dann kann man einfach ein paar Newton-Raphson Iterationen machen.
Um dafür nicht wiederum die Division zu benötigen, kann man für
Division von a und b erst 1/b mit f(x) = 1/x - b und der Iterationsvorschrift x(i+1) = x(i) * ( 2 - b * x(i)^2 ) berechnen und dann mit a multiplizieren.
Wurzel(c) erst 1/Wurzel(c) berechnen und dann mit c multiplizieren. Für 1/Wurzel(c) kann man mit f(x) = 1/x^2 - c und x(i+1)= x(i)/2 * (3 - c * x(i)^2 ) iterieren bis zur gewünschten Genauigkeit.
Beide Iterationen brauchen nur Multiplikation und Addition bzw Subtraktion :-) Siehe z.B. hier (http://perso.ens-lyon.fr/jean-michel.muller/EMTAsilomar05.pdf) für Details.
Hier hätte man übrigends deutlich mehr Arithmetik als Speicherbandbreitenverbrauch. Vielleicht lohnt sich's also doch für diese Architektur?!
Um eine saubere Division zu bekommen braucht man mindestens FMA und die Inverse.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.