Nein, ich kenne keine Werte.
Ok, also ist dein Einwand wertlos. Und dabei wollen wir es belassen. Bis wir genaue Werte kennen, ist 5% sicherlich ein guter Richtwert. Wer glaubt, es sei weniger oder mehr, kann sich das ja dann selber nochmal mit seinem Wert durchrechnen. Ich würde empfehlen, du machst genau das, und teilst uns dann dein Ergebnis mit. Sry, aber das ist einfach wieder mal nur sinnfrei und uneinsichtig deinerseits. Selbst wenn SMT nichts kosten würde, was natürlich Blödsinn ist, stünden immer noch 12% mehr Fläche bei über 30% mehr Performance für CMT. Auch dieses Verhältnis ist mehr als eindeutig.
Es ist klar, dass SMT nur dann sinnvoll ist, wenn die Pipeline mit einem Thread noch nicht wirklich gut ausgelastet ist.
Nö. Das Ziel von SMT hat mit der Pipeline erstmal gar nichts am Hut. Bestimmte Einheiten der Pipeline werden für SMT einfach nur vervielfacht oder verbreitert. Der Sinn von SMT liegt immer noch darin, die Ausführungseinheiten besser auszulasten. Die zwar Teil der Pipeline sind, aber eben nicht pauschal die Pipeline. Und die Ausführungseinheiten besser auszulasten, ist natürlich auch bei einem CMT-basierten Design problemlos machbar, siehe Sun.
Der Beweis dafür ist denkbar einfach: Würde SMT auch bei BD noch nennenswerte Profite bringen, hätte man es implementiert, und wenn es nur für die Servermodelle aktiviert werden würde.
Klar, das ist DER Beweis. Was sonst.
Ein Bulldozer hat 4MB L2+L3 pro Modul, nicht 2MB - und damit über 38mm².
Immer die gleiche Leier.
Du hast es scheinbar immer noch nicht kapiert. Es ging um Kernlogik, nicht um irgendwelchen Cache. Eine gleichwertige Cachemenge wurde lediglich genommen, da keine genauen Zahlen ohne Cache bekannt sind. Wenn dir das Spass macht, dann ziehe sämtlichen Cache eines Moduls ab und vergleiche das mit der Kernlogik eines Sandy Bridge Kerns. Darum geht es. Die Menge des Caches kann eh von Design zu Design variieren.
Es gibt zwar nur ein Frontend pro Modul, das aber im Vergleich zum Vorgänger fast den doppelten Durchsatz hat. Das gleiche gilt für die FPU. Der L2-Cache wurde gleich vervierfacht.
Diese Komponenten sind trotzdem nur einmal vorhanden. Intel hat bei Nehalem ja ebenfalls einiges verbreitert, damit SMT nicht im Keim erstickt. Ausserdem sollte man bei einigem vorsichtig sein. Wer sagt uns denn, dass die FPU wegen CMT verbreitert wurde? Dagegen spricht zB AVX. IIRC waren in früheren Patenten nur 2x 64-bit beschrieben, die für das ursprünglich geplante SSE5 auch gereicht hätten.
Vorgegeben war gleiche Leistung bei gleichem Stromverbrauch. Es ist richtig, dass nicht jede Anwendung mit dem Takt skaliert, aber das trifft nur auf Anwendungen zu, bei denen andere Hardware limitiert, z.B. Speicher, Grafikkarte, I/O Subsystem.
Vorgegeben war gleiche Performance bei gleicher Leistungsaufnahme @ default. Was ich darüber hinaus vergleiche, um mich zu entscheiden, zB wie sich Performance und Leistungsaufnahme mit höherem oder niedrigerem Takt entwickeln, darfst du schon noch mir überlassen. Unsinnig ist daran natürlich nichts.
Was Durchsatz und Sprungvorhersage angeht, wurde bei HT überhaupt nichts verändert.
Darüber hat auch keiner ein Wort verloren. Bleibe bitte beim Thema. Mal abgesehen davon ist diese Behauptung auch ziemlich falsch. ZB wurde die Reservation Station (1/3 mehr µOps) vergrössert. Ähnliches gilt für andere Buffer. Der Durchsatz wurde an einigen Stellen also sehr wohl geändert, und zwar deutlich.
Das Frontend wurde deutlich erweitert (Fetch, Decode, Sprungvorhersage, usw).
Deutlich? Und was hat zB Sprungvorhersage konkret mit CMT zu tun? Einiges mag breiter ausgelegt sein für CMT. Wie viel es ist, können wir aber noch nicht einschätzen. Und wie gesagt, auch bei SMT muss die Pipeline teilweise aufgebohrt werden. In diesem Punkt unterscheiden sich CMT und SMT also gar nicht so sehr.
Naja, es ist schon richtig, das einige Veränderungen von K10.5 zu BD sich eher negativ auf die IPC auswirken sollten, z.B. die längere Pipeline und 2-issue statt 3-issue
Ohne die genaue Arbeitsweise zu kennen, sind solche Aussagen nur irreführend. Strikt genommen hat Bulldozer zwar nur 2 Issue Slots gegenüber 3 Issue Slots beim K10. Diese arbeiten aber anders. Der springende Punkt ist ein anderer. Es sind 4 Instruction Pipelines bei Bulldozer vs 3 Instruction Pipelines bei K10. K10 konnte pro Takt durchgehend maximal 3 Instruktionen verarbeiten, bei Bulldozer sind es hingegen 4. Da sollte sich also nichts negativ auf die IPC auswirken. Eher im Gegenteil.
Also den Vergleich sollte BD locker gewinnen
Kann man so nicht sagen. Wenn alle 8 logischen Prozessoren ausgelastet werden können, ja, vermutlich in den meisten Fällen. Bei 4 oder weniger ausgelasteten logischen Prozessoren könnten beide hingegen recht nahe beieinander liegen, je nach Anwendung.
was aber auch nicht sonderlich überraschend ist, wenn man die Die-Größen und die Anzahl der Kerne vergleicht.
Doch, genau dann. Beide haben ja gleich viele physische Kerne, die ähnlich viel Logik besitzen, und gleich viele logische Prozessoren, die gleich viele Threads parallel verarbeiten können. Nicht sonderlich überraschend wäre es vielmehr, da bisher eben viel vom CMT-Design durchgesickert ist.
beträgt. Das sind dann für mich wieder nur reine Fanboy Stories. Da kann sich dann die Minderheit darum prügeln, die mit ihre 5% eh kein Gehör oder Beachtung finden wird. Für den Hersteller der 18km² DIE-Fläche ist das völlig ohne Belang.
).
