WaveCache-Architektur - paralleles Rechnen ohne vonNeumann

[S940]

War in der ct als chinesisches Gerücht für Excavator erwähnt, was mMn äußerst zweifelhaft ist, aber die Architektur ansich klingt interessant, ausführtliches Paper gibts hier:

http://cseweb.ucsd.edu/users/swanson...ScalarArch.pdf (http://cseweb.ucsd.edu/users/swanson/papers/TOCSWaveScalarArch.pdf)
(Thx@Complicated@P3D)

[Hübie]

Och man. Nu muss ich mir das komplette paper ansehen um zu wissen worum es denn nun geht. Also komm. Ein paar Sätze wären schon nicht schlecht. Wenn man schon ein Thema eröffnet sollte man auch etwas Arbeit investieren ;)

[ndrs]

Och man. Nu muss ich mir das komplette paper ansehen um zu wissen worum es denn nun geht. Also komm. Ein paar Sätze wären schon nicht schlecht. Wenn man schon ein Thema eröffnet sollte man auch etwas Arbeit investieren ;)
http://www.planet3dnow.de/vbulletin/showthread.php?t=414008 Da wird schon drüber philosophiert.

[Hübie]

Dank layer ads bin ich da seit langer Zeit nicht mehr aktiv...

[Skysnake]

So bin zwar erst auf Seite 4 vom Paper angelangt, aber ein paar Sachen sind mir schon durch den Kopf gegangen, nachdem ich mir vorweg mal kurz nochmal den Ansatz von Datenflussrechnern angeschaut habe.

Datenflussrechner sollen ja impliziet die Datenparallelität ausnutzen, also ohne Zutun des Programmierers diese erkenne, einfach schon aufgrund der Programmiersprache/Compiler.

Für mich klingt das immer direkt nac "faulen" Programmierern, die eben zu doof/keine lust haben sich über Parallelität Gedanken zu machen, und das lieber dem Grundkonzept bzw der Hardware überlassen... Das beudetet aber, das die Hardware "denken" muss, und "denkende" Hardware ist komplexer und/oder verbraucht einfach mehr Strom...

Ich hatte da auch direkt Caches als Problem im Kopf, und der kurze Wikiartikel zu Datenflussarchitekturen stellt auch genau das als Problem raus... Caches werden nicht effizient genutzt... Und damit ist die Architektur eigentlich schon tot, denn heutige Chips, die grundlegend der von-Neumann Architektur folgen, aber eigentlich nicht mehr viel mit dem Grundkonzept zu tun haben, werde einfach durch die Leistungsaufnahme limitiert...

Wenn man also mehr Strom verbraucht ist man langsamer...

Ich werd mir mal noch den Rest reinziehen, aber ich bezweifle, dass da noch der heilige Gral offenbart wird... :rolleyes:

EDIT:
ein wichtiger Satz aus dem Paper:

We continue to investigate the placement problem,
and details of our endeavors are available in [23]
Und genau! das wird ihnen auch das Genick brechen. Sie berechnen zu viel und jagen Daten hin und her über den Chip, weil Sie ansonsten nämlich nicht die Parallelität ausnutzen können... Das macht die Sache aber energiehungrig, und da wir power limited sind, sind wir damit langsamer las mit einem normalen Design.

Dazu kommt noch, dass Sie eben einiges an zusätzlichen Daten verarbeiten müssen. Sie müssen ja für JEDE! Operation sich 4 Werte merken und auswerten... Und dann setzen Sie auch noch auf Broadcast-interconnects, weil Sie ja eben alles parallel machen, und parallel entscheiden müssen, ob etwas überhaupt ausgeführt werden darf...

Also ich seh in dem Ansatz absolut keine Chance, das im Consumerbereich zu sehen. Es gibt sicherlich einzelne Problemfelder, wo das Design super duper toll drauf passt, aber der 0815 Anwender wird das nicht sein.

EDIT2:
Und noch so ein Punkt...

We use a well-known dataflow technique, k-loop bounding [24], to restrict the number iterations, k, that can be executing at one time. We tune k for each appli-cation.

[Loeschzwerg]

Gleich vorweg, ich habs mir nicht durchgelesen :freak:

Aber den Punkt bezüglich "denkender" Hardware finde ich recht interessant. Ist es nicht u.a. Ziel von HSA irgendwann einmal die anfallenden Aufgaben von der Hardware effektiv verteilen zu lassen bzw. so eine bestmöglichste Auslastung der Ressourcen zu schaffen?

[Skysnake]

Ja, aber das ist was komplett anders.

Hier geht es darum zu erkennen, welche Operationen ausführbar sind, also das was bei der von-Neumann Architektur einfach durch den Programmcounter realisiert wird, ist hier ein wirklich großes Problem. Du führst nämlich einfach mal alles aus, was es an Möglichkeiten gibt, und schaust erst dann, ob das überhaupt richtig ist...

Das kann man sich meiner Meinung nach heute eigentlich nicht mehr leisten wo man powerlimited ist.

HSA hat da einen komplett anderen Ansatz.
Du hast einen Code und willst im Prinzip durch Hard-/Software entscheiden, welche Hardware denn am Besten dafür geeignet ist.

Also z.B. du hast nur sehr sehr sehr wenige Branches, aber gleichzeitig extrem große Schleifen, die du leicht entrollen kannst. So was würde sich gut auf ner GPU machen. Usw usw

Also das sind zwei grundverschiedene Sachen und dürfen auf keinen Fall in einen Topf geschmissen werden!

[Loeschzwerg]

Also das sind zwei grundverschiedene Sachen und dürfen auf keinen Fall in einen Topf geschmissen werden!

Tue ich auch nicht ;) Ich frage mich nur welchen Sinn es überhaupt macht diesen neuen Ansatz zu verfolgen, gerade im Hinblick auf die Effizienz und Kompatibilität.

Mehr als Grundlagenforschung ist dies dann doch nicht?! => Mit dem Zwischenfazit: Da dürfte es massive Probleme geben (Wie du ja geschrieben hast)

[Skysnake]

Datenfluss-Architekturen sind keine neue Erfindung. Das gibts schon relativ lange, Sie haben sich aber nie wirklich durchgesetzt. Also es gab meines Wissens nach schon zeitweise welche die durchaus eingesetzt wurden, aber nie etwas für den Massenmarkt.

Man forscht halt weiter dran, und schaut ob man nicht doch durch irgendwelche tollen Tricks/Heuristiken/what ever die Sache doch effizient gelöst bekommt. An sich ist die Idee ja ganz scharmant, vor allem weil man eben nicht von Hand expliziet parallelisieren muss, sondern das impliziet passiert. Wenn man sich anschaut, das >50% der Programmierer einfach nicht parallel programmieren können/wollen, dann weiß man eigentlich schon, warum es ganz "nett" ist. Gute parallel-Programmierer sind selten und daher teuer, wie so vieles halt!

[Skysnake]

Hach, ich musste beim lernen gerade an diesen Thread denken.

Hab gerade ne Folie vor mir, die sich mit fine-grain parallelism beschäftigt, und auf die Erkennung von Datenabhängigkeiten eingeht. ;)

Und siehe da, da tauchen VLIW und Datenflussrechner auf.

VLIW macht die Erkennung von Datenabhängigkeiten zur Compilezeit durch eben diesen, und Datenflussgraphen machen es in Hardware.

AMD hat sich ja von VLIW abgewendet, da der Compiler einfach zu complex geworden ist, um die Probleme vernünftig auf immer mehr VLIW einheiten zu mappen. Das sagt eigentlich alles aus ;)