nVidia - Next Gen Architekturen Maxwell and beyond [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : nVidia - Next Gen Architekturen Maxwell and beyond

Gipsel

2012-01-06, 15:00:08

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

2012-01-06, 16:29:05

Godmode

2012-01-06, 16:50:50

LovesuckZ

2012-01-06, 17:24:22

Skysnake

2012-01-06, 17:33:09

ähm doch....

Schaus dir nochmal in Ruhe an.

Kurz zusammengefasst. Geh mehr von den fat-cores weg hin zu den simplen Einheiten. Nimm das zentrale Registerfile, was für Probleme mit geringer Datenlokalität nice ist, weg und mach verteilte daraus. Da wird dann einfach akzeptiert, das in solchen Fällen man schlicht Pech hat, wenn dann die Performance nicht so stark steigt oder gar zurück geht.

nVidia geht da schon sehr stark in die Richtung, die AMD schon lange verfolgt.

Am witzigsten ist aber das rumgereite auf Hardwareunabhängigkeit ;D Wie man plötzlich nichts mehr von propritären Sachen wissen will....

Die Sache mit den "dunklen Chips" solltet ihr euch auch nochmals zu Gemüte führen. Das ist eine WICHTIGE! Sache. Hust APU Hust SoC Hust bye bye dezidierte Komponenten Hust.

LovesuckZ

2012-01-06, 17:40:02

ähm doch....

Schaus dir nochmal in Ruhe an.

Kurz zusammengefasst. Geh mehr von den fat-cores weg hin zu den simplen Einheiten. Nimm das zentrale Registerfile, was für Probleme mit geringer Datenlokalität nice ist, weg und mach verteilte daraus. Da wird dann einfach akzeptiert, das in solchen Fällen man schlicht Pech hat, wenn dann die Performance nicht so stark steigt oder gar zurück geht.

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

Nighthawk13

2012-01-06, 18:01:02

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

LovesuckZ

2012-01-06, 18:05:12

Ja, "our Oldschool Fermi architecture". :D

Hugo78

2012-01-06, 18:21:27

Wenn man schon an der Gen, drei Gens weiter bastelt, darf man Fermi auch als Old School bezeichnen. :D

Skysnake

2012-01-06, 18:24:39

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

2012-01-06, 18:31:37

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:

LovesuckZ

2012-01-06, 18:37:08

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.

Unglaublich - du hast den ersten Teil des Vortrages überhaupt nicht verstanden. :eek:

Bin ich der einzige hier, der sich fragt, wie man

Leistung = Effizienz

nicht verstehen kann und wie eine Leistungssteigerung durch

Leistung = Effizienz - Effizienzverlust

zu stande kommen würde?

boxleitnerb

2012-01-06, 18:44:49

Äh, ich glaube du hast was nicht verstanden:

Es gibt mehrere Arten von Effizienz. Beispiel:

Chip A, Performance 100% bei 512 Einheiten bei Takt X. Verbrauch 250W
Chip B, Performance 180% bei 2048 Einheiten bei Takt 0,6*X. Verbrauch 250W
(Performance in Spielen).

B hat 1,8x Perf/W von Chip A. Aber da er 2,4x die Rechenleistung hat, sinkt die Effizienz im Bezug auf die vorhandene Rohleistung.
Schau doch die aktuellen Spekulationen an. GK104 mit weitaus mehr als 2TF, nimm mal 2,5TF an. Das sind knappe 50% mehr "Bums". Wird GK104 deshalb 50% flotter als GF110? Nö, sondern nur (anscheinend) gute 10%.

LovesuckZ

2012-01-06, 18:52:31

Gipsel

2012-01-06, 18:56:52

Unglaublich - du hast den ersten Teil des Vortrages überhaupt nicht verstanden. :eek:Der komplette Tenor des Vortrags geht in die andere Richtung, als Du es behauptest. :rolleyes:

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

Bin ich der einzige hier, der sich fragt, wie man

Leistung = Effizienz

nicht verstehen kann und wie eine Leistungssteigerung durch

Leistung = Effizienz - Effizienzverlust

zu stande kommen würde?
Du bist offenbar der Einzige, der da zwei verschiedene Sachen in einen Topf wirft, wie boxleitnerb gerade noch einmal (und andere auch schon vorher) geschrieben hat.

Gipsel

2012-01-06, 18:59:49

Na, das hat mit dem Thema von Daily nichts zu tun. Um in "Spielen" eine annährend 1:1 Skalierung hinzubekommen, muss jede mögliche Latenz reduziert werden. ;)Und gerade das machen GPUs nicht, weil man da unweigerlich schlechter in der zukünftig praktisch alles bestimmenden Metrik Performance/Watt wird. Das machen allerdings CPUs.

Nicht vergessen: NVidia nennt CPU-Kerne dort nicht umsonst "latency optimized cores", während die SMs "throughput optimized cores" sind. ;)

LovesuckZ

2012-01-06, 19:12:30

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

...

Äh, hä? Du hast schon zugehört, dass Daily in 8 Jahren zu heute folgendes haben will:

100x Leistung = 100x Effizienz

Beim Vortrag handelt es sich über den Weg zum Exascale-System. Welche Einheit ist wohl maßgeblich für die Bezeichnung? Der Stromverbrauch beim Datentransfer?

Und Daily sagt es: "More work per data-unit per data transfer". Sein "it's not about the FLOPs" bezieht sich darauf, dass die Berechnungen nicht der limitierende Faktor sind, sondern "Data movement" eine bedeutende Rolle einnehmen. Denn dadurch definiert sich laut ihm am stärksten der Verbrauch des Chips. Weniger Datenbewegungen ist gleichbedeutend mit weniger Stromverbrauch. Und dadurch mehr Ressourcen für mehr Einheiten oder höhrere Taktfrequenzen.

Ja, ich habe es verstanden.

Und gerade das machen GPUs nicht, weil man da unweigerlich schlechter in der zukünftig praktisch alles bestimmenden Metrik Performance/Watt wird. Das machen allerdings CPUs.

Nicht vergessen: NVidia nennt CPU-Kerne dort nicht umsonst "latency optimized cores", während die SMs "throughput optimized cores" sind. ;)

Es handelt sich hier um die API-bezogene Latenz.

/edit: Folie 27 zeigt es doch sehr eindeutig, über was Daily die ganze redet: Dem Gesamtverbrauch einer "Instruction":

http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=41626&stc=1&d=1325874409

Gipsel

2012-01-06, 19:24:11

...

Äh, hä? Du hast schon zugehört, dass Daily in 8 Jahren zu heute folgendes haben will:

100x Leistung = 100x Effizienz

Beim Vortrag handelt es sich über den Weg zum Exascale-System. Welche Einheit ist wohl maßgeblich für die Bezeichnung? Der Stromverbrauch beim Datentransfer?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?

Aquaschaf

2012-01-06, 19:25:56

Na, das hat mit dem Thema von Daily nichts zu tun. Um in "Spielen" eine annährend 1:1 Skalierung hinzubekommen, muss jede mögliche Latenz reduziert werden. ;)

Wie kommst du denn auf diesen komischen Schluss? Die Arbeit die bei Spielen anfällt ist Bilder in einer interaktiven Rate zu produzieren. D.h. man hat mehrere Millisekunden Zeit um einen Block an gut parallelisierbarer Arbeit zu erledigen. Mehrere Millisekunden sind eine Größenordnung bei der der trade-off zwischen Latenz und Durchsatz unmissverständlich zugunsten des Durchsatzes ausfällt. Jede GPU befindet sich im Raum der möglichen Prozessorarchitekturen in der Kategorie: hohe Latenzen, aber dafür hoher Durchsatz.

Gipsel

2012-01-06, 19:43:28

Um in "Spielen" eine annährend 1:1 Skalierung hinzubekommen, muss jede mögliche Latenz reduziert werden. ;)Und gerade das machen GPUs nicht, weil man da unweigerlich schlechter in der zukünftig praktisch alles bestimmenden Metrik Performance/Watt wird. Das machen allerdings CPUs.
Es handelt sich hier um die API-bezogene Latenz.:confused:
Ich habe gerade den starken Verdacht, Du weißt gar nicht, was oder worüber Du überhaupt schreibst.

LovesuckZ

2012-01-06, 19:45:37

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?

Nein, das ist einfach falsch.
Vielleicht verstehst du es mit Berechnungen besser - Leistung / Stromverbrauch

nVidia's Ziel für 2020 ist 1 Exaflop / 20 MW.

Laut nVidia erreiche man dies bei Beibehaltungen der heutigen Entwicklung entweder erst 203x oder mit 1 Exaflop / x GW (ich glaube 2 wurden genannt).

Siehst du, was die Konstante in beiden Rechnungen ist? Die Leistung. Die Leistung pro Flop bleibt (soll) gleich (bleiben). Der ganze Vortrag handelt davon, wie man per Architektur die Voraussetzungen schaffen kann, dass der Gesamtverbrauch pro Berechnung sinkt.

Viel einfacher kann ich es dir nicht mehr erklären.

:confused:
Ich habe gerade den starken Verdacht, Du weißt gar nicht, was oder worüber Du überhaupt schreibst.

Vielleicht solltest du dich nicht einmischen, wenn du meinen Kommentar auf den von boxleitnerb nicht verstanden hast. Er spricht nämlich von Spiele. Und wie wir dort wissen, ist die Rechenleistung eben nicht der einzige entscheidene Faktor für die Anzahl der Bilder pro Sekunde.

Gipsel

2012-01-06, 19:48:03

LS, laß es lieber sein, ist ein wirklich gut gemeinter Tipp. :)

LovesuckZ

2012-01-06, 19:56:56

LS, laß es lieber sein, ist ein wirklich gut gemeinter Tipp. :)

Nein, ich denke, wir sollten das weiter bereden, Immerhin wird uns das Thema bei Kepler, Maxwell und Co weiterhin begleiten. Daher ist es wichtig zu sehen, wieso du die Problematik nicht verstanden hast.

In keiner der Keynotes, Aussagen oder Vorträge geht es um eine Verschlechterung der Leistung. Wie kommst du also zum Schluss, dass die Leistung der zukünftigen Produkte sinken wird? Immerhin hat nVidia in keiner Person von einer Senkung des Stromverbrauches für die Zukunft geredet.

guest_29132

2012-01-06, 21:11:06

Wie kommst du also zum Schluss, dass die Leistung der zukünftigen Produkte sinken wird?

http://www.forum-3dcenter.org/vbulletin/images/smilies/upicard.gif

Gipsel

2012-01-06, 21:38:44

LovesuckZ

2012-01-06, 22:07:56

Tja, was soll man da noch schreiben ... :freak:

LS, wie schon gesagt, tue Dir selbst einen Gefallen und lege lieber mal eine kurze Postingpause hier ein. Schlaf Dich aus und lies Dir danach noch mal ein paar Posts von anderen Leuten (z.B. Aquaschaf oder boxleitnerb, falls Dir meine nicht gefallen) hier durch und überdenke die auch, bevor Du später Dein fortgesetztes Posten vielleicht mal bereust.

Wäre wirklich in Deinem eigenen Interesse und ein wohlgemeinter Ratschlag.

Gipsel,
der einzige, der hier was bereut, bist doch du. Deine Aussagen über nVidia sind meistens falsch. Daher auch die Zensur. ;)

Aber ich will hier in diesem Thread über Kepler und Co reden. Also wäre es nett, wenn du bitte beim Thema bleibst. Dally spricht in seinem Vortrag nicht über Spiele. Welchen Stellenwert hat also das Posting von boxleitnerb für die Aussagen von Dally? Richtig, erstmal keinen. Schön, dass du dies ignorierst, nichts anderes ist von dir zu erwarten. :)

Das nVidia in Zukunft simple Cores verbauen wird, ist nicht neu. Das hat auch schon Steve Scott gesagt. Davon werden es jedoch sehr, sehr viele. Das wissen wir schon.

Das lustige ist, dass du anscheinend nicht den Kontext des Themas von Dally verstanden hast. Fläche sei nämlich kein limitierender Faktor mehr. Das heißt, wenn nVidia den Stromverbrauch durch Data-Movement und Vereinfachung senkt, dann können sie mehr Cores verbauen und dadurch deutlich mehr Rechenleistung erreichen.

Deine Aussagen sind daher, wie meisten über nVidia, falsch. Es geht in Zukunft nämlich einzig um FLOPs. Aber um das zu erreichen, muss der Gesamtstromverbrauch pro Berechnung/Anweisung/Instruction gesenkt werden. Du siehst, das Ziel ist interessant und nicht der Weg.

Daher Gipsel:

tue Dir selbst einen Gefallen und lege lieber mal eine kurze Postingpause hier ein. Schlaf Dich aus und lies Dir danach noch mal ein paar Posts von anderen Leuten [...], falls Dir meine nicht gefallen) hier durch und überdenke die auch, bevor Du später Dein fortgesetztes Posten vielleicht mal bereust.

:)

/edit: Achja, Dally spricht einzig über Leistung in seinem Vortrag. Das Ziel ist ein "100x performance increase in 10 years":
http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=41629&stc=1&d=1325885007

Und nein, ich diskutiere nicht seitenlang darum, dass "Performance" Leistung und nicht Markteinteilung bedeutet.

AwesomeSauce

2012-01-06, 22:31:43

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.

LovesuckZ

2012-01-06, 22:45:09

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.

Einstein ist die GPU-Architektur für das Echelon-Projekt.

Gipsel

2012-01-06, 22:51:01

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.

Knuddelbearli

2012-01-06, 22:56:50

Einstein ist die GPU-Architektur für das Echelon-Projekt.

und dafür gibt es einen eigenen THread wo du dich asutoben kannst ...

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=512733

OgrEGT

2012-01-06, 22:58:23

LovesuckZ

2012-01-06, 23:00:04

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

Liegt daran, dass die Effizienz pro Einheit gesteigert wird. ;)
Höre dir den Teil zum L0 Cache an. Sie opfern keine Leistung, die implementieren einen zusätzlichen Cache, der zu einem "huge energy saving" beitragen soll. Vergleichbar mit dem 5. A9 Kern von Tegra.

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?

FLOP/s ist ein Leistungsmaßstab. Perf/Flops macht daher kein Sinn und ist redundant.

Knuddelbearli

2012-01-06, 23:09:38

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

Hugo78

2012-01-06, 23:20:51

Ein FLOP ist ein FLOP.
Es steigt oder fällt ja auch nicht die Länge pro Meter. *g*

OgrEGT

2012-01-06, 23:26:04

Liegt daran, dass die Effizienz pro Einheit gesteigert wird. ;)
Höre dir den Teil zum L0 Cache an. Sie opfern keine Leistung, die implementieren einen zusätzlichen Cache, der zu einem "huge energy saving" beitragen soll. Vergleichbar mit dem 5. A9 Kern von Tegra.

FLOP/s ist ein Leistungsmaßstab. Perf/Flops macht daher kein Sinn und ist redundant.

Perf/Peak-Flops

Edit: Bedeutet, dass pro Leistungsäquivalent immer mehr theoretische Rohleistung erforderlich sein wird.

boxleitnerb

2012-01-06, 23:27:23

Perf/Peak-Flops

Von was für Perf reden wir hier? Spiele oder Passwortknacken und Co?

OgrEGT

2012-01-06, 23:28:22

Von was für Perf reden wir hier? Spiele oder Passwortknacken und Co?

Von letzterem.

LovesuckZ

2012-01-06, 23:39:07

Perf/Peak-Flops

Edit: Bedeutet, dass pro Leistungsäquivalent immer mehr theoretische Rohleistung erforderlich sein wird.

Das Problem ergibt sich zwangsläufig aus mehr Kernen. Wir reden hier von massiv viel mehr Recheneinheiten.

Nur muss man im Hinterkopf behalten, dass durch die Vereinfachung der Stromverbrauch deutlich stärker sinkt als der Leistungsverlust durch den Umbau. Im Umkehrschluss kann man so mehr Einheiten oder eine höhrere Taktfrequenz fahren. Somit gleich sich der Nachteil aus oder wird sogar zu einem Vorteil.

Gipsel

2012-01-07, 00:07:35

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.Sry Gipsel, aber das ist falsch und hat Daily nicht gesagt.

Die Leistung pro Flop bleibt (soll) gleich (bleiben).
Nirgendwo behauptet Daily, dass man in Zukunft Leistung opfern werde, um mehr Leistung zu erreichen (was für ein Paradoxon).
Nein das ist keins und genau das sagt Dally dort.
Nur muss man im Hinterkopf behalten, dass durch die Vereinfachung der Stromverbrauch deutlich stärker sinkt als der Leistungsverlust durch den Umbau. Im Umkehrschluss kann man so mehr Einheiten oder eine höhrere Taktfrequenz fahren. Somit gleich sich der Nachteil aus oder wird sogar zu einem Vorteil.
Jetzt also doch? ;D SCNR

Im Übrigen wird es gar nicht so viel einfacher, es gibt mehr Hierarchie, es wird anders.

=Floi=

2012-01-07, 00:11:00

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

2012-01-07, 00:14:56

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

LovesuckZ

2012-01-07, 00:19:27

Jetzt also doch? ;D SCNR

Ich habe das doch nie beschritten, Gipsel.
Ich habe dir dagegen vorgeworfen, dass du nicht verstanden hast, dass nVidia keine Kompromisse in Bezug auf "nutzbare Leistung" eingehen wird. Das, was sie durch die Änderungen an Strom weniger verbrauchen, wird sofort in mehr Einheiten und/oder höheren Takt investiert. Dadurch steigt die "nutzbare Leistung" deutlich an. Gleichzeitig ist doch der zweite Teil von Dally's Vortrag genau auf die Verringerung des Unterschiedes zwischen "nutzbarer Leistung" und "Peak-Leistung" gerichtet. Je geringer der Unterschied, umso leichter ist das Ziel zu erreichen.

Gipsel

2012-01-07, 00:25:01

Ich habe das doch nie beschritten, Gipsel.Sorry, doch das hast Du. Lies Deine eigenen Beiträge! Ich muß die hier doch wohl nicht alle quoten und damit den Thread zumüllen, oder?
Wie gesagt, laß es gut sein, jetzt haben wir es ja.

Wenn Du Dich darüber weiter austauschen willst, gerne per PN.

Gute Nacht!

LovesuckZ

2012-01-07, 00:45:20

Sorry, doch das hast Du. Lies Deine eigenen Beiträge! Ich muß die hier doch wohl nicht alle quoten und damit den Thread zumüllen, oder?
Wie gesagt, laß es gut sein, jetzt haben wir es ja.

Wenn Du Dich darüber weiter austauschen willst, gerne per PN.

Gute Nacht!

Nein, ich habe nie gesagt, dass die Leistung der Produkte sinken wird. Du hast meine Postings entsprechend falsch verstanden. Den einzigen Kompromis, den nVidia eingeht, ist die eigengesetzte Beschränkung auf Verbrauchlimits - z.B. 250 Watt.

Dally sagt es doch sehr eindeutig und unmissverständlich:
Leistung = Effizienz

Der Sinn hinter der Architekturänderung ist eine deutliche Senkung des Stromverbrauchs bei der Berechnung einer Gleitkommazahl-Operationen gegenüber einer eventuellen längeren Berechnungsdauer. Nur dadurch steigt die Effizienz der Architektur und damit auch die mögliche Maximalleistung im Verbrauchslimit.

Denn was bringt ein geringerer Abstand zwischen "nutzbarer" und "Peak"-Leistung, wenn die maximale Nutzleistung deutlich unter der von anderen Architekturen liegt? Genau, nichts.

nVidia geht keine Kompromisse in Bezug auf Leistung ein. Die Architektur wird auch nicht ineffizienter. Und das hast du hier propagiert, Gipsel. Das Problem ist, du hast eben nicht den Kontext verstanden, auf den du geantwortet hast. Und das habe ich dir versucht anhand der Präsentation von Dally auch nochmal zu zeigen. Aber anscheinend war es vergebens, schade.

guest_29132

2012-01-07, 00:55:18

Wie kommst du also zum Schluss, dass die Leistung der zukünftigen Produkte sinken wird?
http://www.forum-3dcenter.org/vbulletin/images/smilies/upicard.gif
Nein, ich habe nie gesagt, dass die Leistung der Produkte sinken wird.

Aber auch sonst, so im allgemeinen, bist du ein ziemlich komischer Typ.
Im Sinne von eigenartig, nicht witzig.

Distroia

2012-01-07, 01:02:52

So langsam weiß ich auch nicht mehr, ob ich lachen oder Mitleid haben soll.

LovesuckZ

2012-01-07, 01:13:06

Aber auch sonst, so im allgemeinen, bist du ein ziemlich komischer Typ.
Im Sinne von eigenartig, nicht witzig.

Dein Besuch soll nicht umsonst gewesen sein, hiermal die Definition von Kompromiss:
Vereinbarung, bei der alle Beteiligten einige Aspekte ihrer Vorstellungen aufgegeben haben, um zu einer Entscheidung zu kommen
http://de.wiktionary.org/wiki/Kompromiss

Der Kompromiss ist also nicht der eventuell größer werden Abstand zwischen "nutzbarer" und "Peak"-Leistung, sondern die Limitierung durch den Stromverbrauch und der heutigen Architektur. Man legt sich auf Verbrauchlimits fest und muss daher einen anderen Weg einschlagen, um seine gesteckten Ziele erreichen zu können.

Gipsel propagiert, dass der Kompromiss bei der Architekturänderung keinen positiven Effekt auf die Effizienz haben werde, also unabhängig vom Shrink. Dabei wird der Kontext einfach mal so ignoriert. Dally hat doch folgendes klar und eindeutig gesagt:

In 10 Jahre = 100 x Performance von heute
Performance = Effizienz

=> in 10 Jahren = 100 x Effizienz von heute

Es ist offensichtlich, dass die Veränderungen der Architekturen zu einer deutlichen Leistungssteigerung führen sollen. Das ist nicht die Definition von Kompromiss.

Einfaches Problem, anscheinend schweres Verständnis.

HarryHirsch

2012-01-07, 01:20:44

Vereinbarung, bei der alle Beteiligten einige Aspekte ihrer Vorstellungen aufgegeben haben, um zu einer Entscheidung zu kommen

ich kann nicht mehr :freak:

Skysnake

2012-01-07, 01:30:08

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:
....
Dir ist offensichtlich nicht klar, über was für "tools" er, und damit ich rede. Das sind tools zur Optimierung deines Codes, und zu dessen analyse. So was wie der Perf.Inspector, oder wie sich das tool noch mals von nVidia nennt. Oder wie der gDEBugger. Nur das die Dinger VIEL VIEL intelligenter sein sollen. Hör dir bitte das Ende des Videos nochmals an. Da erklärt er anhand der Metriken, was er für tools meint. Stichpunkt Students Hand optimized Code vs. tool optimization.

Gipsel,
der einzige, der hier was bereut, bist doch du. Deine Aussagen über nVidia sind meistens falsch. Daher auch die Zensur. ;)

Aber ich will hier in diesem Thread über Kepler und Co reden. Also wäre es nett, wenn du bitte beim Thema bleibst. Dally spricht in seinem Vortrag nicht über Spiele. Welchen Stellenwert hat also das Posting von boxleitnerb für die Aussagen von Dally? Richtig, erstmal keinen. Schön, dass du dies ignorierst, nichts anderes ist von dir zu erwarten. :)

Das nVidia in Zukunft simple Cores verbauen wird, ist nicht neu. Das hat auch schon Steve Scott gesagt. Davon werden es jedoch sehr, sehr viele. Das wissen wir schon.

Das lustige ist, dass du anscheinend nicht den Kontext des Themas von Dally verstanden hast. Fläche sei nämlich kein limitierender Faktor mehr. Das heißt, wenn nVidia den Stromverbrauch durch Data-Movement und Vereinfachung senkt, dann können sie mehr Cores verbauen und dadurch deutlich mehr Rechenleistung erreichen.

Deine Aussagen sind daher, wie meisten über nVidia, falsch. Es geht in Zukunft nämlich einzig um FLOPs. Aber um das zu erreichen, muss der Gesamtstromverbrauch pro Berechnung/Anweisung/Instruction gesenkt werden. Du siehst, das Ziel ist interessant und nicht der Weg.

Daher Gipsel:

:)

/edit: Achja, Dally spricht einzig über Leistung in seinem Vortrag. Das Ziel ist ein "100x performance increase in 10 years":
http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=41629&stc=1&d=1325885007

Und nein, ich diskutiere nicht seitenlang darum, dass "Performance" Leistung und nicht Markteinteilung bedeutet.
LZ lass es gut sein, du verstehst nicht mal im Ansatz die Problematik, die in dem Vortrag angesprochen wird. Mit jeder Aussage die du tätigst unterstreichst du das noch...

Die Nutzleistung (Preformance) sinkt im Vergleich zur theoretischen Rechenleistung. Daher sinkt die Effizienz der Architektur. Die Perf/W steigt aber, da man auf Durchsatz geht, und einem der Rest ziemlich Jacke wie Hose ist.

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.

Bzgl. der Leistung pro Instructionen, die du auch vom Stapel gelassen hast, die Instructionen treten in den Hintergrund. Ob du jetzt eine oder 100 Instructionen brauchst ist egal. Hauptsache du verbrauchst wenig Energie um das Ergebnis zu bekommen. Wie du das erreichst ist egal.

Kurze Randnotiz:
Eventuell spricht das doch gegen SFUs. Die sind zwar viel Energieeffizienter, aber man muss die Daten eben erst mal zu ihnen bekommen. Das könnte dazu führen, das man am Ende sogar mehr Energie verbraucht, als wenn man es nicht SFUs berechnen lässt... Hm... Hatte ich noch gar nicht so betrachtet. Berechnungen kosten ja fast nichts.

Also:
- Gesamt-Performance steigt, aber nicht in dem Maß wie Flops steigen aufgrund des limitierenden Powerbudgets
- (Nutzleistung)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 haste so richtig verstanden.

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.
Oh doch. Fermi war schon power limited. Da wäre deutlich mehr gegangen, wenn man noch ein freies Powerbudget gehabt hätte. Das wird in Zukunft sogar noch viel schlimmer.

Sobald stacked Chips eingesetzt werden, haste ein Zichfaches an Platz, aber nicht mehr an Energie, die du verbraten kannst, da nicht kühlbar und nicht mit Strom zu versorgen über die Pins. IBM arbeitet aber an den Problemen, bzw. hat diese teils schon gelöst. Man muss aber dennoch berücksichtigen, das man möglichst viel effektive Rechenleistung aus jedem Watt pressen muss.

Nein, ich habe nie gesagt, dass die Leistung der Produkte sinken wird. Du hast meine Postings entsprechend falsch verstanden. Den einzigen Kompromis, den nVidia eingeht, ist die eigengesetzte Beschränkung auf Verbrauchlimits - z.B. 250 Watt.

Dally sagt es doch sehr eindeutig und unmissverständlich:
Leistung = Effizienz

Der Sinn hinter der Architekturänderung ist eine deutliche Senkung des Stromverbrauchs bei der Berechnung einer Gleitkommazahl-Operationen gegenüber einer eventuellen längeren Berechnungsdauer. Nur dadurch steigt die Effizienz der Architektur und damit auch die mögliche Maximalleistung im Verbrauchslimit.

Denn was bringt ein geringerer Abstand zwischen "nutzbarer" und "Peak"-Leistung, wenn die maximale Nutzleistung deutlich unter der von anderen Architekturen liegt? Genau, nichts.
Gz. Du hast endlich das begriffen, was ich dir schon vor einigen Seiten erklärt habe.

nVidia geht keine Kompromisse in Bezug auf Leistung ein. Die Architektur wird auch nicht ineffizienter. Und das hast du hier propagiert, Gipsel. Das Problem ist, du hast eben nicht den Kontext verstanden, auf den du geantwortet hast. Und das habe ich dir versucht anhand der Präsentation von Dally auch nochmal zu zeigen. Aber anscheinend war es vergebens, schade.
Doch Sie wird ineffizienter mit der zur verfügung stehenden theoretischen Rechenleistung umgehen. Dafür aber Effizienter mit der zur verfügung gestellen Energie.

Und Gipsel hat in keinem seiner Posts etwas falsches gesagt. Du hast es nur nich verstanden, weil du die ganze Thematik nicht durchdrungen hattest. Les dir die Posts nochmal in Ruhe durch, dann wirst du auch merken, das du einiges falsch/nicht verstanden hattest.

Ich finds aber noch immer irgendwie lächerlich, wie er das aufbläst in dem Vortrag. Das ist praktisch schon ein alter Hut. Jedem, der sich in dem Umfeld rum treibt, sollte das schon klar sein. Auf der vorletzten oder gar vorvorletzten SuperComputer war das ein großes Thema. Seit dem habe ich mich damit auch schon beschäftigt, und das was er da erzählt hat ist schon wirklich Oberflächlich. Zumal das ja kein Vortrag vor Studenten war.... Da sollte man schon etwas produktives bringen, und nicht zum xten mal die bekannten Sachen wiederkeuen. Das war mehr ne PR-Veranstaltung als alles andere.

EDIT:
:facepalm:
LZ, geh schlafen bitte. Du wirst dich bald selbst darüber ärgern, was du hier im Eifer des Gefechts verbrochen hast.

Gipsel

2012-01-07, 01:35:22

LS, höre bitte auf! Das wäre wirklich zu Deinem Besten!

@all:
Bitte provoziert LS jetzt nicht noch! Danke.

Gipsel

2012-01-07, 01:43:38

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

Iruwen

2012-01-07, 01:44:27

Eigentlich sind das zwar recht offensichtliche und leicht zu verstehende Sachen

Jetzt fühl ich mich doof.

LovesuckZ

2012-01-07, 02:02:11

....
LZ lass es gut sein, du verstehst nicht mal im Ansatz die Problematik, die in dem Vortrag angesprochen wird. Mit jeder Aussage die du tätigst unterstreichst du das noch...

Ehrlich? Okay, gucken wir mal:

Die Nutzleistung (Preformance) sinkt im Vergleich zur theoretischen Rechenleistung. Daher sinkt die Effizienz der Architektur. Die Perf/W steigt aber, da man auf Durchsatz geht, und einem der Rest ziemlich Jacke wie Hose ist.

Effizienz kann nur im Zusammenhang mit eingebrachten Ressourcen stehen. Die Effizienz einer Architektur ergibt sich nicht auf der Auslastung der Einheiten. Denn ohne Aufwand kann ich die Einheiten sowieso ins unendliche skalieren und dann ist die Auslastung auch vollkommen belanglos...
In diesem Fall ist "Strom" die eingebrachte und vorallem limitierende Ressource. Steigt die nutzbare Leistung nun mit der neuen Architektur deutlich stärker an als sie es mit der alten getan hätte, verbessert sich natürlich auch die Effizienz - in unserem Fall eine Verbesserung des Perf/Watt Verhältnisses. Du hast also gerade bewiesen, dass du das angesprochende Problem von Dally nicht verstanden hast. Vielen Dank, dass du es mir dagegen vorwirfst...

Bzgl. der Leistung pro Instructionen, die du auch vom Stapel gelassen hast, die Instructionen treten in den Hintergrund. Ob du jetzt eine oder 100 Instructionen brauchst ist egal. Hauptsache du verbrauchst wenig Energie um das Ergebnis zu bekommen. Wie du das erreichst ist egal.

Guck an. Plötzlich ist also Effizienz ala "verbrauchst wenig Energie" doch entscheidend. Man, nächstes Mal einfach anderen nicht was vorwerfen, das dich selbst betrifft. Ja?

Gipsel

2012-01-07, 02:06:42

Jetzt ist Schluß hier mit dem Kram! Jeder kann sich selbst ein Bild machen. Ansonsten ist der Thread für eine Abkühlphase dicht! Klar?

Skysnake

2012-01-07, 02:07:18

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

Ailuros

2012-01-09, 03:39:09

Gipsel,

Ist es nicht besser wenn Du das wichtigste Material hier sammelst und einen thread damit im Technologie-forum ueber Maxwell und Einstein aufmachst?

Der Thread hier ist nicht nur voll von nutzlosem Muell, aber es wird auch kein besonderes Spekulations-Material bezueglich Maxwell in absehbarer Zeit geben. Bis zu Anfang/Mitte 2013 wird es noch einige Zeit dauern.

Gipsel

2012-01-09, 17:12:59

Wie von Ailuros vorgeschlagen, wurden die wichtigsten 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.