Kerndiskussion - breit oder schmal, wenige oder viele?

[Ge0rgy]

Hier ein Podium für die Diskuttanten die sich gerne über Skalierungseffekte, Multicore und den immerwährenden Disput zwischen wenigen "fetten" - Kernen kontra vielen, schlankeren auslassen.

Viel spaß

 

[mocad_tom]

Kommt auf den Applikationsmix an. Wenn er sehr spezifisch ist, gibt es Anwendungsfelder.

Wir unterhalten uns schon über eine "General Purpose CPU"?
Ich gehe davon aus, dass Bulldozer eine "General Purpose CPU" ist.

Vielleicht sind sie ja wirklich mit dem Schlachtplan in die Schlacht gezogen:
Zuerst Bulldozer:
Ein etwas schmalerer Kern (der auch leichter zu Validieren ist) da man überall genug Baustellen hat

Danach Piledriver:
An Punkten, die man fetter gestalten kann wird ausstaffiert, um die "Durchschitts-IPC" anzuheben.

Trinity hat ja auch nur zwei Piledriver-Module.
Während man von Istanbul zu Orochi geht, geht man von 6 Kerne auf 8 Int-Kerne.
Von Llano auf Trinity geht man aber von 4 Kerne auf 4 Int-Kerne.

Wann wird jetzt da endlich etwas gelauncht?


Vielleicht stimmt ja auch was Crashtest geschrieben hat:

Immerhin benötigt AMD reichlich gute Chips für Server - Desktop ist da nur Randgebiet immerhin soll da Bulldozer erst richtig als Fusion nächstes Jahr durchstarten ...

Kannst du mal dieses Paper suchen- oder vllt ist es ja noch wo auf deiner Platte?

Hier fehlt jetzt das Paper mit den Power/Performance-Kurven bei 2way-InO, 2way-OoO, 4way-OoO etc. Mit denen konnte ich kürzlich ein paar Kollegen recht leicht nachvollziehbar die wesentlichen Unterschiede zwischen einigen CPUs inkl. ARM verdeutlichen.

Ich glaube mich erinnern zu können - wurde es nicht auch mal hier gepostet (vor Jahren) - ich weiß aber partout nicht mehr wo.

 

[Ge0rgy]

Heben wir doch mal die Unterschiede hervor:
Dicker Kern:
Pro:
- potenziell hohe durchschnittliche IPC
- SMT-Fähig
- nur wenig Takt nötig für hohe Leistung

Contra:
- Komplex, daher Bug-Anfällig, schwieriger zu validieren, groß.
- Stromsparen ist schwieriger
- schwerer auszulasten, daher nicht immer max. Effizienz bei der Arbeit
- nur moderat taktbar

Schlanker Kern:
Pro:
- hohe Takte möglich
- einfacher zu validieren / testen
- einfacheres Design spart Transistoren
- Stromsparen ist leichter, selbst wenn man es nur auf Ebene ganzer Kerne implementiert.
- mittlere auslastung besser als bei großen Kernen.

Contra:
- schlechte IPC, daher hohe Takte nötig
- höhere Spannungen erforderlich, zu Lasten des Stromverbrauchs
- in vielen Fällen langsamer weil Software nicht sauber skaliert.

Hab ich was vergessen?

 

[PuckPoltergeist]

Schlanker Kern heisst nicht automatisch geringere IPC und umgekehrt. Das finde ich jetzt etwas sehr verallgemeinert.

 

[Bobo_Oberon]

Schlanker Kern heisst nicht automatisch geringere IPC und umgekehrt. Das finde ich jetzt etwas sehr verallgemeinert.

Du meinst, da spielt mindestens ebenso stark die ISA und Betriebssystem (-> dahinter stehendes Ökosystem) eine Rolle?!

MFG Bobo(2011).

 

[mocad_tom]

Schlanker Kern heisst nicht automatisch geringere IPC und umgekehrt. Das finde ich jetzt etwas sehr verallgemeinert.

Dem kann ich nur zustimmen.
Itanium kann eine hohe IPC haben ist aber vom Kern-Transistorbudget her kleiner als die aktuellen x86-Budgets.

Ich finde auch diese Simulationen etwas verallgemeinernd.

Man schafft es ja in einen bestehenden Kern hinein immer wieder etwas neues reinzubauen. Issue-Wide-Mässig, anzahl Pipeline-Stufen, FO4 ändert sich nicht, trotzdem steigt die IPC - wie durch Zauberhand

 

[Ge0rgy]

Öhm... natürlich ist das verallgemeinert, das soll ja auch eine art stichwortliste sein zur weiteren Erörterung.
Abgesehen davon, dass 2-issue nun mal in der theorie einen befehl weniger pro takt bearbeiten kann als 3-issue. Also ist die maximale IPC eben schon geringer.
Ebenso haben die fetten kerne die Transistoren ja nicht aus Jux und Dollerei. - Die haben einen Sinn, meistens eben die Verbesserung der Auslastung zur erhöhung der mittleren IPC.
So alla Branch Prediction, Prefetching, OP-Fusion usw. usf.
Also mit fettem Kern ist nicht nur gemeint dass man 10-fach OoO arbeitet sondern auch das Ganze drum und dran.
Die paradebeispiele beider Lager sind doch eigentlich CPUs und GPUs. Erstere haben relativ wenig Rechnekerne, die aber wesentlich mehr logik enthalten. letztere Vertreter der Brute-Force-Methode alla Ameisenschwarm...
Die genaueren Spezifika des einen oder anderen Ansatzes (egal ob CPU oder GPU) sind genau der Gegenstand dieses Threads. CELL Beispielsweise ist eher ein Hybride der Elemente von beiden Ansätzen enthält.

 

[PuckPoltergeist]

Du meinst, da spielt mindestens ebenso stark die ISA und Betriebssystem (-> dahinter stehendes Ökosystem) eine Rolle?!

MFG Bobo(2011).

Auch wenn das stimmt, meinte ich das nicht mal hier. Vergleicht doch nur mal den Pentium4 mit dem Core. Letzterer ist schlanker im Design und hat trotzdem die höhere IPC.

 

[Duplex]

Dicker Kern:
Pro:
- potenziell hohe durchschnittliche IPC
- SMT-Fähig
- nur wenig Takt nötig für hohe Leistung

Contra:
- Komplex, daher Bug-Anfällig, schwieriger zu validieren, groß.
- Stromsparen ist schwieriger
- schwerer auszulasten, daher nicht immer max. Effizienz bei der Arbeit
- nur moderat taktbar

Hab ich was vergessen?

Dein Contra dazu timmt nicht ganz, Stromsparen & CPU Takt ist bei Intel kein Problem.

Und die aktuellen Xeon für Sockel 1155 haben ohne IGP 3,6Ghz Basistakt bei 95W TDP mit durchscnittlich 40% höhere IPC als K10.

Seit dem Core2 hat Intel eine Super Architektur die auf hohe IPC & moderate Taktraten ausgelegt ist, mit Architektur Updates Stichwort: "Tock" steigert Intel weiterhin die IPC und der Takt wird nicht geringer!

 

[Dresdenboy]

Wir unterhalten uns schon über eine "General Purpose CPU"?
Ich gehe davon aus, dass Bulldozer eine "General Purpose CPU" ist.

Ich kenne derzeit niemanden, der nicht davon ausgeht, außer vielleicht Bauarbeiter und alle anderen, die nicht so in der Materie stecken.

Da aber "General Purpose" nicht "konstante Leistung" bedeutet sondern sich eher auf die ISA bezieht, ist die Variabilität bei heutigen Architekturen auch kein Widerspruch. Siehe dazu auch das Bild mit den Clustern, welches wir schon verwendet hatten.

Vielleicht sind sie ja wirklich mit dem Schlachtplan in die Schlacht gezogen:
Zuerst Bulldozer:
Ein etwas schmalerer Kern (der auch leichter zu Validieren ist) da man überall genug Baustellen hat

Danach Piledriver:
An Punkten, die man fetter gestalten kann wird ausstaffiert, um die "Durchschitts-IPC" anzuheben.

So ähnlich stelle ich mir das auch vor. Aber eher danach gestaffelt, welche Merkmale von der Komplexität am ehesten umsetzbar sind, so dass komplexere Elemente in nachfolgende Ausprägungen integriert werden. Das passt ganz gut zu Chuck Moores Ansatz, solche Features nicht nur nach Performanzgewinn zu gewichten, sondern auch nach Aufwand, Zeit, Energiebedarf usw.

Trinity hat ja auch nur zwei Piledriver-Module.
Während man von Istanbul zu Orochi geht, geht man von 6 Kerne auf 8 Int-Kerne.
Von Llano auf Trinity geht man aber von 4 Kerne auf 4 Int-Kerne.

Da gibt es nicht mehr viel Spekulationsspielraum nach unten bezgl. der Leistung

Kannst du mal dieses Paper suchen- oder vllt ist es ja noch wo auf deiner Platte?

"Energy-Performance Tradeoffs in Processor Architecture and Circuit Design: A Marginal Cost Analysis" von Omid Azizi, Aqeel Mahesri, Benjamin C. Lee, Sanjay J. Patel, Mark Horowitz
Link: http://www.duke.edu/~BCL15/documents/azizi2010-isca-opt.pdf

 

[Ge0rgy]

Dein Contra dazu timmt nicht ganz, Stromsparen & CPU Takt ist bei Intel kein Problem.

Und die aktuellen Xeon für Sockel 1155 haben ohne IGP 3,6Ghz Basistakt bei 95W TDP mit durchscnittlich 40% höhere IPC als K10.

Seit dem Core2 hat Intel eine Super Architektur die auf hohe IPC & moderate Taktraten ausgelegt ist, mit Architektur Updates Stichwort: "Tock" steigert Intel weiterhin die IPC und der Takt wird nicht geringer!

Wir müssen aufpassen dass wir hier nich die Fertigung mit hineinmischen.
Die Core-Mikroarchitektur ist ohne Zweifel gut... aber nur weil wir nichts besseres als Vergleichsbassi haben, ist sie noch lange nicht der Weisheit letzter Schluss.
Warum erscheinen dir 3,6Ghz viel?
Weil die Konkurrenz auch nicht mehr gebracht hat? - Das sagt nichts über die theoretische Möglichkeit aus, dass ein schlankerer Prozessor alla Bobcat nicht die 5Ghz hätte knacken können in Intels 32nm-Prozess.
Meine Pros und Contras sind nicht auf die derzeitige Marktsituation ausgerichtet sondern auf das was möglich wäre.
Das Stromsparen ist ein anderer Punkt... wenn du einen Bobcat-10-kerner hättest, der alle Kerne bis auf 1 im IDLE abschalten kann... meinst du nicht der wäre noch sparsamer als Sandy Bridge?
Also nur weil man mit viel Tricks & technischem Aufwand (der wiederum transistoren kostet) die "fetten" Kerne auf Diät gesetzt hat wenn es nichts zu arbeiten gibt, bedeutet das nicht kategorisch einen Vorteil des Architekturansatzes.

 

[Mente]

Hi Ge0rgy

aber wenn wir nach dem Was wissenschaftlich möglich ist, müssten wir auf Silitzium langsam verzichten.
Die Frage ist er was könnte man Kostendeckend Produzieren. Viele gehen ja davon aus das es nicht mal lange mit Silizium weiter gehen kann.

lg

 

[mocad_tom]

@ddb

http://www.duke.edu/~BCL15/documents/azizi2010-isca-opt.pdf

Wenn man sich Abbildung 8 auf Seite 9 anschaut.
Dort ist die Voltage variabel (also genau das was wir derzeit als gegeben voraussetzen).
Der 4-Issue-OoO und der 2-Issue-OoO scheinen hier wirklich die zwei härtesten Kontrahenten zu sein.
Der Schnittpunkt liegt bei 2000MIPS.
Was ist, wenn man dem Intel-Design-Team sagt, baut eine 4-Issue-Wide-OoO, die aber nur so viel Verbrauchen darf wie eine 2-Issue-Wide-OoO.

Die Sachen sind halt leider nach wie vor sehr theoretisch abgearbeitet. Man sieht nicht, welchen Effekt ein Handverdrahtetes Design hätte gegenüber einem syntetisierten (aus Foundry-Bibliotheken). Was ist, wenn Intel besonders kleine, schnelle und stromsparende Cachezellen bauen kann.
Was ist, wenn Intel sich deshalb auf ein Design stützt, das besonders gut mit großem L3-Cache und vollem Kern-Takt zurechtkommt.

Ich sehe die Cache-Pipeline als genau so wichtig, wie die Prozessor-Pipeline. Beim Core 2 Duo wurde hier vieles sehr sehr gut gemacht. Sie hatten eine extrem kurze Cache Latency beim Zugriff auf den 6MB großen L2-Cache.

Ich freue mich auf den start des BD, ich glaube aber, dass er den Namen wahrscheinlich nicht verdient hat.

 

[mocad_tom]

Wollte hier noch was anderes einwerfen.
Im "Energy-Performance-Tradeoff"-paper auf Seite 9 liegen die CPUs nicht so weit auseinander.

Jetzt mal kurz etwas, das vllt. den ein oder anderen aus den Socken heben könnte:
http://www.hotchips.org/archives/hc...1.23.270.Pulli-OpenCL-in-Handheld-Devices.pdf
In diesem Paper wird gezeigt, wie viel ein Bild-Bearbeitungs-Algorithmus auf einer ARM-CPU verbraucht und wie viel auf einer GPU mit OpenCL.

Auf Seite 18 wird mit der Angabe Joule per Frame rumhantiert.
Dabei zeigt sich, dass die Bildbearbeitung nicht nur schneller auf der GPU läuft, sondern auch nur ca. 15% der Energie braucht.
3,93 Joule pro Frame für die Berechnung auf der CPU
0,56 Joule pro Frame für die Berechnung auf der GPU

Es lässt sich daraus folgern:
für spezielle Anwendungen eignet sich die GPU um den Energieverbrauch minimieren zu können.

 

[Ge0rgy]

Lang lebe Fusion

 

[Stryki]

Erstmal muss es Leben
Im Moment ist es aus meiner Sicht nicht mehr als GPU und CPU auf einem DIE.
Software ist auch nicht gerade eine Stärke von AMD,trotzdem noch die beste Strategie ihr Know-how zu nutzen.

 

[memory_stick]

Im Paper wird ausserdem noch erwähnt, dass das kombinierte berrchnen eines Frames mehr verbraucht als nur auf der GPU, jedoch immer noch deutlich weniger als auf der CPU allein.

Folgerung: Da mit OpenCL dynamisch CPU und/oder GPU verwendet werden können, wird es in Heterogenen Anwendungen sehr wichtig sien, die richitgen Aufgaben auf die richtige Hardware zu verteilen,um ein optimales Performance/Watt Verhältnis zu erreichen.

btw: Georgy
es heisst "The Future is Fusion"

mfg memory_stick

 

[Dresdenboy]

Wollte hier noch was anderes einwerfen.
Im "Energy-Performance-Tradeoff"-paper auf Seite 9 liegen die CPUs nicht so weit auseinander.

Was auch spannend bzgl. der Tradeoffs ist (und nicht so oft dahingehend untersucht wurde): Welche Tradeoffs/Kurven passen nun gut zu den geplanten Einsatzfeldern (teilweise auch dadurch verschieden, weil das gleiche Die oder der Kern für Server/DT oder gar Mobile genutzt wird)?

Z. B. wäre für single threaded performance die Architektur am besten, deren Energie/Befehl-gegen-Performanz-Kurve sich am weitesten in den unteren rechten Sektor bewegt. Für angepeilte Multithreaded-Anwendungen können die Arch. geeigneter sein, welche eher im Mittelfeld bis leicht unten rechts liegen, da mehr Kerne dank TDP mit weniger Verbrauch auskommen müssen u. damit in den etwas niedriger performenden Bereich rutschen müssen. Für "unten rechts" reicht das Energiebudget einfach nicht mehr (ansteigender Part).

Jetzt mal kurz etwas, das vllt. den ein oder anderen aus den Socken heben könnte:
http://www.hotchips.org/archives/hc...1.23.270.Pulli-OpenCL-in-Handheld-Devices.pdf
In diesem Paper wird gezeigt, wie viel ein Bild-Bearbeitungs-Algorithmus auf einer ARM-CPU verbraucht und wie viel auf einer GPU mit OpenCL.

Auf Seite 18 wird mit der Angabe Joule per Frame rumhantiert.
Dabei zeigt sich, dass die Bildbearbeitung nicht nur schneller auf der GPU läuft, sondern auch nur ca. 15% der Energie braucht.
3,93 Joule pro Frame für die Berechnung auf der CPU
0,56 Joule pro Frame für die Berechnung auf der GPU

Es lässt sich daraus folgern:
für spezielle Anwendungen eignet sich die GPU um den Energieverbrauch minimieren zu können.

Wie jetzt... ? Fusion würde etwas bringen?

Tja, bei sehr hoher Datenlokalität und oft regelmäßigen Operationen passt das gut zu den vielen kleinen GPU-Shaderkernen mit vielen lokalen Registern u. Caches.

Es gab auf RWT u. woanders ja auch schon die Diskussion, dass ALU's ja eigentlich billig sind und nur das Hin- und Herschieben der Daten und Befehle in großen General-Purpose-CPU-Kernen dagegen sehr viel Energie braucht.

 

[Ge0rgy]

Erstmal muss es Leben
Im Moment ist es aus meiner Sicht nicht mehr als GPU und CPU auf einem DIE.
Software ist auch nicht gerade eine Stärke von AMD,trotzdem noch die beste Strategie ihr Know-how zu nutzen.

Du sagst das als wäre es was negatives?
Ja, es ist CPU und GPU auf einem DIE... und auch wenn die CPU teilweise nicht mehr ganz auf der Höhe der technischen Möglichkeitne rangiert, ist sie dennoch noch lange nicht untauglich und die GPU ist Top. Allen Unkenrufen zum Trotz freue ich mich auf mein Llano-Notebook, so es denn bald geliefert wird.
Die GPU ist sehr tauglich als GPU für Videobeschleunigung und "kleinere" 3D-Spielchen, ebenso sehr brauchbar als GPGPU-Beschleuniger.
Zugegeben, AMD hat sich bisher softwareseitig nicht mit Ruhm bekleckert, aber sie arbeiten daran. Neue SDKs, Debugger usw.
Aber, das Potential das dort schlummert ist enorm. Überlegt man was alleine die 80 Shaderkernchen eines Zacate in GFlops zu Leisten im Stande sind und zu welchem Preis/welchem Energiebedarf.
Genau hier wirds mittelfristig sehr lustig, wenn Bildbearbeitungssoftware und div. Algorithmen dank OpenCL stromsparender & schneller auf APUs rechenen können als auf CPUs alleine. Dann müssen nur noch einige Hürden bei der Zusammenarbeit/Speicherverwaltung zwischen CPU-Teil und GPU-teil der APU genommen werden und es geht rund! Photoshop auf einem Netbook

 

[mocad_tom]

Wie jetzt... ? Fusion würde etwas bringen?

Tja, bei sehr hoher Datenlokalität und oft regelmäßigen Operationen passt das gut zu den vielen kleinen GPU-Shaderkernen mit vielen lokalen Registern u. Caches.

Dieses Paper:
http://www.duke.edu/~BCL15/documents/azizi2010-isca-opt.pdf
Plus die Annahme, dass Algos mit hoher Datenlokalität gut zur GPU passen -> daraus folgt doch dann:
Wir brauchen einen breiten General-Purpose-Prozessor für stark chaotische Instruktionen+Daten
und
eine GPU für sehr strukturierte Instruktionen+Daten (weil Energieeffizienter)

Wenn man das schon weiß - warum macht man dann BD nicht 4-Issue-OoO?

 

[Lynxeye]

Dann müssen nur noch einige Hürden bei der Zusammenarbeit/Speicherverwaltung zwischen CPU-Teil und GPU-teil der APU genommen werden und es geht rund!

Welche Hürden? Der Zero-Copy Pfad kann inzwischen genutzt werden. Die Entwickler müssen nur noch die Dokumentation lesen und diese umsetzen, aber das ist mit OpenCL insgesamt das selbe Spiel.

Edit:

Dieses Paper:
http://www.duke.edu/~BCL15/documents/azizi2010-isca-opt.pdf
Plus die Annahme, dass Algos mit hoher Datenlokalität gut zur GPU passen -> daraus folgt doch dann:
Wir brauchen einen breiten General-Purpose-Prozessor für stark chaotische Instruktionen+Daten
und
eine GPU für sehr strukturierte Instruktionen+Daten (weil Energieeffizienter)

Wenn man das schon weiß - warum macht man dann BD nicht 4-Issue-OoO?

Weil der Vorteil der CPUs gegenüber den Shaderkernen nicht in der Breite der ALUs liegt, sondern an der Fähigkeit durch große Caches, sehr gute Dekoder, sinnvolle Branchprediction, usw. annehmbare Geschwindigkeiten bei stark verzweigendem (chaotischem) und wenig parallelen Code zu erreichen. Allein schon diese Tatsache zeigt doch, dass es nicht sinnvoll ist mehr parallele superskalare Einheiten zu verbauen, sondern das Transistorbudget in das Umland der ALUs/AGUs zu stecken, um diese sinnvoll auszulasten. -> Genau das, was bei BD gemacht wurde.

 

[Stryki]

Die Entwickler müssen nur noch..... Klar passiert nebenbei, genau das ist das Problem CUDA funktioniert doch auch nur weil NV es massiv unterstützt.
Das ist ein ernstes Problem sonst würde es doch passieren wo sind denn die Applikationen dafür? Klar im Browser ganz fein aber geht auch prima ohne oder?
Und dann ist es nicht mehr als auch Intel hat nur bessere GPU schlechter CPU und ne Menge schlummerndes Potential aber ich kauf nichts mehr was in X Jahren Y% Leistung bringen soll.
Kamm ganz oft genau nicht so.