PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Intel - Silverthorne der Anfang vom Ende der Out-of-Order-Execution?


turboschlumpf
2008-04-06, 18:24:41
Wie lange noch lassen sich mit jeder Prozessor-Generation die Anzahl der Prozessorkerne, aber gleichzeitig auch die IPC jedes Kerns immer weiter steigern? Wie lange noch wird jeder Kern mit jeder Prozessor-Generation immer komplexer und komplexer werden?

Der immense Aufwand, der hierfür vor allem bei der Out-of-Order-Execution betrieben wird, ist ja für einen nicht gerade kleinen Teil des Transistor-Counts und auch des Stromverbrauchs aktueller Prozessorkerne verantwortlich. Dass In-Order-Designs wie Silverthorne demgegenüber deutlich energie-effizienter arbeiten ist bekannt.

Schon Banias hatte Anfang 2003 den Grundstein für den Mitte 2006 erschienenen Conroe gelegt. Bildet Silverthorne analog die Basis für die neue Architektur des Ende 2010 anstehenden Sandy Bridge? Und setzt Sandy Bridge erstmals wieder auf deutlich weniger komplexe Prozessor-Kerne als dies noch bei Nehalem der Fall sein wird? Eventuell sogar auf Kerne basierend auf einem In-Order-Design?

Botcruscher
2008-04-06, 18:35:52
Welches Ende?
Es ist eher ein Anfang den veränderten Marktanforderungen gerecht zu werden.

Mobil und Office sind andere Qualitäten gefragt.

Coda
2008-04-06, 18:39:08
Amdahl's Law sagt dazu: Nein.

Und überhaupt: Der Anteil an Logiktransistoren an der Die-Fläche sinkt stetig.

GeneralHanno
2008-04-06, 18:44:37
polaris ist doch ein in order design, oder?

Gast
2008-04-06, 18:46:39
Dass In-Order-Designs wie Silverthorne demgegenüber deutlich energie-effizienter arbeiten ist bekannt.


das hängt in erster linie von der software ab.

wenn diese die befehle schon in der idealen reihenfolge abarbeitet kann eine out-of-order-architektur natürlich kein vorteile erarbeiten und braucht trotzdem mehr strom.

wenn die befehle allerdings nicht ideal vorsortiert sind (was sie prinzipbedingt auch nicht immer sein können) kann OOOE sehr viel an performance bringen, dann sieht es mit der energieeffizienz schon wieder ganz anders aus.

genau hier liegt imo auch das problem. in-order-execution verlangt eine extrem gut angepasste software um schnell zu sein.

damit wird der schritt von OOOE zu IOE extrem schwer, denn alte software wird dann auf der neuen cpu schon mal ziemlich schlecht laufen. und auch für neue software wird es eine riesen herausvorderung für den compilerbau.
insbesondere dadurch, dass diverse optimierungen auf unterschiedlichen prozessoren eine ganz unterschiedliche wirkung haben können.
je nach software kann dann beispielsweise mal eine, mal der eine, mal der andere prozessor deutlich schneller sein.
nicht gerade toll für die softwareentwicklung wenn man für AMD und Intel-CPUs jeweils eigenen code braucht um schnell zu laufen.

unter umständen kann das ganze natürlich durch diverse frameworks wie .NET oder Java einigermaßen abgefangen werden, da dann nur die jeweilige VM die architekturspezifischen optimierungen braucht und nicht jedes einzelne softwareprodukt.

im prinzip haben wir mit dem Pentium 4 so was ähnliches in der "light-version" schon gesehen. niedriger IPC und starke abhängigkeit von der verwendeten software, was man durch hohe taktraten ausgleichen versucht.

die frage ist nun ob man zum compile-zeitpunkt wirklich schon genug informationen hat um eine IOE-architektur ordentlich auszunutzen und ob man sich das ganze überhaupt antun will.
wobei auch hier möglicherweise der trend in richtung JIT-compiler den ausschlag geben kann, da dieser ja auch zur laufzeit noch optimierungen vornehmen kann.

stickedy
2008-04-06, 18:51:25
Theoretisch sollte es mit einem In-Order-Design möglich sein die fehlende IPC durch einen höheren Takt wett zu machen. Allerdings ist das praktisch wohl alles andere als einfach umsetzbar, wie man ja an den Centaur-Prozessoren schön sehen kann... Und auch Intel hat ja bei Netburst ein ähnliches Konzept verfolgt: Niedrigere IPC (im Vergleich zum Pentium III) und stattdessen höherer Takt. Nur leider ist das ja nicht wirklich was geworden und am Schluss hat Intel dann doch noch versucht die IPC bei Netburst so gut wie möglich noch zu erhöhen, weil man beim Takt schlicht jahrelang quasi nicht von der Stelle kam...

Aus diesem Grund: Nein, zumindest nicht generell. Wobei es aber afaik Überlegungen gibt, Prozessoren mit sehr vielen Kernen zu bauen. Das bei 80 Kernen diese kaum die Komplexität haben dürften wie aktuelle Kerne sollte auf der Hand liegen. Allerdings geht sowas nur, wo man massiv parallelisieren kann, bei einem normalen PC gibt es da enge Grenzen...

Bei GPUs hingegen ist das wesentlich einfacher zu bewerkstelligen. Evtl. geht Intel bei Larrabee ja diesen Weg. Könnte ich mir zumindest vorstellen.

Coda
2008-04-06, 19:41:40
Larrabee ist tatsächlich In-Order. Aber das ist ja keine gerneral purpose CPU, auch wenn man das Ding dafür wohl einsetzten könnte.

Exxtreme
2008-04-06, 20:05:23
Problem ist halt, der Takt lässt sich auch nicht beliebig steigern wenn es noch wirtschaftlich sein soll. Der Verlust der fehlenden Ooo-Execution dürfte schon eine 2-stellige Prozentzahl an Leistung ausmachen. Die Frage ist jetzt ob man darauf verzichten will. Man sieht ja bei den aktuellen Konsolen, daß deren CPUs trotz hohen Taktes nicht so superschnell sind. Fehlt halt die Effizienz und die Pipelines laufen öfter leer und drehen Däumchen.

AnarchX
2008-04-06, 20:27:44
Schon Banias hatte Anfang 2003 den Grundstein für den Mitte 2006 erschienenen Conroe gelegt. Bildet Silverthorne analog die Basis für die neue Architektur des Ende 2010 anstehenden Sandy Bridge? Und setzt Sandy Bridge erstmals wieder auf deutlich weniger komplexe Prozessor-Kerne als dies noch bei Nehalem der Fall sein wird? Eventuell sogar auf Kerne basierend auf einem In-Order-Design?

Sandy Bridge, früher Gesher, wird wohl auf jeden Fall noch OoO werden:
http://img222.imageshack.us/img222/9606/larrabeespecsma9.png

Aber danach könnte es in der Tat in Richtung extremes Multi-In-Order-Core gehen, immerhin bezeichnet Intel Larrabee als "Entwicklungsplattform für zukünftige Multicore-Architekturen".

Auch möglich wären wohl Hybride, bei denen es eine geringe Zahl an starken Out-of-Order-Cores gibt, die durch einen Pool an an einfacheren In-Order-Cores, bei für diese geeignete Aufgaben, unterstützt werden. Jedenfalls stellt sich das Intel so in einigen Artikeln vor.

robbitop
2008-04-06, 20:40:35
General Puropose CPUs OOO auch weiterhin. Coda hat es ja schonmal erwähnt: Amdahl's Law
In der Praxis lassen sich viele Dinge nicht unendlich stark parallelisieren. Also ist SingleThreadperformance und damit auch die IPC verdammt wichtig.
In Order ist für Nettop, PDA ect Designs akzeptabel und sicher auch genau richtig in bei Dingen, die hoch parallelen Code haben (GPUs und GPGPU-Zeug).

AnarchX
2008-04-06, 21:13:54
Nunja, das ist eure Meinung.
Aber Intel ist nunmal der dominierend Hersteller für x86-CPUs bzw. CPUs, mit denen wohl der Endkunde am meisten arbeitet und deren Veröffentlichungen und Aussagen deuten eindeutig auf ein massives Multi-Core-Engagement für die Zukunft hin, wo In-Order-Kerne mit ihrer Verbrauchscharakteristik eine entscheidende Rolle spielen.

Und wenn man sich mal Gedanken über die Software von >2014 macht bzw. Projektionen sich dazu anschaut, dann erkennt man doch, dass es sich um hochparalle Anwendungen handelt, die auch für den Endkunden interessant sind und wofür oben genannte Architektur eben sich ziemlich gut eignet.

GeneralHanno
2008-04-06, 21:17:57
intel hat sich die zukunft auch mal aus kilometer langen pipelines und irrwitzigen taktraten vorgestellt ;)

aber im wissenschaftlichen bereich geht der trend (GPGPU&larrabee) ja klar in massiv parallele in-order designs. die single-tread leistung eines OOO kerns zu steiger, wird mit zunehmender zeit immer schwieriger ;)

AnarchX
2008-04-06, 21:33:45
Hier noch etwas Reißerisches von der aktuellen IDF:
So you think parallel programming is a drag, huh? "Let us recompile your app to take advantage of all those cores", says Intel. (http://apcmag.com/we_can_transform_single_thread_to_multithread_intel.htm)
:D

Exxtreme
2008-04-06, 21:37:41
Und wenn man sich mal Gedanken über die Software von >2014 macht bzw. Projektionen sich dazu anschaut, dann erkennt man doch, dass es sich um hochparalle Anwendungen handelt, die auch für den Endkunden interessant sind und wofür oben genannte Architektur eben sich ziemlich gut eignet.
Du kannst die allerwenigsten Dinge sinnvoll parallelisieren. Und genau deshalb werden Intels Träume wohl nicht aufgehen. Klar macht es evtl. Sinn wenn man 3D-Grafik wieder in die CPU verlagern will. Nur das könnte evtl. floppen. Und Intel hat nicht die Marktmacht irgendwelche Konzepte mit Gewalt durchzudrücken. Dazu müssten die Konzepte sehr viel besser sein als die bisherigen. Es ist interessant wie sich AMD hier verhalten wird.

SavageX
2008-04-06, 21:38:54
Man kann out-of-order ja auch mit variablem Aufwand betreiben. Wenn man z.B. das Instruktionsfenster kleiner wählt, dann kann man vermutlich gut an der Buchhaltung sparen etc.

Vermutlich ist ein "kleines" out-of-order immer noch besser als "gar keines". Man muss halt abwiegen, wieviel Mächtigkeit man spendiert. Und bisher marschiert z.B. Nehalem klar in die Richtung "mehr Ausgetüfteltheit".

AnarchX
2008-04-06, 21:48:39
Du kannst die allerwenigsten Dinge sinnvoll parallelisieren.
Massives Data-Mining auf lokale und im Netz vorhanden Resourcen verbunden mit künstlicher Intelligenz, was ich auch als sehr relevant für Endkunden-PC-Nutzung für oben genannten Zeitraum und später sehen würde, dürfte doch sehr gut parrallelisierbar sein.;)

Ausserdem gibt es ja immernoch die Möglichkeit der Hybriden, sodass eben Sandy Bridge bei seinen 4 bis 8 Ooo-Cores stehen bleiben wird und im nächsten "Tick" hier die unterstützenden In-Order-Cores in größerer Menge hinzukommen, sodass wir wohl weiterhin über >200GFLOPs Ooo-Performance reden, der aber >2 TFLOPs In-Order-Performance für hochparralle Anwendungen zur Seite stehen.

Demirug
2008-04-06, 22:00:26
Hier noch etwas Reißerisches von der aktuellen IDF:
So you think parallel programming is a drag, huh? "Let us recompile your app to take advantage of all those cores", says Intel. (http://apcmag.com/we_can_transform_single_thread_to_multithread_intel.htm)
:D

Ich habe massive Zweifel dass sowas bei komplexen Programmen funktioniert.

robbitop
2008-04-06, 22:05:07
Nunja, das ist eure Meinung.

Das ist keine Meinung, das ist Fakt. Entwickler wie Demirug sagen das, Amdahls Law besagt das und auch Collegeprofessoren sagen das. Und wenn man als Laie/Nichtentwickler mal über den mathematischen Hintergrund nachdenkt, sollte einem klar werden, dass sich nicht alles unendlich parallelisieren lässt. Viele Rechenoperationen hängen voneinander ab, müssen also seriell bearbeitet werden.
Zumindest für General Purpose CPUs und viele (nicht alle) Anwendungen ist das so.
Gegenfrage: wo hast du denn von Intel offiziell bestätigt bekommen, dass irgendeine kommende General Purpose CPU In Order werden soll?

AnarchX
2008-04-06, 22:27:52
Das ist keine Meinung, das ist Fakt. Entwickler wie Demirug sagen das, Amdahls Law besagt das und auch Collegeprofessoren sagen das. Und wenn man als Laie/Nichtentwickler mal über den mathematischen Hintergrund nachdenkt, sollte einem klar werden, dass sich nicht alles unendlich parallelisieren lässt. Viele Rechenoperationen hängen voneinander ab, müssen also seriell bearbeitet werden.
Zumindest für General Purpose CPUs und viele (nicht alle) Anwendungen ist das so.
Wenn wir von riesigen Datenmengen aus verschiedenen Quelle, wie oben beschrieben, reden, die möglichst schnell verarbeitet werden sollten, um den User sein gewünschtes Ergebnis zu liefern, dann zieht dies aber eine massive parallele Abarbeitung nach sich.


Gegenfrage: wo hast du denn von Intel offiziell bestätigt bekommen, dass irgendeine kommende General Purpose CPU In Order werden soll?

Future CPU Architectures -- The Shift from Traditional Models (http://www.beyond3d.com/content/articles/31/1)
http://www.beyond3d.com/images/articles/IntelFuture/Image6-big.jpg
http://www.beyond3d.com/images/articles/IntelFuture/Image9-big.jpg

Bei den betrachteten Zeiträumen ist es natürlich schwierig zu sagen, was werden wird, aber momentan scheint sich der wichtigste Hersteller doch für diese Richtung zu interessieren.

Botcruscher
2008-04-06, 22:45:08
Schöne Werbefolien... Alleine die 20x ohne Vergleichsangabe.

Der Multicorehype wird imo schnell versanden. Der Aufwand für die Progger ist gigantisch und der Gewinn schwindet mit jedem Core mehr.
Die Hersteller machen es sich natürlich einfach und laden ihre Probleme einfach woanders ab. Ein billiger Weg wenn mehr Takt/Effizienz nicht drin ist.

Coda
2008-04-06, 22:50:57
Ich habe massive Zweifel dass sowas bei komplexen Programmen funktioniert.
Wollt grad was dazu sagen :|

Coda
2008-04-06, 22:54:56
Wenn wir von riesigen Datenmengen aus verschiedenen Quelle, wie oben beschrieben, reden, die möglichst schnell verarbeitet werden sollten, um den User sein gewünschtes Ergebnis zu liefern, dann zieht dies aber eine massive parallele Abarbeitung nach sich.
Zumindest 4-8 Cores werden wohl immer OOO bleiben. Für die Basisprogramme ist es einfach unmöglich alles zu sinnvoll zu parallelisieren.

Und da wollen die Leute nich auf einmal bodenlose Performance. Genau aus dem selben Grund hat sich auch ein Cell niemals als Macintosh-Prozessor geeignet wie viele Apple-Fanboys uns weißmachen wollten.

robbitop
2008-04-06, 22:58:22
Intel meint das aber IMO nicht für General Purpose sondern für den Rest.
Denn irgendwann macht es keinen Sinn mehr die teuren OOOs zu skalieren, da viele Anwendungen nichtmehr groß weiterskalieren. Also fügt man zusätzlich In Order oder Vektoreinheiten hinzu. Damit kann man dann zumindest den parallelen Kram skalieren.
Das eine wird das andere jedoch IMO nicht ersetzen.

AnarchX
2008-04-06, 23:06:42
Aber irgendwann kommt man dann wohl auch bei dem Punkt an, wo man die Ooo-Cores von Board werfen kann, da einfach genügend programmierbare, auch andersweitig einsetzbare In-Order-Leistung vorhanden ist um diese via entsprechender SW-Emulation zu ersetzen.

Naja, vielleicht kommt ja zufällig doch noch der große Durchbruch in der Fertigungstechnologie, der einen deutlichen Sprung bei der Taktfrequenz erlaubt und somit das Leben von Singlecore + Ooo noch etwas verlängert. :D

Exxtreme
2008-04-06, 23:11:52
Massives Data-Mining auf lokale und im Netz vorhanden Resourcen verbunden mit künstlicher Intelligenz, was ich auch als sehr relevant für Endkunden-PC-Nutzung für oben genannten Zeitraum und später sehen würde, dürfte doch sehr gut parrallelisierbar sein.;)

Mag sein, daß es bei diesem Anwendungsbereich Vorteile bringt. Es lassen sich aber nur sehr wenige Aufgaben massiv parallelisieren. Und genau daran wird das Vorhaben weitgehend scheitern. Mag sein, daß es in grösseren Serverfarmen, die für eine einzige spezielle Aufgabe gebaut wurden, eine Zukunft hat. Aber für "normale" Dinge sehe ich da keine große Zukunft, sorry.

Ich sehe bei spätestens 8 Kernen erstmal Schluss. Hat kaum einen Sinn noch mehr Kerne reinzubauen.

Coda
2008-04-06, 23:21:14
Aber irgendwann kommt man dann wohl auch bei dem Punkt an, wo man die Ooo-Cores von Board werfen kann, da einfach genügend programmierbare, auch andersweitig einsetzbare In-Order-Leistung vorhanden ist um diese via entsprechender SW-Emulation zu ersetzen.
Du hast anscheinend keine Ahnung was In-Order und OOO überhaupt bedeutet. Was willst du da "emulieren"? Entweder man hat hohe IPC oder nicht, da gibt's keine "Emulation".

AnarchX
2008-04-06, 23:27:47
Du hast anscheinend keine Ahnung was In-Order und OOO überhaupt bedeutet...
Weil du daran zweifelst, dass mit genügend Rechenleistung, eine Laufzeitoptimierung des Programmkodes für In-Order möglich ist?

Aber für "normale" Dinge sehe ich da keine große Zukunft, sorry.
Was sind aber diese "normalen Dinge", welche einen weiter stark wachsenden Bedarf an Single-Thread-Leistung haben?
Selbst so ein kleiner Atom deckt ja schon viele Anwendungsbereiche ab.

Ich sehe doch die große Herausforderung in der Verarbeitung und Auswertung der immer größere wachsenden Datenbestände, die es auch im privaten Bereich gibt, nach den Vorstellungen und Ansprüchen des Users, der ohne entsprechende Anwendung keinen Überblick mehr über diese Daten hätte. Und da ist doch ein hoher Bedarf an paralleler Leistung.

Demirug
2008-04-06, 23:53:14
Ein IOO Design hat nur zwei Vorteile gegenüber einem OOO Design. Man braucht weniger Platz und Leistung (elektrisch). Dafür hat ein IOO Design bei gleicher Taktfrequenz immer eine schlechtere IPC als ein OOO egal wie gut der Code optimiert ist. Würden bei den PCs also von OOO zu IOO Design gehen hätten wir letzten Endes bei gleicher Chipgröße mehr „schlechter“ Cores. Von wenigen Ausnahmen mal abgesehen haben die meisten Anwendungen nicht genügen parallelisierbaren Code um mit 4 Cores noch eine ordentliche Skalierung zu erreichen. Da wir bald 8 Cores bekommen hätten wir dann mindestens 16 IOO Cores. Was sollen wir damit machen?

=Floi=
2008-04-07, 00:08:35
es gibt genug bereiche und auch im privaten umfeld profitiert man von virtualisierung. Es werden sich auch dafür neue möglichkeiten bieten und entwickeln, wenn es die hardware dafür erst einmal gibt. Auch muß ein system nicht immer gleich unbrauchbar sein, nur weil 1,2,4 oder 8 cores ausgelastet sind!

Gandgets brauchen teilweise auch extreme leistung.

Gast
2008-04-07, 00:17:11
es gibt genug bereiche und auch im privaten umfeld profitiert man von virtualisierung. Es werden sich auch dafür neue möglichkeiten bieten und entwickeln, wenn es die hardware dafür erst einmal gibt. Auch muß ein system nicht immer gleich unbrauchbar sein, nur weil 1,2,4 oder 8 cores ausgelastet sind!

Gandgets brauchen teilweise auch extreme leistung.Wie dumm ist das denn bitte? :usad:

Coda
2008-04-07, 01:48:38
Weil du daran zweifelst, dass mit genügend Rechenleistung, eine Laufzeitoptimierung des Programmkodes für In-Order möglich ist?
Bitte was?

Gast
2008-04-07, 02:03:08
Was hat das mit Was hatte das aber mit in order und out of order zu tun? Ich will keine IOE zuhause. Das ist für die Softwareinfrastruktur daheim idiotisch. Genauso idiotisch wie EPIC. Intel/HP bauen schon seit 1994 an einem brauchbaren Compiler.

IOE ist interessant für Vector. Achte hier auf den Pat mit dem X2.
http://www.cray.com/products/xt5/xt5_demo/

Ich sehe doch die große Herausforderung in der Verarbeitung und Auswertung der immer größere wachsenden Datenbestände, die es auch im privaten Bereich gibt, nach den Vorstellungen und Ansprüchen des Users, der ohne entsprechende Anwendung keinen Überblick mehr über diese Daten hätte. Und da ist doch ein hoher Bedarf an paralleler Leistung.Ein hoher Bedarf nach Leistung besteht immer und in allen Bereichen. Oder läuft etwas zu schnell bei dir?

Ob sie durch parallele Verarbeitung oder sonstwie erfolgt ist doch Schnuppe. Wie Demirug schon sagte haben wir schon garnicht so wenige Quads bei den Mainstream-Anwendern und genauso wie er sehe ich bis jetzt keinen großartigen Nutzen dieser Technologie. Sie beschleunigt zwar das Arbeiten mit mehreren Prozessen, die Steigerung der Leistung einzelner Prozesse bleibt bis jetzt aber ein Randthema. Programme die für mich erwähnenswert von Quads profitieren kann ich an beiden Händen abzählen.

Nach einem E8400@ 3.8 Ghz kann ich mir noch einen Nehalem mit 4 Cores und 8 Threads aufschwätzen lassen, diesmal will ich aber ganz genau überprüfen wofür.
Die momentane Situation (wie alt sind Quads @home eigentlich schon?) hat mich am Anfang ungemein gestreßt. Wie unser Undertaker :ulol: war ich dauernd auf der Suche nach einem Nutzungsprofils der immer möglichst alle 4 Cores merkbar nutzte. Auch das ist idiotisch. Ich kann nicht dauernd etwas recodieren.
Der gefressige Q6600@ 3.2 Ghz flog raus, der Wolfdale@ 3.8Ghz kam rein. Wunderbares arbeiten ;) Mein Locate32 geht merkbar schneller ab.

Gast
2008-04-07, 02:08:44
IOE ist interessant für Vector. Achte hier auf den Pat mit dem X2.
http://www.cray.com/products/xt5/xt5_demo/Hier hat man mit MMX- und den SSE-Befehlen auch mehr als genug Wunderwaffen. Sie müßen nur vernünftig genutzt werden.

Bokill
2008-04-07, 05:47:50
... Der immense Aufwand, der hierfür vor allem bei der Out-of-Order-Execution betrieben wird ... Dir ist bekannt, dass der Power6, Cell, Xenon ebenso In Order Prozessoren sind?

Dennoch sind komplexe Projekte, wie der Niagara 2, "Rock", Nehalem in den letzten Jahren angeschoben worden.

Ich denke, es hat der Silverthorne hier weder ein Anfang gemacht (weil einfach schon andere Hersteller sich wieder parallel zum Design von In Order-Prozessoren entschlossen haben), noch deutet sich derartiges bei Nehalem und seinen Nachfolgern an.

Technisch gesehen ist noch sehr viel Raum sogar für Out of Order-Prozessoren da. Auch heute noch sind die aktuellen Prozessoren noch ausserordentlich ineffektiv, wenn sie falsche Programmvorhersagen gemacht haben und die komplette Pipeline erst mal leerlaufen muss, während aktueller Programmcode erst mal aus dem Speicher mühsam nachgeladen werden muss.

Ich denke, dass In Order-Projekte den Aufwand für neue Projekte im Zaum halten und dadurch SMT-Technik, massive Multicores, [...] etwas leichter planbar sind.

MFG Bobo(2008 )

Exxtreme
2008-04-07, 08:53:50
Was sind aber diese "normalen Dinge", welche einen weiter stark wachsenden Bedarf an Single-Thread-Leistung haben?
Selbst so ein kleiner Atom deckt ja schon viele Anwendungsbereiche ab.
Nun, bis auf alte MSDOS-Spiele kann es mir persönlich nie zu schnell sein. :D Bei "normalen" Dingen fressen halt Spiele sehr viel "Lowthreaded"-Leistung weg. Mit mehr Threads erreicht man da kaum was.
Ich sehe doch die große Herausforderung in der Verarbeitung und Auswertung der immer größere wachsenden Datenbestände, die es auch im privaten Bereich gibt, nach den Vorstellungen und Ansprüchen des Users, der ohne entsprechende Anwendung keinen Überblick mehr über diese Daten hätte. Und da ist doch ein hoher Bedarf an paralleler Leistung.
Ich denke nicht, daß Privatpersonen so große Datenbestände haben, daß sich ein massiv paralleles CPU-Design lohnt. ;) Das Problem ist, mit einer IOE-CPU fährst du die meiste Zeit spürbar schlechter als mit einer OOOE-CPU. Du wirst keinen Kunden erklären können warum 95% seiner Software schlechter läuft als vorher, die Suche dafür superschnell geht. :D Da wird keiner Verständnis dafür haben sowas zu kaufen.

Problem Nummer 2 ist, IOE-CPUs sind total unflexibel. Stell dir vor Intel schafft es tatsächlich den Leuten diese massiv parallelen IOE-CPUs schmackhaft zu machen. Die meisten Programmierer liefern auch hochoptimierte Executables um den IOE-Nachteil verschmerzbarer zu machen. Paar Monate später kommt der Nachfolger dieser IOE-CPU raus natürlich auch IOE. Doch Intel hat paar Dinge geändert und der hochoptimierte Code für die vorherige CPU schmeckt der neuen CPU überhaupt nicht... :D

"Ja wir wissen, daß ihr Routenplaner 2014 nicht gut mit der neuen CPU zusammenarbeitet und sie öfter warten müssen wenn die Routen berechnet werden müssen. Kaufen sie sich doch Routenplaner 2016! Der ist auf die neue CPU optimiert!". X-D

Und man sieht auch in der Praxis wie "toll" die IOE-CPUs so sind. Die Xbox360-CPU hat drei Kerne und 3,2 GHz. Kommt aber gerade so an einen C2D mi 2,2 GHz ran. Ich glaube nicht, daß die OOOE-Logik so viel Platz auf der CPU verbraucht. Da brauchen die Caches wohl deutlich mehr. Der Effizienznachteil ist durchaus gravierend. Mit Itanic sieht man auch wozu IOE taugt. Intel bastelt da schon seit 10 Jahren am Compiler rum obwohl Intel durchaus gutes Knowhow in dieser Richtung hat. Herausgekommen ist bisher nicht viel. Das ist halt der Vorteil von OOOE. Das optimiert den Code selbst und ist weder auf Compiler, noch auf "passende" Daten so richtig angewiesen

Aquaschaf
2008-04-07, 11:34:21
Und man sieht auch in der Praxis wie "toll" die IOE-CPUs so sind. Die Xbox360-CPU hat drei Kerne und 3,2 GHz. Kommt aber gerade so an einen C2D mi 2,2 GHz ran.

Woher dieser Vergleich? Ich denke die XBox360-CPU ist ein gutes Stück langsamer als ein 2,2GHZ C2D.

Gast
2008-04-07, 15:26:53
Auch heute noch sind die aktuellen Prozessoren noch ausserordentlich ineffektiv, wenn sie falsche Programmvorhersagen gemacht haben und die komplette Pipeline erst mal leerlaufen muss, während aktueller Programmcode erst mal aus dem Speicher mühsam nachgeladen werden muss.Die Trefferquote liegt aktuell bei 90%. Der in order Kompiler liegt nur selten richtiger.

Gast
2008-04-07, 15:28:04
Woher dieser Vergleich? Ich denke die XBox360-CPU ist ein gutes Stück langsamer als ein 2,2GHZ C2D.
Ist vom Code abhängig, führ ich auf dem Ding entsprechende Handoptimierte Aufgaben aus (natürlich keine Interaktiven) kann das Teil schon ein brauchbare Leistung bringen. Gibts viele Branches etc hast einen Triplecore Palomino :)

robbitop@work
2008-04-07, 15:28:58
Man muss schon erstmal die Aufgaben unterteilen:

- Aufgaben, die Single Thread IPC brauchen
- Aufgaben die sehr gut mit der Anzahl der Einheiten skalieren

Server-CPUs, Vektor-CPUs usw haben alle idR eher letzteren Zweck. Dort skaliert die Performance mit der Anzahl der Einheiten.
Hier sprechen wir von Strömungssimulation, CGI, Datenbanken, Offlinerendering, Videobearbeitung/Encoding, Bildbearbeitung, Wettersimulation, Crunching ectpp.
Für solche Tasks macht das Ganze Sinn.

Erstere Aufgaben jedoch lassen sich prinzipbedingt nur begrenzt parallelisieren. Das ist nunmal so. Das bleibt auch so. Dafür braucht man dann, wenn man eine gute Endleistung haben will, OOO-Cores. Da führt kein Weg dran vorbei.

Vorstellen könnte ich mir für die Zukunft ein Konzept, was vieleicht 8-16 OOO-Cores enthällt und einen Batzen Vektoreinheiten oder irgendwelche simplen x86 Cores. So wäre man für vieles gut aufgestellt.

Gast
2008-04-07, 15:29:50
Woher dieser Vergleich? Ich denke die XBox360-CPU ist ein gutes Stück langsamer als ein 2,2GHZ C2D.Das auch noch ;)

Gast
2008-04-07, 15:39:26
@robbitop@work
Das ist der Müll von Intel. Die gleiche Verarsche die man mit Itanic mit uns versucht hat. Ich werde als Inteljünger AMD für AMD64 ewig dankbar sein.

Das was du erwähnst kann man nämlich mit der GPU die jetzt am PCIe hängt und DX ab 9c wunderprächtig erledigen. Diese Leistung ist einfach gigantisch. Sehr brauchbar "vektorisieren" kann man auch mit SSE.

Was Intel hier versucht ist sich in jeder Ecke fett breitzumachen. Wie MS. Wie bei MS scheinen deren Lösungen aber bei weitem nicht so gut für den Endkunden zu sein wie das was der freie und noch recht abwechslungsreiche Markt zu bieten hat. Für den Markt bzw. für den Endkunden ist das sogar sehr nachteilig. Man sollte das auf keinen Fall fressen.

Exxtreme
2008-04-07, 16:37:32
Woher dieser Vergleich? Ich denke die XBox360-CPU ist ein gutes Stück langsamer als ein 2,2GHZ C2D.
Wenn der Code gut ist dann wohl eher nicht. Ich denke, man kann durchaus beide vergleichen.

Aquaschaf
2008-04-07, 17:28:45
Wenn der Code gut ist dann wohl eher nicht. Ich denke, man kann durchaus beide vergleichen.

Meine Frage ist ja: anhand von was? Hast du irgendwelche Zahlen dazu?

Coda
2008-04-07, 17:35:39
http://www.heise.de/newsticker/foren/S-Warum-die-Playstation-unter-Linux-so-lahm-ist/forum-109161/msg-11731119/read/

Ist zwar für Cell und eine unbestätigte Quelle, aber die Kerne sollten ja recht ähnlich sein.

AnarchX
2008-04-07, 19:47:55
Naja, ob Cells PPE mit der hier genannten PowerPC-Problemen so ein optimales Beispiel ist.

Atom zeigt doch, dass es deutlich besser geht:
In SuperPI schlägt man mit 1.6GHz einen 1.13GHz P3, in etwa Netburst(P4) IPC (http://www.computerbase.de/news/hardware/prozessoren/intel/2008/maerz/erster_benchmark_intels_silverthorne/)


Die von Intel selbst veröffentlichen CineBench-Ergebnisse deuten ja in eine ähnliche Richtung hin.

Bokill
2008-04-07, 20:04:21
Die Trefferquote liegt aktuell bei 90%. Der in order Kompiler liegt nur selten richtiger. Es geht um die vergeudete Zeit, die anfällt, wenn die Pipeline gar nicht gefüllt ist. ;)

-> Das sind Grössenordnungen von 200 bis 300 brachliegende Taktzyklen.

NEC spricht mit stolzgeschwellter Brust von 25 bis 50 Prozent Ausnutzung eines Prozessorkerns bei den aktuellen Vektorprozessoren (SX-Serie). Im Vergleich dazu verorten sie die üblichen skalaren x86-Prozessoren bei einem Nutzungsrad von etwa 10 Prozent.

... Der Witz besteht ja darin, bei Vektorprozessoren, die Rechenoperationen so geschickt zu organisieren, dass gleichsam ein "Code-Stream" die SX-Prozessoren füttert ... bei skalaren Rechenoperationen versagen die SX-Prozessoren ja jämmerlich.

Ob nun AMDs K8, K10, Intels Core-Familie und Pentium 4, IBMs Power 6, der Cell [...] alle diese skalaren Prozessoren drehen ihre Rechenleistung mächtig auf, wenn deren Vektoreinheiten gut gefüttert werden (SSE2/SSE3, AltiVEC, [...])

MFG Bobo(2008 )

robbitop
2008-04-07, 20:36:17
Naja, ob Cells PPE mit der hier genannten PowerPC-Problemen so ein optimales Beispiel ist.

Atom zeigt doch, dass es deutlich besser geht:
In SuperPI schlägt man mit 1.6GHz einen 1.13GHz P3, in etwa Netburst(P4) IPC (http://www.computerbase.de/news/hardware/prozessoren/intel/2008/maerz/erster_benchmark_intels_silverthorne/)


Die von Intel selbst veröffentlichen CineBench-Ergebnisse deuten ja in eine ähnliche Richtung hin.
Der P4 hat ja auch eine lachhafte IPC. Wenn nicht sogar die mieseste alle OOO-CPUs.
Der Atom hingegen ist eine brandneue durchoptimierte In-Order Variante.
Wenn man die gegen eine brandneue durchoptimierte OOO Variante vergleicht, kommt bei SingleThreaded IPC mal eben fast Faktor 3 heraus. Und selbst der gute alte Dothan liegt bei Faktor 2,3.

Wuge
2008-04-07, 21:49:26
Und vor allem gehts um SuperPi, wo Netburst so bescheiden performt wie sonst nirgends.

Exxtreme
2008-04-07, 21:54:23
http://www.heise.de/newsticker/foren/S-Warum-die-Playstation-unter-Linux-so-lahm-ist/forum-109161/msg-11731119/read/

Ist zwar für Cell und eine unbestätigte Quelle, aber die Kerne sollten ja recht ähnlich sein.
Ups, doch so schlecht? Oo

Coda
2008-04-07, 22:50:30
Naja kann auch noch andere Gründe haben, aber ich würde die Rechenleistung dieser In-Order-Kerne auch nicht sehr hoch einschätzen trotz des hohen Taktes.

Das sind im Prinzip Pentiums von der Technologiestufe.

Gast
2008-04-08, 00:30:01
Es geht um die vergeudete Zeit, die anfällt, wenn die Pipeline gar nicht gefüllt ist. ;)

-> Das sind Grössenordnungen von 200 bis 300 brachliegende Taktzyklen.Es geht eher darum wie oft das passiert. 300 Zyklen von 3.8 Milionen Zyklen pro Sekunde geht so ;) Oder wie meinst du das?

NEC spricht mit stolzgeschwellter Brust von 25 bis 50 Prozent Ausnutzung eines Prozessorkerns bei den aktuellen Vektorprozessoren (SX-Serie). Im Vergleich dazu verorten sie die üblichen skalaren x86-Prozessoren bei einem Nutzungsrad von etwa 10 Prozent.

... Der Witz besteht ja darin, bei Vektorprozessoren, die Rechenoperationen so geschickt zu organisieren, dass gleichsam ein "Code-Stream" die SX-Prozessoren füttert ...Der Witz besteht wohl daraus, wie ich schon sagte und Exxtreme nochmal wiederholte, daß Intel schon 10 Jahre an einem brauchbaren in order kompiler rumfuscht. Für die Pentium1-Komplexität ist das vielleicht noch gut machbar. Für reine Vektorprozessoren auch. Für GPUs prinzipbedingt ebenfalls.

Für Desktop- oder Server-CPUs sehe ich eher schwarz bzw. bin 100% Blackbirds Meinung.

Coda
2008-04-08, 00:44:53
Du meinst jetzt Itanium, oder?

Das ist ja nochmal eine ganz andere Komplexität für den Compiler.

Gast
2008-04-08, 01:06:46
Ja. Welche Komplexität auch immer. Es ist ein lebendes Beispiel. Andere nicht-vektor finde ich nicht.
Es sieht nicht so aus als wenn für die zukünftige DesktopCPUs solche Komplexität eher abnehmen würde.

Es sieht einfach so aus als wenn Intel uns einen Teil des EPICs unbedingt aufs Auge drücken will, um ein marketingtechnisches Salto aus dem Itanium-Theater zu vollziehen. Das gefällt mir einfach nicht und ich bin mir sicher, daß es nicht nur Vorteile für uns bietet.
Wir sollen denen wohl helfen das Gesicht zu wahren :mad: "Nun verschmelzen wir blah blah. Das beste aus beiden Welten blah blah. Die zweite Generation von EPIC :ulol: blah blah". Sie wollen uns den Mist diesmal mit AMD64 doch noch aufs Auge drücken.

Ich sags euch das ist irgendeine Aktion die nicht nur mit einer sinnvollen Technik zu tun hat. Sie wollen aus der Itanicfalle raus und fangen an zu mischen, weil sie nicht wissen wie sie das nach Außen siegreich darstellen sollen. Und wir sollen diesen Mist dann fressen.

nacht

Bokill
2008-04-08, 01:16:45
Es geht eher darum wie oft das passiert. 300 Zyklen von 3.8 Millionen Zyklen pro Sekunde geht so ;) Oder wie meinst du das? ... So meine ich das garantiert eben nicht. :tongue:

Wenn die Sprungvorhersage zu 90 Prozent etwa richtig rät, dann passiert zu 10 Prozent der GAU, der bei den aktuellen Prozessoren unbedingt vermieden werden sollte.

Also fallen diese "380.000 Zyklen" (-> die besagten 10 Prozent) sehr deutlich ins Gewicht.

Ich betrachte da alleine einen einzigen "schlechten" falschen Zugriff. Dies wird bestraft mit 200 bis 300 "Straf"zyklen, bis der richtige Programmcode vom RAM (oder noch schlimmer von der Festplatte) geholt wird.

MFG Bobo(2008 )

Gast
2008-04-08, 02:06:38
Wenn die Sprungvorhersage zu 90 Prozent etwa richtig rät, dann passiert zu 10 Prozent der GAU, der bei den aktuellen Prozessoren unbedingt vermieden werden sollte.:| Warum ist das bei aktuellen Prozessoren schlimmer als bei zb. einem P3?

Also fallen diese "380.000 Zyklen" (-> die besagten 10 Prozent) sehr deutlich ins Gewicht.Das sind 0.38Mhz von 3800 Mhz in unserem Beispiel. Ich komm jetzt wohl nicht so mit :)

So wie ich das bis jetzt überblicke sieht das mit Nehalem nochmals sehr interessant aus.
Und nochmal, einen in order Kompiler der so gut backen würde wie Penryn out of order arbeitet, kenn ich nicht. Außer dem XL-Compiler, der aber wohl noch nie einen Firefox oder Crysis kompilieren mußte. Das ist eine Schweinemaloche und die bekommt Intel anscheinend nicht hin.

Die in order Architektur für den Desktop verenifacht die Komplexität der CPU, nötigt mich aber wesentlich mehr Speicher einzusetzen was die Anschaffungskosten und die Stromkosten erhöht. Und benötigt eine Bandbreite die ich noch nicht kommen sehe. Oder riesige L3 Caches. Die heitzen wiederum.
Man vergleiche schon die out of order Kompilate des SP1 für Vista32 und Vista64. Das als in order Kompilat würde einigen hier die Kienlade in eine beachtliche Abwärtsbewegung bringen.

Wenn man überlegt, daß eine DesktopCPU bestenfalls nur 90% ihrer Laufzeit im idle verbringt kann ich noch nicht ganz nachvollziehen in welche größeren Geschwindigkeitspitzen ich hier investieren sollte.

Wie immer :uclap: hab ich wieder einen wichtigen Link verschlampt, aber wie ich gelesen habe, bedeutet ein nur grob profiled Kompilat aus dem VC2008 eine für Phenom/Penryn Trefferquote von nah 93%. Nehalem soll mit den Alphas des VC bis 95% gehen. (in einer Textdatei notiert aber den Link nicht gespeichert. Idiot :() Für alle 3 CPUs mit durchschnittlich 1/4 längerem Kode. Das sind Werte mit welchen man mir die überwiegenden Vorteile von in order erstmal klar aufzeigen muß. Praktisch. Die Nachteile sind den meisten die hier brauchbar mitquatschen bekannt.

Ich kann den Beitrag 53 nur nochmals unterschreiben. Es geht garantiert nicht einfach nur um bessere CPUs. Eine ähnliche Nummer von Intel kennen wir schon. Ihr Name lautet Netburst. Die Gespräche hier mit all den Pros und Contras waren damals die selben.

Coda
2008-04-08, 02:31:39
Wieso sollte ein In-Order-Kompilat wesentlich größer sein? Das kapier ich jetzt nicht.

Bokill
2008-04-08, 02:48:32
:| Warum ist das bei aktuellen Prozessoren schlimmer als bei zb. einem P3? Weil die Schere zwischen CPU-Takt und Speichertakt im Laufe der Zeit immer grösser wurde ... ;)

Das sind 0.38Mhz von 3800 Mhz in unserem Beispiel. Ich komm jetzt wohl nicht so mit :) Die 380.000 Zyklen bezogen sich auf die Angabe mit der Zahl 3,8 Millionen Zyklen.
3,8 Millionen = 3.800.000

Bezogen auf GHz: Ein Zehntel von 3,8 GHz sind 0,38 GHz ;)

Gast
2008-04-08, 03:56:14
Wieso sollte ein In-Order-Kompilat wesentlich größer sein? Das kapier ich jetzt nicht.Ich auch nicht ;) Ist aber so. Jedenfalls das was ich von Power6 und Itanium kenne. Falls du an eine Linuxdistri für Itanium rankommst guck dir einige Standarddateien an. Vergleiche dann mit x86-32 und x86-64 Linux. Es sei denn hier haut noch EPIC einiges drauf. Die Ergebnisse des XL-Compilers sieht nicht anders aus. Auch wenn ich selbst damit noch nicht rumgefuchtelt habe. Vielleicht kann ich mir morgen etwas spaßiges vom Power6 schicken lassen was es auch für x86-64 gibt. Falls derjeniger welcher Urlauber wieder am Ackern ist :) Nur so als Birne zum Apfel :tongue:

@Bokill
Ja, 0.38Ghz wäre schon einiges. Richtig.
Immer größere Schere? Netburst ist tot ;) Ich würde eher von relevanten Bandbreiten sprechen als vom reinen Speichertakt. Die Caches sind um einiges größer und um vielfaches schneller geworden. 0.9Ghz DDR2 4-4-4-12 mit pisseligen XMS2 u.ä. fährt heute jeder OC-Depp. Die branch prediction eines Penryn auch eine andere als die des P3. Die Techniken des Nehalem erst recht. Speicherkontroller sind bald durchgehend Teil der CPU.
Man muß beim Miss eh selten etwas gleich aus der allerletzten Hauptspeicherzelle nochmals laden.

Ich behaupte mal von dem 3.8Ghz und 0.38Ghz Beispiel bleiben schon bald 0.25Ghz über. Damit kann man out of order schon gut leben. 0.2Ghz halte ich noch für machbar. Die dynamische Sprungvorhersage ist noch lange nicht am Ende des Möglichen.
Takte mal einen 2.5Ghz B3 Phenom mit 2.7Ghz und sag mir wieviel schneller die Programme laufen. Na eben. Dafür alles auf für die Softwareinfrasktruktur des Heimanwenders wesentlich komplizierteres in order umsatteln? Ich weiß nicht.

Intel will vielleicht dem Anwender unbedingt etwas reinwürgen. Dazu fehlen aber noch die Argumente. Vielleicht haben wir dann 9Ghz in order CPUs die 70W verbrauchen und doppelt so schnell wie ein 3.5Ghz Nehalem sind. Dann interessierts eh keinen ;)

mocad_tom
2008-04-08, 12:43:58
Ich auch nicht ;) Ist aber so. Jedenfalls das was ich von Power6 und Itanium kenne. Falls du an eine Linuxdistri für Itanium rankommst guck dir einige Standarddateien an. Vergleiche dann mit x86-32 und x86-64 Linux.
Rührt aber auch daher das x86 mit der älteste Befehlssatz ist, der aus der Uhrzeit der Prozessorgeschichte noch überlebt hat. Und damals musste man nunmal mit jedem bit im Kompilat knausern.

Andersrum wird ein Schuh draus, dadurch das die Kompilate so klein sind stressen sie die Cache-Hierarchien nicht so stark. Dies ist mit ein Grund, warum x86 eigintlich doch ein guter Befehlssatz ist - auch wenn mal ordentlich aufgeräumt/ausgemistet werden sollte.

Ob nun ein auf In-Order optimiertes Kompilat dringend größer sein muss wird ddamit also nicht geklärt. Man könnte hergehen und bei In-Order-Optimiert mehr loop-unrolling machen (ob das sinnvoll ist weiß ich jetzt nicht), das würde aber wirklich das Kompilat aufblähen.

Grüße,
Tom

Bokill
2008-04-08, 13:02:51
... @Bokill
Ja, 0.38Ghz wäre schon einiges. Richtig.
Immer größere Schere? Netburst ist tot ;) Ich würde eher von relevanten Bandbreiten sprechen als vom reinen Speichertakt. ... Ähhh ... ich glaube wir bewerten eine deutlich unterschiedliche historischen Zeitdauer. ;)

Ich betrachte gerne Halbleiter und im Speziellen Prozessoren seit Anfang der siebziger Jahre ... Bemessen auf dieser Zeitleiste ist der Speichertakt sehr deutlich dem Prozessortakt davon gelaufen.

Richtig ist, dass (zum Glück) das Taktrennen der Prozessoren teilweise gestoppt ist und zumindest der Speicherbustakt sehr stark aufgeholt hatte in den letzten Jahren.

Tatsächlich haben wir seit wenigen Jahren (sagen wir mal pi mal Daumen) ein Rennen zu höherer Parallelität. Nicht nur Prozessoren werden parallelisiert, sondern auch die Speichertechnik parallelisiert sich. ->
Von SDRAM zu DDR-RAM (Zwischenspeicher von 2 Bit, bevor die Daten auf den Speicherbus geschickt werden).
Bei DDR2-RAM wurden dann 4 Bit zwischengespeichert.
Bei DDR3-RAM werden nun aktuell 8 Bit zwischengespeichert.
Wohlgemerkt ... die Speicherzellen selber "hängen" immer noch bei dem Takt von 200 MHz.

Zur EPIC/Itanium-Diskussion:
Zum reinwürgen von Intels EPIC anhand des Beispiels des Silverthorne.
Ich habe selten solch einen hanebüchenen Unsinnn hier gelesen.

1. Ich empfinde es als sinnvollen Ansatz, wenn ein CPU-Grunddesign entschlackt und so reduziert wird, dass der Strombedarf gedrosselt wird.
2. Wenn dabei nur noch ein zweifach skalarer Prozessor herauskommt, ja und? Wenn es dem Energiesparen dient, was solls?
3. Das In Order Design wird kompensiert mit SMT-Technik und Dualcore-Technik. Solch ein x86 hätte es schon zu 486-Zeiten geben müssen.
4. Zusätzlich bekommt der Silverthorne (alias "Atom") SSE3 mit auf den Weg. Vektor-Instruktionssätze unterstützen de x86-Unterbau schon seit "MMX" mal mehr oder weniger ordentlich in der Leistungsfähigkeit.
5. Zur Zeit gibt es noch keine belastbaren Leistungsabschätzung zum Silverthorne. Die Leistungsabschätzung ist zur Zeit rein spekulativ.
5.a. Wenn Intel bei der Silverthorne-Leistung (1,6 GHz) eines Celeron M mit 900 MHz bleibt, aber den Strombedarf tatsächlich bis um den Faktor 4 reduziert, dann war es immer noch eine gute Entscheidung.
Ist der Strombedarf jedoch höher, dann darf man sich in der Tat fragen, ob die Entwicklung des Silverthorne sinnvoll war/ist.

EPIC im Itanium ist ein völlig anderes Feld. Der Tukwila-Itanium bekommt zudem "Quick Path" (früher als CSI bezeichnet) als Interconnect. Der Silverthorne hingegen BLEIBT auf dem alten Intel-Bus und ist zudem eine x86-CPU.

MFG Bobo(2008 )

Gast
2008-04-09, 01:23:09
Ist doch genau das was ich geschrieben habe Bokill.

Vielleicht haben wir dann 9Ghz in order CPUs die 70W verbrauchen und doppelt so schnell wie ein 3.5Ghz Nehalem sind. Dann interessierts eh keinen.

Wie zu P4 Zeiten bekommen wir mäßig Ghz mit schlechtem IPC und halbem EPIC-Getöse, dafür aber diesmal nicht als verkappte Herdplatten.

Die PR-Schwachmaten bei Intel flippen dann wohl total aus ;)

=Floi=
2008-04-09, 04:55:16
es interessiert schon. Das sieh man ja auch am core2. Man steigert eben auch hier duch mehr mhz die leistung so verdoppelt man bei gleichem takt grob mal die rechenleistung des p4. Es gibt noch immer genug anwendungen die auch einen einzelnen 4ghz core2duo auslasten.

Gast
2008-04-09, 21:07:06
Wenn die Sprungvorhersage zu 90 Prozent etwa richtig rät, dann passiert zu 10 Prozent der GAU, der bei den aktuellen Prozessoren unbedingt vermieden werden sollte.

Also fallen diese "380.000 Zyklen" (-> die besagten 10 Prozent) sehr deutlich ins Gewicht.



es ist ja nicht gerade jede anweisung eine (bedingte) sprunganweisung ;)

Gast
2008-04-12, 18:42:34
Mal ein kurzer Einwurf:
Ihr sagt, dass der Performance-Verlust durch IOE maßgeblich an sprungbedingten Pipeline-Stalls liegt.

Wie wäre es damit, auf ner 16- oder 32-Kern-Architektur dasselbe Programm 3x oder 4x laufen zu lassen, mit jeweils anderen Sprungergebnissen.
Damit könnte man doch im Falle eines solchen Stalls einfach auf den anderen Kern, welcher den Sprung richtig vorhergesehen hat, umschalten und ohne großen Performance-Verlust weiterrechnen.

Oder ist das jetzt zu komplex?
Ich geb ja zu, das ich mich nicht SOO tief in der Materie auskenne, aber so in etwa stelle ich mir Performance-Steigerungen bei Many-Core vor.

Bokill
2008-04-12, 23:24:42
es ist ja nicht gerade jede anweisung eine (bedingte) sprunganweisung ;) Es ist ein Irrglaube, dass die aktuellen Prozessoren schon nahe am Optimum sind.

Wenn das der Fall sein sollte, dann könnten die Hersteller ihre CPU-Designentwicklung einstellen. Dann ist es alles nur noch eine Frage der Herstellung als Halbleiter.

MFG Bobo(2008 )

Gast
2008-04-12, 23:54:24
Mal ein kurzer Einwurf:
Ihr sagt, dass der Performance-Verlust durch IOE maßgeblich an sprungbedingten Pipeline-Stalls liegt.

Wie wäre es damit, auf ner 16- oder 32-Kern-Architektur dasselbe Programm 3x oder 4x laufen zu lassen, mit jeweils anderen Sprungergebnissen.
Damit könnte man doch im Falle eines solchen Stalls einfach auf den anderen Kern, welcher den Sprung richtig vorhergesehen hat, umschalten und ohne großen Performance-Verlust weiterrechnen.Passt schon. Nur das was du dadurch raushaust ist nicht das was du beim Multithreading "jeder für sich selbst" in der Anwendung raushauen kannst.

@Bokill
An Optimum sind sie noch bei weitem nicht und ich höre das hier auch niemanden sagen. Das mit der "CPU-Designentwicklung einstellen" ist grenzwertig, denn mit Itanic und Silverthorne verlagert man die Entwicklung der CPU in den Kompiler.

Nebenbei. Eine genauso gefährliche Entwicklung wie die Gängelungen im OS deren Einführung mit Vista64 anfing. Wenn nur der Chiphersteller selbst einen einzigen brauchbaren Kompiler erstellen kann, dann ist das keine rosige Aussicht für die noch freien DaheimEDV-Welten.

Coda
2008-04-13, 21:09:01
Mal ein kurzer Einwurf:
Ihr sagt, dass der Performance-Verlust durch IOE maßgeblich an sprungbedingten Pipeline-Stalls liegt.

Wie wäre es damit, auf ner 16- oder 32-Kern-Architektur dasselbe Programm 3x oder 4x laufen zu lassen, mit jeweils anderen Sprungergebnissen.
Damit könnte man doch im Falle eines solchen Stalls einfach auf den anderen Kern, welcher den Sprung richtig vorhergesehen hat, umschalten und ohne großen Performance-Verlust weiterrechnen.

Oder ist das jetzt zu komplex?
Ich geb ja zu, das ich mich nicht SOO tief in der Materie auskenne, aber so in etwa stelle ich mir Performance-Steigerungen bei Many-Core vor.
Das macht Itanium schon. Nennt sich spekulative Ausführung. Das Problem ist dass die Energieeffizienz darunter natürlich sehr leidet.

Gast
2008-04-14, 17:23:23
Es ist ein Irrglaube, dass die aktuellen Prozessoren schon nahe am Optimum sind.

zumindest in sachen sprungvorhersage schon, da ist nicht viel mehr drinnen als wir jetzt schon sehen, man kann einfach nicht alle sprünge vorhersagen.

Gast
2008-04-14, 17:44:22
Mal ein kurzer Einwurf:
Ihr sagt, dass der Performance-Verlust durch IOE maßgeblich an sprungbedingten Pipeline-Stalls liegt.

nicht nur, das größte problem ist dass man extrem gut angepasste complier braucht.

man kann auch bei einer in-order-architektur sprünge vorhersagen und das ganze funktioniert auch recht gut. da man in-order üblicherweise auch eine simplere und kürzere pipeline (die man wahrscheinlich auch höher takten kann) hat ist die strafe bei einem falschen sprung möglicherweise sogar geringer.

das problem ist wie der name schon sagt, dass die befehle in der vorgegebenen reihenfolge ausgeführt werden müssen.
wenn du beispielsweise 2 INT-ALU-operationen und 1 FPU-operation pro takt ausführen kannst und beispielsweise folgende befehlsfolge hast:
INT, INT, INT, INT, FP, FP (jeweils voneinander unabhängige befehle)
in-order bräuchtest du dafür ganze 4 takte, es können jeweils 2 INTs parallel abgearbeitet werden, die 2 FPs brauchen jeweils einen takt.

OOO, sofern das befehlsfenster groß genug ist, kann die cpu quasi in die zukunft schauen und die FP-operationen parallel zu den INT-operationen ausführen und braucht damit nur 2 takte.

hier sieht man auch wieder, dass falsche sprungvorhersagen bei OOOE eher mehr schaden, als bei IOE. OOOE versucht ja befehle vorzuziehen, so lange kapazität in den ausführungseinheiten vorhanden ist. wenn dazwischen ein sprung liegt muss die hardware natürlich entscheiden ob gesprungen wird oder nicht und führt die befehle von einer seite des sprungs spekulativ aus.
IOE kennt das problem garnicht, da die befehle eh in der vorgegebenen reihenfolge ausgeführt werden müssen. je nach pipeline hat man bei einem falschen sprung wahrscheinlich IF/DEC umsonst gemacht, aber kaum die ALUs unnötig belastet.


Wie wäre es damit, auf ner 16- oder 32-Kern-Architektur dasselbe Programm 3x oder 4x laufen zu lassen, mit jeweils anderen Sprungergebnissen.

kann man natürlich, effizient ist das aber nicht unbedingt.