Forum: Offtopic (Kickstarter) Parallella: A Supercomputer For Everyone

Das ist viel Blabla um Nichts (substantielles), wenn du mich fragst.

Wieder mal eine Lösung für ein Problem, dass kaum einer hat. Ein ARM9 
ist recht lahm, die FPU (hat der in dem Chip überhaupt eine?) erst 
recht, normale HPC-Lösungen wollen aber im wesentlichen FPU-Performance. 
Und von trivialen Anwendungen (Apfelmännchen...) abgesehen, ist eine 
halbwegs skalierende Parallelisierung gar nicht einfach, automatisiert 
sowieso nicht. Je mehr Cores man hat, umso schwieriger wird es, 
Flaschenhälse durch Cache-Effekte, NoCs und Speicherzugriffe zu 
vermeiden.

ähm...dort werden keine ARM9 zusammengeschaltet. der ARM9 ist nur für 
die Peripherie zuständig.

http://www.adapteva.com/products/silicon-devices/e64g401/

Wie performant das ist, weiss ich natürlich nicht...aber zumindest sinds 
keine normalen ARM Cpus

> dort werden keine ARM9 zusammengeschaltet.

Ok. Die Cores haben auch eine FPU, immerhin...

Aber 32KB lokaler Speicher (kein Cache) reicht nicht für viel. Entweder 
muss man remote (NUMA?) von anderen Cores lesen, das killt die 
Performance oder man muss es sich per DMA holen. Das killt den 
Programmierer ;) Das Konzept hat schon beim Cell dazu geführt, dass er 
trotz seiner potentiellen Performance kein HPC-Knüller wurde (eher ein 
Flop).

Als Interface nach aussen gibts auch nur die LVDS-Links, die im 
Vergleich zur internen Verarbeitungsrate auch eher langsam sind. 
"Echter", grosser Speicher ist damit seeehr "weit" weg, die Performance 
der Cores wird verschenkt.

Sicher wird es Anwendungen geben, die damit super laufen (eine 
Matrix-Multiplikation ist in nahezu jeder HPC-Architektur trivial 
schnell zu bekommen...), auch Streaming/DSP wird gut laufen, aber 
universell wird da eher wenig gehen.

BTW: Ich will ja kein Dauernörgler bzgl. neuer abgespaceter 
Architekturen sein, aber ich habe schon genug von dem Zeug auftauchen 
und wieder untergehen sehen. Am Ende entscheidet der "normale" 
Programmierer (und nicht der Assembler-Frickel-Geek), und der hat immer 
noch genügend Probleme selbst mit normalen Threads. Wenn er sich noch um 
NUMA-Absonderlichkeiten, Datenlokalität/Konsistenz, DMA etc. kümmern 
soll, ists vorbei.

Es gibt ja heute schon Supercomputer. Das waeren dann die GPU. 
Graphikkarten, mit oder ohne Display. Siehe zB
http://www.nvidia.com/object/workstation-solutions.html
http://www.nvidia.com/object/cuda_home_new.html
http://www.nvidia.com/object/workstation-solutions-tesla.html

Eine Tesla C275 macht bis zu Singleprecision 1030 GFlop, resp 515 GFlops 
doubleprecision. Bei einer Memory bandbreite von 140 GByte/s.

Laste erst mal so eine aus...

> Laste erst mal so eine aus...

Und wenn der Speicher auf der Karte nicht ausreicht, ist es auch vorbei 
mit der Performance, da ist PCIe (egal welche Version) dann der 
Flaschenhals.

Na. Die Karte selbst hat 6GByte. Die kann man einen Dual Xeon, mit je 6 
Kernen mit 48 GByte RAM einstecken. Wenn man dann PCI-1600 einfuellt, 
solltye es gut sein.
Aber der Einwand ist korrekt.

>Na. Die Karte selbst hat 6GByte. Die kann man einen Dual Xeon, mit je 6
>Kernen mit 48 GByte RAM einstecken. Wenn man dann PCI-1600 einfuellt,
>solltye es gut sein.

Ach was.
Wenn man die Kohle hat, das Problem/Algorithmus sich parallelisieren 
lässt und man wirklich viel Speicher und Prozessoren braucht, dann 
stellt man sich für 500k++€ ne Sunfire X4800 M2 mit 8x10 Cores und 4TB 
RAM hin.

Da kommt bei grossen Datensätzen vermutlich keine GPU mit

So richtig verstanden habe ich das ganze auch noch nicht.
Ich frage mich wie ich in einer "typischen" Microcontroller-Applikation 
effizient Nutzen aus einem Multicore ziehen kann.

Ich bin über http://www.diydrones.com darauf aufmerksam geworden. In 
Bezug auf Flugdrohnen war ein vorgeschlagenes Anwendungsgebiet der 
optische Fluss. Generell rechenintensive Bildverarbeitung oder 
vergleichbares ließe sich damit super realisieren, durchaus interessant 
für die Drohnenwelt (und andere).

Und bei dem angestrebtem Preis von <100$ kann man es mal testen. Ich bin 
skeptisch ob der "Endanwender" (der normale uC Pogrammierer) wirklich 
gut unterstützt wird in Hinbkick auf Tutorials, Entwicklungsumgebung, 
Beispiele etc und ob das das wirklich gut zusammenspielt. Aber 
vielleicht haben die Leute von adapteva auch Recht mit ihrer 
Einschätzung bezüglich Single-Core Applications.

Noch ein paar Links:

http://www.hpcwire.com/hpcwire/2012-08-22/adapteva_unveils_64-core_chip.html

http://hackaday.com/2012/09/28/massively-parallel-64-core-computer-costs-99/

http://arstechnica.com/information-technology/2012/09/99-raspberry-pi-sized-supercomputer-touted-in-kickstarter-project/

Und hier noch Kickstarter-Status "kicktraq"
http://www.kicktraq.com/projects/adapteva/parallella-a-supercomputer-for-everyone

Das geht auch mit Lego und Raspberry:

http://www.elektronikpraxis.vogel.de/embedded-computing/articles/378289/


HansL

Hans L. schrieb:
> Das geht auch mit Lego und Raspberry:
>
> http://www.elektronikpraxis.vogel.de/embedded-computing/articles/378289/
>
>
> HansL

jaaaa ..... Die Kosten sind ja in etwa die Selben ...

Aber das das ding 1...2 Watt für 40 GFlops braucht halte ich schon für 
beachtlich.
Für autonome Roboter die viel mit DSP zeugs rumrechnen müssen (stichwort 
wie oben Optischer Fluss) ist die Lösung ideal (neben den Alternativen
-GPU in den Roboter einbauen
-multicore ARM gedöhns
-FPGA lösung
)

ja Lösungen gibts sicher heute auch schon. Die ziehlen aber auf eine 
OpenSource Community ab, was ich toll finde. Man sieht ja am Arduino 
Projekt oder am Raspberry PI was mit vergleichsweise moderat 
leistungsfähige Hardware zu erreichen ist. Vor allem das (erst kürzlich 
entdeckte) "es funktioniert einfach" - Prinzip von Arduino ist echt 
toll.


Nur sieht das Kickstarter Projekt nicht besonders rosig aus. IMHO wird 
das nichts... aber lassen wir uns überraschen.


Es gibt jetzt auch ein Architecture Reference und eine SDK Reference

http://www.adapteva.com/support/docs/e3-reference-manual/
http://www.adapteva.com/support/docs/esdk3-manual/

Meiner Meinung nach kann man es nur bedingt mit Raspberry PI 
vergleichen, weil R.PI die Rechenpower fehlt.
Allerdings braucht nicht jeder die Leistung, das sollte klar sein.

Muss nochn bissel rumstacheln...

>jaaaa ..... Die Kosten sind ja in etwa die Selben ...
hm mal rechnen... (grob über den daumen)[ich hab grade keine GFLOPS für 
die ARM CPU von R.PI da und ich rechne nur mit CPU Takt, ohne GPU, da es 
sonst sinnlos ist]
R.PI.  Ghz   64 (nodes) * 0.7 (Ghz) = 44.8 (Equivalente Ghz)
R.PI.  Stromverbrauch  64 (nodes) * 3.5 Watt = 224.0 (muss man 
ordentlich dämmeln)
R.PI.  Kosten  64 (nodes) * 25 Dollar = 1600 (kann man besser 
investieren)

Die Rechnung für die Äquivalente Leistung (Ghz/GFLOPS) spar ich mir mal 
für diesen vergleich.

Man sieht glaub ich deutlich einen trend.

Robert W. schrieb:
> Meiner Meinung nach kann man es nur bedingt mit Raspberry PI
> vergleichen, weil R.PI die Rechenpower fehlt.
> Allerdings braucht nicht jeder die Leistung, das sollte klar sein.
Natürlich kann man die nicht vergleichen

und das:
>>jaaaa ..... Die Kosten sind ja in etwa die Selben ...
war auch recht ironisch gemeint ;-)

gerade weil der adapteva ansatz so günstig ist ist es interessant