Echelon: Architektur für das "ExaScale-Computing"

[Gipsel]

Das Thema kam ja gerade im Maxwell/Kepler-Thread auf. Was ist Echelon?

Kurz, die DARPA hat ein Project ausgeschrieben, bei dem es darum geht, die Architektur für einen HPC-Cluster im Jahre 2018 mit einer Rechenleistung von 1 ExaFlop/s = 1000 PetaFlop/s = 1000000 TeraFlop/s zu entwerfen.

Nvidias Codename für das Project ist Echelon (da machen aber noch ein paar andere mit, z.B. Cray; irgendwie erscheint da der Wechsel von Steve Scott von Cray zu nv in einem etwas anderen Licht, oder?). Es gibt sogar schon grobe Angaben darüber, wie sich nv das Ganze vorstellt (und viel mehr als vorstellen ist auch noch nicht, da ist noch nichts in Stein gemeißelt und es wird sich sehr Vieles noch ändern). In Grundzügen kann man das z.B. hier mal direkt von Bill Dally nachlesen (http://www.nvidia.com/content/PDF/sc_2010/theater/Dally_SC10.pdf). Zu Echelon gehört viel mehr als nur ein GPU-Design, es ist auch die ganze Verbindung der Einzelteile zum ganzen Cluster, also Interconnect, Programmiermodell und sowas. Aber ich denke die meisten interessiert hier erstmal nur der (GPU?-)Chip von nv.

Kurz, ein einzelner Chip soll ~20 TFlop/s machen und aus 128 SMs sowie 8 "latency processors" (in anderen Präsentationen auch "latency cores" genannt). Jeder SM besteht wiederum aus einer 8er-Gruppe von (vector?)-Lanes, die jeweils 4 DP-FMAs und 2 L/S-Einheiten beeinhalten.

Also summa-summarum 4096 DP-FMAs pro Takt und Chip, was heißt, daß die Einheiten mit ~2.4GHz laufen müssen, um die 20 TFlop zu schaffen. Also zumindest danach sieht es weiter nach hotclock aus, es sei den nv will die Taktfrequenz anderweitig steigern bzw. setzt auf Prozeßfortschritte (was in letzter Zeit eigentlich zumindest zu diesem Zweck nie geklappt hat :rolleyes:).

Es sieht so aus, als sollte jede 4fach Vektor-Lane diesen Register-Cache bekommen (hier im Startpost des Tech-Threads zu Kepler/Maxwell verlinkt (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8798670#post8798670)), sowie einen L0-D$ sowie L0-I$ (aka Instruction Buffer bei GCN ;)).

Die 8 Lanes zusammen in einem SM haben dann einen gemeinsamen L1-Cache, alle SMs auf dem Chip (sowie die latenzorientierten Kerne) teilen sich einen L2 mit offenbar 1024 Bänken zu je 256 kB Größe (also insgesamt 256MB L2, bei 128 Bit-Zugriffen hätte man ~40 TB/s on-Chip-Bandbreite zum L2, Speicherbandbreite soll übrigens ~1,5TB/s sein).

Tja, was hält man davon? Ein wenig sieht es so aus, als wären die dort vorgestellten SMs sowas wie die Vektorkerne in den alten Crays. Bei GCN hat man das schon gesagt (dort fällt auch die Skalar-Einheit als oberflächliche Gemeinsamkeit auf), aber bei nv würde es für mich fast so ein wenig auf die von den Vektorrechnern bekannte variable Vektorlänge hindeuten. Also jede Lane mit den 4 DP-FMAs loopt gesteuert durch ein vectorlength register variabel oft über den gleichen Befehl (mindestens 1 mal; wegen der 4 Einheiten pro Lane, das ist also 4 die minimale Granularität). Führt man einen der bekannten Warps mit 32 Datenelementen aus, loopt der also 8 Takte in so einer Lane. Die Größenordnung läßt ein aber auch wieder daran denken, daß man vielleicht fest bei den 32er Warps bleiben wird (und Latenz dann runter auf 8 oder doch 16 Takte von jetzt 18 bei Fermi? Das oben erwähnte Paper mit dem Register-Cache modelliert die Sache übrigens für 12 Takte Latenz, hmm), um die Scheduler möglichst einfach zu bekommen. Das könnte dann nämlich bald genau so wie bei GCN aussehen, ein Scheduler für die 8 vec4-Lanes, und im Round-Robin-Vefahren bekommt jede Lane alle 8 Takte einen neuen Befehl (und bei 8 Takten Latenz müßte der Scheduler noch nicht einmal Abhängigkeiten zwischen den arithmetischen Instruktionen beachten), bzw. zwei Befehle (die L/S-Einheiten wollen ja auch gefüttert werden). Egal, das ist wahrscheinlich noch etwas früh, das zu sagen, da nv das wohl selbst noch nicht festgezurrt hat und das alles eher noch Studien-Charakter hat.

[=Floi=]

das habe ich schon vor mind. 2 monaten mal gefragt und da hat es keinen interessiert... :rolleyes:

[Gipsel]

das habe ich schon vor mind. 2 monaten mal gefragt und da hat es keinen interessiert... :rolleyes:
Vor 3 Wochen im Tegra-Thread (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8848086#post8848086). :rolleyes:

Aber jetzt hast Du ja eine Antwort. ;)

[Skysnake]

Naja, es ist doch klar, das sich die Sache so weiter entwickelt. GPUs sind ja schon bis jetzt immer stärker in die Richtung der Vektorrechner gegangen, mit GCN und der Skalareinheit ist die Verwandtschaft extrem hoch.

Die Sachen bzgl. Echelon hören sich auch sehr vernünftig an für weitere Steigerungen. Die Sache mit den fehlenden Abhängigkeiten gabs doch beim Stanford Imagine glaub ich schon. Oder es war eine andere grundlegende Rechnerarchitektur, wo die Sache durch ein Prozessorgrid durchgewandert sind. Den Namen hab ich aber grad vergessen. War das nicht der Feldrechner oder so?

Naja, wie dem auch sei. Es werden halt wieder alte Konzepte aufgegriffen, die sich bewährt haben, aber eben neu kombiniert mit der aktuellen Technik. Es ist halt wie immer eine Frage der Skalierbarkeit+Größe. Man muss immer das jeweilig optimale Konzept benutzen.

Der Knackpunkt am Exaskaleprojekt ist eigentlich die Energieaufnahme. Die Größe der Chips ist da wirklich zu vernachlässigen. Eben so eigentlich in gewissen Grenzen die Anzahl der Maschinen. Lieber unterm Strich die gleiche Berechnung mit weniger Stromverbrauch.

Bei so ner Maschine wird man sich wohl eh von FatTree und allgemein von Switch basierten Netzwerken verabschieden müssen. 3D+ Tori werden wohl die beste Wahl sein. Man spart sich einfach den Switch, der schon verdammt teuer und Energiehungrig ist, und kann auch die Latenzen sehr schön niedrig halten bei Anwendungen, deren Kommunikationsstruktur eben eine ähnliche Struktur haben. Wenn man Punkt zu Punkt brauch, hat man halt verloren, aber das ist ja eher selten. Meist sind es ja eher nearest neighbor oder halt eine Stufe noch dazu, aber das wars ja. Damit lassen sich ja die ganzen Probleme wie Wärmeverteilungen, Wetter, etc etc etc machen. n-Body wird da schon etwas blöde, wobei da die Kommunikation im Verhältnis zum Rechenaufwand ja schnell vernachlässigbar wird. Da kann man gut Latenzen verstecken, wenn man genug RAM/Cache hat.

Brauch-/Warmwasser WaKü wird dort sicherlich auch eingesetzt werden. Den "Luxus" mit gekühlter Luft zu kühlen kann man sich einfach nicht mehr erlauben.....

Naja, ein großer Punkt wird denke ich noch die Anbindung der GPU an die CPU werden. Eigentlich sollte man sich meiner Meinung nach von PCI-E verabschieden und auf HT setzen und gut ist. Die CPU und GPU müssen einfach besser verzahnt werden, sonst wird das nichts. Vielleicht sehen wir daher auch APUs mit Octachannel Interface oder so eher als CPU+dezidierte GPU. Der Ansatz ist auf jeden Fall sehr interessant, da eben die Latenzen wegfallen, und man Cache-Kohärenz dort auch sehr einfach realisieren könnte. Also der Umstieg zwischen Fat-Core und Stream-Cores wäre halt sehr Effizient machbar. Ist halt nur die Frage, wie oft geplante Anwendungen dies effektiv nutzen könnten, und wie sich die Chipentwicklung bis dort hin weiter entwickelt. Wenn wir da schon die stacked Chips haben, was durchaus möglich ist, dann kanns eventuell wirklich auf ne APU raus laufen, da dann echt nur die Stromversorgung + Datenkommunikation (Pin-Limitation) ein Problem ist.

Wenn man die Verknüpfung nicht nutzen kann, dann wird es wohl bei CPU+dezidierter GPU bleiben.

Man sollte die FPGAs allerdings nicht aus den Augen verlieren. Sie sind einfach extrem effizient und flexibel, was weder die CPU ist, noch die GPU. Hier ist halt das Problem der "Programmierbarkeit" noch größer als bei den GPUs, die die Programmierer ja schon vor große Probleme stellen.... Für Exascale könnte ich mir aber schon vorstellen, das es die Leute gebacken bekommen, die bestehenden High-lvl FPGA-Programmiersprachen weiter zu entwickeln, und eben große Bibliotheken ähnlich wie bei FORTRAN bereit zu stellen, die dem normalen Programmierer dann die Arbeit mit FPGAs ermöglicht.

Würde dann also wie folgt aussehen: CPU+onchip FPGA und dazu eine dezidierte GPU.

Im Optimalfall nutzt die GPU eben kein PCI-E, sondern wie die CPU dann z.B. HT, womit dann viel Overhead und Latenzen abgebaut werden können. Man spart sich auch viel Geld für die Entwicklung des Cachecohärenzprotokolls zwischen CPU und GPU. In dem Text von Gipsel stand ja auch was dazu, das man die Caches zwischen CPU und GPU cohärent halten will, wenn ich mich nicht verlesen habe.

Naja, und wenn man das dann hat, sollte die GPU dann intern auch konsequent aufsetzen, damit man sich da auch wieder Latenzen spart, um zwischen Protokollen zu wechseln.

Richtig Schick wäre es natürlich, wenn eine "CPU"+1-2GPUs zusammen direkt auf ein Daughterboard gelötet werden, und diese dann wieder in ein Motherboard gesteckt werden. Ähnlich wie bei den PowerPC in BlueGene halt.

Wenn man so konsequent CPU und GPU verbindet auf einer Platine, könnte man sich auch überlegen, ob man CPU und GPU nicht der eigenständigen Ram-Controller beraubt und diesen als einen Zusatzchip hin baut, der dann einen asymmetrischen Speicher verwendet. 512 oder 1024 Bit Interface, welches voll an die GPU angebunden wird, und für die CPU eben etwas geschrumpft. Da besteht leider nur das Problem, das CPUs eher kurze Latenzen benötigen, und GPUs die Latenzen eher zweitrangig sind, dafür aber sehr viel Bandbreite brauchen...Ok, vielleicht keine gute Idee ^^ auch wenn der Ansatz halt ganz nett gewesen wäre, da man dann für einen "CPU"-GPU Verbund eben einen gemeinsamen Speicher gehabt hätte, und damit der Datenaustausch über ein Transferprotokoll wie HT oder PCI-E weggefallen wäre. Man würde halt über den RAM kommunizieren, der ja doch recht hohe Bandbreiten bietet. Cachekohärenz wäre auch sehr einfach zu realisieren, wenn man die Latenzen als nicht ganz so wichtig ansieht, was bei der Verbindung mit der GPU doch durchaus Sinn machen könnte. Also mehr oder weniger, eine zweistufige Cachecohärenz. Einmal intern auf der CPU/GPU und dann über beide Device hinweg, wo die Latenz etwas größer sein darf, und man dann halt warten muss und andere Sachen machen kann in der Zwischenzeit.

hmmm... Dann könnte man auch direkt über Load/Stores arbeiten.... hmm.... vielleicht ist die Idee doch nicht ganz so schlecht. :biggrin:

Das Problem mit den Latenzen ließe sich mit DDR4 (x) oder anderen Speichermodellen, vielleicht auch beheben. Müsste man halt mal schauen, was einem die Sache bringt, und wie viele Probleme man sich bei der CPU damit einhandelt....

Auf jeden Fall mal ne Überlegung Wert. Allerdings sehe ich da etwas das Problem, das man damit komplett aus der "Standard"-Hardware/Formfaktoren/Protololle etc. raus fliegt, und damit die Kosten doch explodieren. Die Stückzahlen an produzierter Hardware wären einfach relativ gesehen doch sehr klein, auch wenn man eine Millionen solcher Daughter-Boards dann bauen würde.

Vielleicht könnte man so ein Daugther-Board aber als Grundlage für die übernächste XBox oder PS5 nehmen. Das wäre dann natürlich optimal.

Hmm..... :D Da bieten sich eigentlich GANZ lustige Konzepte der Skalierbarkeit merke ich gerade :biggrin: Ne Spielekonsole bekommt 1-2 Daughter-Boards in System, womit die Sache sehr einfach bleibt, der PC, bekommt 2 bzw. 4, womit die Main-Boards noch recht einfach bleibt auch was die Multiplexer etc. angeht, und die Server bekommen dann 8/16/32/64/128 solcher Daughter-Boards auf ein Mainboard, welches dann per Backplane innerhalb eines Racks verbunden sind, um Punkt-Punkt Verbindungen zu realisieren, bzw. eben Broadcasts etc. effizient durch zu führen etc. Und dann das gesamte Rack per 10 oder 20D Tori mit den anderen Racks zu verbinden. Man könnte für ein Rack ja genug Ports dann bereit stellen.

Arg ne Moment, die Bandbreite vergessen.... Man braucht ja zwischen den Racks ja noch dich gleiche Bandbreite, als wenn man jedes Mainboard untereinander dann verbindet....

Hm.. Wobei, man kann ja beim Tori-Konzept "einfach" statt einem 10/20D Tori dann einfach einen 3/4D Tori nehmen. Damit steigt dann die Bandbreite zwischen den einzelnen Racks an :biggrin:

hm... Klingt auch gar nicht so schlecht, da man sich dann überlegen kann, was eher auf dem Cluster läuft, bzw. den Cluster in 2-4 Subcluster unterteilen, die halt eher die eine oder eher die andere Aufgabe erfüllen, und dann Performanceverluste hinnehmen, wenn man wirklich mal eine uniforme Aufgabe auf dem gesamten Cluster ausführt, ansonsten kann man die Aufgabe vielleicht auch geschickt Partitionieren und auf den Cluster mappen, so das man die unterschiedlichen Topologien geschickt zu einem Vorteil nutzen kann, wobei ich mir das nicht vorstellen kann für die Aufgaben, die einen Exascale Rechner brauchen :ugly:

EDIT:

Sorry für die WoT gerade erst gesehen :rolleyes:

[Ailuros]

Ziemlich alter Link: http://www.brightsideofnews.com/news/2010/11/19/project-echelon-the-future-of-nvidias-silicon.aspx

aber nur weil er vielleicht nutzvoll zum Thema hier sein koennte als Lesematerial.

Jetzt wo das Thema konstant wieder im Kepler/Maxwell Thread zum OT abschweift wird das Thema Echelon vielleicht wieder aktuell ;)

[Skysnake]

Naja, was soll man dazu sagen? Das Problem ist halt die Energieeffizienz. Wenn das gelöst ist, wird es auch einen Exaskale-Rechner geben. Aktuell sieht es aber etwas schwierig aus.

Mit den aktuellen Konzepten, die keine großen Schritte vorwärts gehen und zu sehr an alte Standards, Formfaktoren und Bauweisen gebunden sind, wird das nichts.

Bevor das gelöst wird, sind meiner Meinung nach folgende Schritte noch notwendig:


Neuer Speicher ähnlich wie Flash, der große Datenbestände hält
Integration der GPU in die CPU, so das immer derjenige mit der besten Energieffizienz das Problem lösen kann und der Energieaufwand für das kopieren von Daten wegfällt
gemeinsamer Arbeitsspeicher sowohl für CPU als auch GPU, um keine Energie für sinnloses hin und her kopieren zu verschwenden
Extrem hohe Bandbreiten für den RAM, damit CPU und GPU auch mit genug Daten versorgt werden können
Neue Formfaktoren, die die ganzen Steckverbindungen eleminieren. Die Verluste kann man sich nicht leisten. CPU/GPU/RAM alles auf eine Platine löten mit kurzen Laufwegen, damit man die Signale nicht so weit treiben muss
Vereinheitliches Protokoll für CPU und GPU und alle etwaigen Erweiterungskarten. Umcodieren etc. kostet nur unnötig Energie
Netzwerktopologie ohne Switches. Die kosten nur unnötig Energie


Sodele, wenn wir das dann alles haben, was ja wirklich "nicht" viel ist :ugly: dann sollte man noch darüber nachdenken, FPGAs zu verwenden, die on the fly umprogrammierbar sind, um z.B. bei reduzierten Anforderungen, oder extrem hohen Anforderungen an die FP-Genauigkeit, Energieeffizienter zu arbeiten.

Naja, und wenn das alles gemacht ist, bzw. Parallel dazu, sollte man noch On-Chip über LWL nachdenken, spätestens halt wenn man vom Chip mal runter muss.

Mit den heutigen Formfaktoren, wo alles über eigene Sockel bla blub angeschlossen ist, kommste da aber nicht weit. Das ist alles nicht radikal genug, und für son Ding musst du einfach radikal sein.

Luftkühlung ist da auch absolut keine Möglichkeit. Das Ding muss mit Wasser gekühlt werden, und dieses dann an eine Stadt/Industrie weitergeleitet werden, damit die die Abwärme nutzen können. Ein Schwimmbad+Kleinstadt mit Fernwärme oder sowas wie der Bursch Dubai wären so Kandidaten meiner Meinung nach.

Die Verlustleistung darf man auf jeden Fall nicht einfach in die Umwelt raus blasen. Ansonsten kann das keiner mehr zahlen, weil die Effizienzanforderungen nicht erfüllbar sind. Bzw. es macht einfach keinen Sinn mehr, so viel Energie schlicht nach draußen zu blasen.

[LovesuckZ]

Nvidia’s Steve Scott on the Road to Exascale at SC11 (http://insidehpc.com/2011/11/21/video-nvidias-steve-scott-on-the-road-to-exascale-at-sc11/)

Interessantes Interview und vorallem ist es glaubwürdig, da Scott deutliche Einblicke bei Cray gesammelt hat.

[Gipsel]

Hier mal eine Präsentation zu den Herausforderungen für die Zukunft von nV (http://mediasite.colostate.edu/Mediasite/SilverlightPlayer/Default.aspx?peid=22c9d4e9c8cf474a8f887157581c458a1d#) (man benötigt wohl Silverlight). Um etwa 30 Minuten geht es um einen Maxwell-Nachfolger (er nennt ihn Einstein), wo klar gesagt wird, daß dort keine Scoreboarding mehr gemacht wird und das Scheduling dramatisch vereinfacht wird. Es fallen auch Wörter wie "latency counter". Damit wird erreicht, daß man eine Operation sicher absetzen kann, ohne sich groß um Abhängigkeiten kümmern zu müssen. Das Scheduling wird also sich also offenbar auf die selben simplen Prinzipien zurückziehen wie GCN das heute tut. Die SM-Lanes arbeiten aber vollkommen anders, das sieht [eventuell] nicht mehr nach SIMD aus.

Edit:
Das Ding ist übrigens angeblich für den 10nm Prozeß geplant (die 290mm² Diegröße sind allerdings zu diesem Zeitpunkt schwerlich mehr als eine sehr grobe Schätzung), kann man sich also grob überlegen, wann das kommt (2018+).

Edit2:
In Technologiethread kopiert. Die Beschreibung hat sich übrigens gegenüber der früheren Darstellung offenbar schon geändert. Es sind jetzt doppelt so viele SMs, dafür macht jede SM-Lane nur noch 2 DP-FMAs statt vorher 4 (und besitzt nur eine L/S-Einheit statt 2). Das bestätigt die Einschätzung aus dem Eingangsposting, daß das längst noch nicht feststeht, sondern noch eher Studiencharakter besitzt.

[=Floi=]

warum soll man da nur 290mm² pro chip nützen, wenn technisch sicherlich auch das doppelte gehen wird? da könnte man ja dann gleich 4 DIE pro chip verbauen...

[Skysnake]

Immer auch eine Sache der Kosten.

[Gipsel]

Wie von Ailuros vorgeschlagen, wurden die Posts in einen entsprechenden Technologiethread (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9116942#post9116942) kopiert, der sich mit den Entwicklungen nach Kepler hin zu Einstein und dem Echelon-Projekt befaßt. Dort kann die Diskussion fortgesetzt werden.