Entwicklungen von Maxwell zu Einstein/Echelon

[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 ;)

[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.

[Gipsel]

Warum sollte man in dieser Beziehung einen Rückschritt machen und den Nachfolger ineffizienter bauen? Ergibt für mich keinen Sinn.Schau Dir mal den von mir weiter vorne (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9110743#post9110743) verlinkten Vortrag an. Da wird eindeutig gesagt, daß es im Sinne der besseren Energieeffizienz günstiger ist, andere Sachen (wie nutzbare Leistung / theoretischer Peakleistung) zu opfern. NVidia wird in Zukunft Kompromisse in diese Richtung machen. Die Frage ist bloß, welche wann genau.

[Skysnake]

Warum lässt sich eigentlich keiner zu dem Vortrag, den Gipsel verlinkt hat aus? Ist jetzt auch an Gipsel gerichtet.

Der ist ja relativ aktuell, und ich bezweifle jetzt mal ziemlich stark, dass das Zeug, was dort angerissen wurde allen Leuten wirklich klar ist.

[Nighthawk13]

Warum lässt sich eigentlich keiner zu dem Vortrag, den Gipsel verlinkt hat aus? Ist jetzt auch an Gipsel gerichtet.
Der ist ja relativ aktuell, und ich bezweifle jetzt mal ziemlich stark, dass das Zeug, was dort angerissen wurde allen Leuten wirklich klar ist.
Ist halt die Frage, in wie weit sich die Sachen auf Kepler oder auf spätere Generationen beziehen.

Paar Punkte die mir aufgefallen sind:
- Anfangs spricht fast schon abfällig davon, wie die noch aktuelle Generation(Fermi) nur 512 Cores hat -> Hinweis auf viele Cores, kein Hotclock mehr
- Der Register-Cache wird erwähnt, ebenso die beiden Listen für aktive und inaktive(Wartend auf Speicherlatenzen) Warps -> siehe Technik-Thread (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=509927)
- Konfigurierbare Cache-Partionierung war mir neu
- Seine Vorstellung von Softwareentwicklung scheinen wohl eher von Wunschdenken geprägt zu sein. An die magischen Tools glaub ich, wenn sie sich 1 Jahr in der Praxis bewährt haben.

Musste an einen Webinar von Nvidia zum Thema Parallelprogrammierung(mit OpenACC) denken. Zitat war da sinngemäss: "Wenn jemand behauptet, Parallelprogrammierung wäre einfach, will er dir vermutlich etwas verkaufen". :D

[Skysnake]

Und was wollen sie am Ende erreichen? Richtig, mehr Leistung.
Folie bei Minute 19 sagt es in 4 Wörtern:

Leistung = Effizienz
Effizienz = (Daten-)Lokalität

Wenn sie dafür ihre Cores vereinfachen müssen, dann werden sie es tun. Nirgendwo behauptet Daily, dass man in Zukunft Leistung opfern werde, um mehr Leistung zu erreichen (was für ein Paradoxon).
Es gibt mehrere Arten der Effizienz. Das von mit application TFlops/theretical Peak TFlops gemeint war, sollte eigentlich offensichtlich gewesen sein.

Man opfert also schon "Leistung" theoretische Leistung, die man aber eben gar nicht nutzen kann, weil man am Powerlimit ist. Die Sache wird mehr in Richtung SFUs gehen, die aber schön verteilt sind, damit man die Daten nicht so weit schubsen muss. Genau so die Sache mit den unterschiedlichen Cores für Aufgaben die Laufzeitkritisch sind, und denen, die nicht Laufzeitkritisch sind.

Man wird also vermehrt mit dem Leben müssen, was man bei AMD schon lange sieht. Super theoretische Werte, die aber oft nicht erreicht werden, oder eben in Zukunft eben gar nie, weil man zu weniger Powerbudget hat.

Die Perf/W wird steigen ja, aber jedwede andere Effizienz wird wohl sinken.

In wie weit man diesem Trend durch größere Caches entgegen wirken kann, wird sich zeigen müssen. Auf kurz oder lang wird aber ein Schritt definitiv nötig werden. Der RAM auf dem PCB muss weg.

Ist halt die Frage, in wie weit sich die Sachen auf Kepler oder auf spätere Generationen beziehen.

Paar Punkte die mir aufgefallen sind:
- Anfangs spricht fast schon abfällig davon, wie die noch aktuelle Generation(Fermi) nur 512 Cores hat -> Hinweis auf viele Cores, kein Hotclock mehr
- Der Register-Cache wird erwähnt, ebenso die beiden Listen für aktive und inaktive(Wartend auf Speicherlatenzen) Warps -> siehe Technik-Thread (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=509927)
- Konfigurierbare Cache-Partionierung war mir neu
- Seine Vorstellung von Softwareentwicklung scheinen wohl eher von Wunschdenken geprägt zu sein. An die magischen Tools glaub ich, wenn sie sich 1 Jahr in der Praxis bewährt haben.

Musste an einen Webinar von Nvidia zum Thema Parallelprogrammierung(mit OpenACC) denken. Zitat war da sinngemäss: "Wenn jemand behauptet, Parallelprogrammierung wäre einfach, will er dir vermutlich etwas verkaufen". :D

Da sprichst du mir aus der Seele. Wenn man ihm zuhört, könnte man denken, darauf wäre noch NIE jemand gekommen, und jetzt müsste man nur ein paar Fingerübungen machen und schon wären die super tollen tools da.....

Die Dinger sind ziemlich komplex.... Das die Dinger wirklich in KOMPLEXEN! Anwendungen richtig gut funktionien will ich erst mal sehen. Man schaue sich nur mal OpenMP an. Funktioniert auch ganz gut. Bei einfachen Problemen, und wenn man selbst sehr genau weiß was man macht. Der Rest ist eher Reduzierung von Schreibaufwand. Mehr nicht.

[Bucklew]

Die Dinger sind ziemlich komplex.... Das die Dinger wirklich in KOMPLEXEN! Anwendungen richtig gut funktionien will ich erst mal sehen.
Gibt bereits jetzt schon mehr als genug Tools, die zeigen was mit GPUs möglich ist. Sowohl GPGPU, als auch Raytracing o.Ä.

Lego nutzt z.B. Raytracing um ihre Konstruktionen zu überprüfen, Flugzeughersteller nutzen Flußsimulationen in Realtime für ihre Konstruktionen, Autohersteller simulieren die Spiegelung des Amaturenbretts in der Windschutzscheibe oder den Steinchenflug am Radkasten usw.

Und die Beispiele sind alle schon gute 1-2 Jahre alt :biggrin:

[AwesomeSauce]

Bist Du nicht bis zur Minute 30 gekommen? Da wird explizit gesagt, daß man bei vielen kleinen Sachen Performance opfert, um insgesamt bessere Performance/W zu bekommen (was sich dann bei begrenztem Power-Budget in einer höheren Gesamtperformance ausdrückt). Das wird übrigens auch schon beim Blockdiagramm der Alpha-CPU gesagt, daß genau das es ist, was eine CPU (latency optimized core) von einer GPU (throughput optimized core) unterscheidet.

Es wird eindeutig gesagt, man solle in Zukunft nicht mehr Instruktionen bzw. Flops zählen (die sind billig), sondern auf die Kommunikationsstrukturen und die Datenbewegung achten. Ergo Performance/Flops wird eine unwichtige Metrik (sprich, es wird weniger).
Genau so habe ich es auch verstanden. Danke übrigens für das Video.

Könnten wir aber bitte zum Thema zurückkehren? Einstein dürfte ja noch ein Weilchen auf sich warten lassen. Wieviel/Welche von den ganzen Ideen es bereits in die Kepler-Architektur geschafft haben, dürfte doch sehr schwierig zu sagen sein.

[Gipsel]

Genau so habe ich es auch verstanden. Danke übrigens für das Video.Ist ja eigentlich auch gut verständlich. Also ich meine daß falls man da was mißversteht, dann liegt es bestimmt nicht am schlechten Ton. Und logisch ist es zudem auch noch. ;)

Und was Kepler angeht, so würde ein Verzicht auf die Hotclock und dramatische Steigerung der Einheitenzahl auf die ersten Schritte in diese Richtung hindeuten. Aber sicher nicht alle, immerhin Ist Einstein dort Maxwell+2, dafür müssen die sich ja noch was übrig lassen.

[OgrEGT]

Ja! Genau!
Zumindest definiert Dir dies Deinen Energieverbrauch und Effizienz ist Leistung/Energieverbrauch. Also es geht exakt darum, den Stromverbrauch der Datentransfers zu senken bzw. die Distanz des Transfers möglichst kurz zu halten, weil Dir dies die Effizienz erhöht, egal ob man damit weniger Performance pro verbautem Flop erreicht oder nicht. Genau darum ging es in dem Vortrag!

Jetzt verstanden?

Also:
- Gesamt-Performance steigt, aber nicht in dem Maß wie Flops steigen aufgrund des limitierenden Powerbudgets
- Perf/Flops sinkt weil
- Flops steigen aufgrund von mehr (einfacheren) Recheneinheiten,
- Leistungsaufnahme bleibt innerhalb eines bestimmten Budgets durch Fokus auf Einsparungen bei Verlustleistung durch unnötigen Datentransfer, deshalb
- Perf/W steigt ebenfalls.

Korrekt?

[Knuddelbearli]

Also:
- Gesamt-Performance steigt, aber nicht in dem Maß wie Flops steigen aufgrund des limitierenden Powerbudgets
- Perf/Flops sinkt weil
- Flops steigen aufgrund von mehr (einfacheren) Recheneinheiten,
- Leistungsaufnahme bleibt innerhalb eines bestimmten Budgets durch Fokus auf Einsparungen bei Verlustleistung durch unnötigen Datentransfer, deshalb
- Perf/W steigt ebenfalls.

Korrekt?

ja

[=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...

[=Floi=]

mit was willst du denn die "mehr einheiten" denn bauen? lego?
schon bei fermi stand man nicht durch die leistungsaufnahme an, sondern durch das transistoren-budget und die dadurch resultierende chipgröße!
hotclock und die jetzige architektur sind auch auch deswegen entstanden, weil dies der beste weg war und imho auch ist. ein neuer weg muß sich erst mal als umsetzbar erweisen.

[AwesomeSauce]

schon bei fermi stand man nicht durch die leistungsaufnahme an, sondern durch das transistoren-budget und die dadurch resultierende chipgröße!
Definitiv nein!

[Skysnake]

Immer auch eine Sache der Kosten.

[Gipsel]

Weil man die Cores aber einfacher macht, die Kommunikation reduziert etc. Wird die Gefahr/Anfälligkeit bei Applikationen, die eine geringe Datenlokalität haben, größer. Dort wird man dann halt wahrscheinlich noch stärker einbrechen, als man das heute schon macht.Dem versuchen die bei den Echelon-Modulen mit den 256 MB onchip-Cache entgegenzuwirken, den man im Prinzip selber hierarchisch konfigurieren kann (um die Datenlokalität nachzubilden und so Transfers über große Distanzen zu minimieren). Und hier kommen wohl auch wieder diese Autotuning-Tools ins Spiel. Das muß halt funktionieren damit es funktoniert oder so ähnlich. Die haben ja auch noch ein paar Jährchen Zeit, um daran zu basteln. ;)

[Skysnake]

Jetzt fühl ich mich doof.
Musste nicht. Ich mein damit wirklich nur Leute, die sich wirklich durch Studium/Beruf damit auseinander setzen müssen und auch ansonsten ein breites Hintergrundwissen zu früheren Architekturen, und vielem mehr haben. Nur für die ist es einfach klar.

Die Sache an Sich ist aber nicht konzeptionell schwer zu verstehen und auch nachvollziehen, wenn man ihm ein paar Sachen erklärt, wie was läuft und wo die Probleme sind. Gerade die Sache mit dem Datentransfer on Chip, und VOR ALLEM off chip, sind da so Sachen.

Dem versuchen die bei den Echelon-Modulen mit den 256 MB onchip-Cache entgegenzuwirken, den man im Prinzip selber hierarchisch konfigurieren kann (um die Datenlokalität nachzubilden und so Transfers über große Distanzen zu minimieren). Und hier kommen wohl auch wieder diese Autotuning-Tools ins Spiel. Das muß halt funktionieren damit es funktoniert oder so ähnlich. Die haben ja auch noch ein paar Jährchen Zeit, um daran zu basteln. ;)
Halt Standardkost. Man unterteilt die Caches und fügt neue hinzu.

256 ist aber schon ein ziemlicher Brocken und der Schritt in die richtige Richtung. Mir wäre es aber lieber, wenn Sie es GLEICH! richtig machen würden, und den gesamten RAM näher zum Chip packen würden. Also per Interposer und gut ist.

Vom Chip runter, über das Packaging, übers PCP, auf das Packaging, auf den Chip drauf und wieder zurück kostet einfach abartig viel Strom. Der Faktor 1000 war ja laut dem Video richtig, den ich schon vorher mal hier genannt hatte. (Aussage von nem Prof dieses Semester, hatte ich aber auch schon vorher z.B. zur SC letztes Jahr gehört.)

Die Sache mit den Tool versteh ich aber nicht so wirklich ganz Gipsel. Vielleicht kannst du mir dabei helfen das zu verstehen durch einen anderen Blickwinkel.

Für mich stellt sich das halt so dar:

Die Tools sollen die Lokalität analysieren, und dafür sorgen, dass die Daten so wenig bewegt werden wie möglich, bzw. halt am Energieeffizientesten. Um das zu machen, muss ich aber den zukünftigen Programmablauf kennen, denn wie soll ich denn das sonst entscheiden? (Von heutigen Programmiermodellen ausgehend)

Das Problem ist doch an einer n-body-Simulation schön zu sehen. Ich hab zwar immer das gleiche Programm, die Datenabhängigkeiten ändern sich aber und sind nicht vorhersagbar. Die Aufteilung, die in einem Durchlauf super toll funktioniert, kann in einem anderen nicht mehr so toll sein (Ich denke dabei an den Brans-Head-Algorithmus). Naja und so gehts halt grad weiter.

Zudem muss auch im Fall einer "trivialen" Implementierung, wo man einfach immer alle Kräfte berechnet, doch verdammt viel berücksichtigt werden, und dabei würde man ja die gesamte Karte für sich exklusiv haben. Wenn jetzt gleichzeitg da noch was anders läuft wie irgend was für den Browser etc. dann wird das noch viel viel viel viel komplizierter.

Ich seh da eigentlich keine Chance, ohne compiler Pragmas etc. den tools einen Tip zu geben, was Sie machen sollen. Damit wären wir aber nicht wirklich viel weiter als heute, und wie "gut" das funktioniert, sehen wir ja....

[Shakti]

Keine Ahnung vom Thema, nur als Frage\Hinweis, ueberall steht Echelon, nur in eurem Artikel steht ueberall Echolon?

[Gipsel]

Keine Ahnung vom Thema, nur als Frage\Hinweis, ueberall steht Echelon, nur in eurem Artikel steht ueberall Echolon?
:confused:
Wo steht das?

[Godmode]

:confused:
Wo steht das?

Naja auf der Hauptseite, in dem neuen Artikel.

[Gipsel]

Naja auf der Hauptseite, in dem neuen Artikel.
Da hat sich Leo offensichtlich verschrieben.

[Gipsel]

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.

Und wieder mal was Neues (http://research.nvidia.com/sites/default/files/publications/IEEE_Micro_2011.pdf). Es bestätigt, daß Echelon/Einstein kein SIMD machen muß, sondern praktisch (wahrscheinlich sehr häufig) nur so durch die Software konfiguriert werden kann (aber nicht muß, die Vektorlänge ist also variabel und im Minimum 1).

Weiterhin geht man weg vom dynamischen Issue (kostet wohl zuviel Strom) sondern macht "LIW", also fast VLIW, aber eben mit Instruktionen bestehend aus genau 3 Operationen (statt 4 oder 5 wie bei AMDs VLIW-Architekturen).

Eine Instruktion besteht dabei aus zwei arithmetischen Befehlen und einer L/S Operation. Allerdings nur bei double precision. Bei SP (Echelon macht SP mit 2:1 Rate) funktioniert es wie ein Mini-SIMD, also die Operation in einem LIW-Slot arbeitet auf zwei SP-Werten. Maximal können also vier SP-Operationen und ein L/S-Operation pro Takt und Lane ausgeführt werden. Ist gewissermaßen ein etwas vereinfachtes VLIW5. :wink:
Na das ist doch mal eine Information!

[Hübie]

Öhm. Ja hier wurde ja lang nix gesagt. Ich habe gerade Leerlauf und denke mal etwas über Maxwell nach. Welche Aufgaben neben der Thread-Zuordnung, Sicherheitsabfragen könnte so ein ARM-Core noch übernehmen? Sind die Latenzen schnell genug um bspw. einzelne GPC auf das powertarget hin zu überwachen und zu steuern? Oder noch krasser einzelne SMX in den GPCs schlafen legen, hoch-/runtertakten etc...
Oder sind die Schaltzeiten zu "träge"?

[Skysnake]

Sollte gehen, in ner CPU von AMD reichts ja auch dafür :ugly:

Die ARM-Cores sind aber eher für so Sachen wie MPI interessant.

[ux-3]

Ich klickte eben den Thread an, überrascht und erwartungsfroh, eine Physik-Diskussion über die Entwicklung des Lichtäthers zu lesen, und dann sowas! Nennt es doch wenigstens Chipentwicklung! :P

[gnahr]

is ja kein powi-unrat. :P
tegra hat einen asymetrischen core für kleinkram bekommen (input-erkennungs-verbesserung, power-managment, ...) und für einstein ist es auch angesagt... sehr schön. bald besteht der restliche pc nur noch aus nem netzteil und dem massenspeicher wenn grakas nicht nur c nativ ausführen können und bunte klötzchen an den monitor redigieren.

[-/\-CruNcher-/\-]

Als ich DARPA und Echelon gelesen hab da frag ich mich ob sie das ironisch meinen mit dem Codenamen :P

Immerhin war Echelon das Telekomunikations Abhörsystem der NSA und des GCHQ http://de.wikipedia.org/wiki/Echelon :)

Denke mal damit wollen sie ihren eigenen Überwachunscluster erweitern da kommt der name Echelon für den Chip schon supi rüber der alten zeiten wegen ;)
Im Vergleich zu den 8 Gflops die ein Echelon TMS DSP geschaft hat ist das schon ein recht üppiger gewinn mit 20 Tflops sieht man aber wie Daten immer Komplexer werden und deren Semantische Auswertung dadurch auch in der Komplexität steigt und wie das dann erst 2018 aussehen muss ist es Quasi aber nur das mitgehen mit der Zeit ;)

[kunibätt]

Aha :D