Deshalb schlagen sich die AMDs K10-Modelle singlethreaded auch so toll und liegen mit den Intels (ohne Turbo) auf einer Linie.
Was willst du plötzlich mit singlethreaded? Die Rede war von "pro Thread". Und ich habe doch bereits die Werte von Cinebench oben gepostet, ~0,69 Punkte pro Thread für den i7-870, ~0,98 Punkte pro Thread für den X6 1100T, bei vergleichbarer Grösse der Kernlogik. Der X6 ist pro Thread in dem Fall also schneller. Oder anders formuliert, mit der gleichen Grösse an Kernlogik generiert AMD mehr Performance pro Thread. Wo soll also das Problem sein? Klar, du kannst jetzt einen Nehalem ohne Hyperthreading hernehmen und dann sagen, dass der X6 pro Thread doch nicht schneller ist. Nur solltest du dann bedenken, dass die Gesamtperformance in Cinebench ohne Hyperthreading ein ordentliches Stück niedriger ausfällt. Ein X6 1075T ist dann zB immer noch gut 35% schneller als ein i5-760.
Vielleicht ist es dir nicht aufgefallen, worauf ich hinaus wollte. Ihr betrachtet das Thema eindimensional, was es aber nicht ist. Behauptungen wie AMD wäre pro Thread zu langsam, sind einseitige Polemik und entsprechen schlichtweg nicht den Tatsachen. Was den Tatsachen entspricht, hängt von der Vergleichsbasis ab. Lässt du nur einen Thread laufen, ist Nehalem meist schneller. Lässt du hingegen den gesamten Prozessor auslasten, also inklusive Hyperthreading, ist der X6 pro Thread meist schneller. Und das sind auch jene Designentscheidungen, über die sich die Ingenieure Gedanken machen müssen und worauf letztendlich der Fokus gelegt wird. Ein Patentrezept für die eierlegende Wollmilchsau gibt es nun mal nicht. Du magst ja deine Wünsche haben und eine hohe singlethreaded Performance bevorzugen. Und sicherlich wäre es auch für AMD kein Problem, einen solchen Prozessor zu entwickeln. Nur, wozu? Ist das wirklich sinnvoll, wenn man dabei Abstriche beim Multithreading machen muss? Wo liegt die Zukunft? Bei Single- oder Multithreading? Die Anwendungen, wo es auf Performance ankommt, sind mittlerweile meist eh multithreaded. Und falls das mal nicht der Fall ist, weil sich nicht jede Aufgabe beliebig parallelisieren lässt, singlethreaded lässt sich auch durch Turbo recht ordentlich steigern, je nach Prozessor teils 50% und mehr. Selbst singlethreaded Anwendungen können sehr gut mit logischen Prozessoren skalieren. Nämlich dann, wenn du mehrere Instanzen der Anwendung hast. Typisches Beispiel, LAME. Ein Kodierer für MP3, der rein singlethreaded ist. Macht es wirklich einen Unterschied, ob das Konvertieren einer Datei ein paar Sekunden länger dauert? Oder ist es nicht sinnvoller, wenn du beim Konvertieren ganzer Alben etliche Minuten einsparen kannst?
Ich denke, AMD ist mit dem clusterbasierten Konzept schon auf dem richtigen Weg. Vielleicht wird das in Zukunft ja noch ausgebaut. Statt zwei Cluster pro Modul könnte ich mir auch 3 oder 4 Cluster pro Modul vorstellen. Ein noch breiteres Frontend und eine noch "fettere" FPU, die noch mehr Instruktionen pro Takt bei einem Thread verarbeiten können. Bei 3 oder 4 Threads aber dennoch effizient sind und eine hohe Performance pro Thread erreichen. Und das alles mit vergleichsweise wenig Transistorlogik im Vergleich zu 3 oder 4 herkömmlichen Kernen. Vielleicht stockt man dann auch die Integer Cluster noch etwas auf. Mit dem Clock-Grid sollte es eigentlich möglich sein, einzelne Komponenten, auch Ausführungseinheiten, bei Nichtnutzung lahm zu legen, so dass diese nicht unnötig Energie verschwenden. Interessant finde ich auch den Gedanken, die Integer Cluster zu vereinheitlichen, halt wie man es bei der FPU gemacht hat. Das wären aktuell 8 Instruction Pipelines mit 4 ALU + 4 AGLUs. Je nach Anzahl der Threads und Auslastung wird dann jedem Thread eine bestimmte Anzahl an Pipelines zur Verfügung gestellt. Ein Thread könnte so die vollen Ressourcen nutzen für hohe IPC. 2-4 Threads würden dann vielleicht 10-25% an IPC pro Thread verlieren, aber trotzdem noch auf eine hohe Gesamtperformance kommen. Und das alles ohne signifikant mehr Energie zu benötigen.
Aber das ist Zukunftsmusik und hat auch alles seine Grenzen, da der Aufwand dann teilweise potenziell steigt bei maximal linearem Gewinn. Wie auch immer, Potenzial ist jedenfalls vorhanden. Bei bdver1 geht es erstmal darum, dass das Ding überhaupt läuft.
Klar, besonders im Integerbereich hat ein Bulldozer-Kern (also ein halbes Modul) richtig zugelegt. Es wird sich erst noch zeigen müssen, ob die Streichung von Int-Pipelines im Vergleich zum alten K8 durch eine bessere Auslastung kompensiert werden kann.
Es ging vielmehr um gemeinsam genutzt Ressourcen. Die Integer Cluster gehören aktuell nicht dazu. Und wie kommst du darauf, dass Integer Pipelines gestrichen wurden? Jeder Cluster hat nun 4 Integer Pipelines, K8/K10 hat lediglich 3 Integer Pipelines pro Kern. Der Unterschied ist, während bei K8/K10 jede Pipeline ihren eigenen Scheduler und ein ALU/AGU Pärchen hatte, besitzt Bulldozer einen Unified Scheduler für alle Pipelines mit jeweils einer Ausführungseinheit, ALU oder AGLU.
Btw: Kennt sich hier irgendjemand mit SSE-Programmierung in Assembler aus?
Jup, wieso?
Obwohl es schon irgendwie süß ist, wie er um den x6 schönzurechnen, vom 2500k - von dem seit dem ersten Post von Duplex zu dieser Sache die Rede ist - ablenkt und so einen alten i7 ausgräbt.
Falls es dir nicht aufgefallen sein sollte, der i5 2500 ist 32 nm. Wie Schaffe89 schon anmerkte, ich habe zwei Prozessoren im gleichen Node verglichen, was imo nur fair ist bei einem Architekturvergleich. Den i5 2500 / i7 2600 können wir dann ja mit Zambezi vergleichen, die beide 32 nm sind.
Ausserdem habe ich zu den Aussagen von Duplex nichts gesagt. Es ging um deine Aussage.
. Mal im Ernst: Bis 2012 wird sich das definitiv nicht mehr verschieben können.