AMD - AMDs Bulldozer - neue CPU-Architektur für Q2 2011 [Archiv] - Seite 2

aylano

2009-12-31, 15:01:50

Das wären ja wieder 8 Cores des Bulldozers morgen gegen einen 4 Kern Deneb heute.
Ansichts-Sache.
Nehmen wir mal an, ein BD-Modul wird mit dem 2. Int-Core 50% größer als ein K10.5-Core (, wobei in den 50% auch die doppelt oder vierfach so starkte FPU dabei ist.)

Dann ist das beachtlich, wenn man es mit Nehalem vergleicht, wo der Core damals mit all den Verbesserungen auch um 50% wuchs, aber eben keinen 2. Int-Core hat.

Außerdem würde ich es auch sehr beachtlich sehen, wenn ein BD-Modul dann genauso groß wäre wie der Core der Konkurrenz.
Die größere Core-Größe war immer ein Nachteil von AMD, was sich nicht nur auf die Produktionskosten, sondern auch auf den Stromverbrauch auswirkte.

takt war unter 2ghz. tdp unter 45w (4 BD-module). es gab einen test in dem die 4 BD-module (8 kern BD) mit unter 2ghz gegen
Momentan finde ich am Interesantersten, dass er läuft und mit knapp unter 2Ghz nur 45Watt verbraucht.

Zum Start wird der wahrscheinlich nicht mehr als 3,0 Ghz brauchen.

Avalox

2009-12-31, 15:07:44

Ansichts-Sache.

Eigentlich nicht. Der Bulldozer ist dann eine 8 Kern CPU, welche über 4 doppelt genutzte FPUs verfügt.

Über was keiner diskutieren muss ist, dass der Bulldozer die selbe Produktzielgruppe hat wie die heutigen 4 Kern AMD Chips.
Das ist eben der Fortschritt. Morgen gibt es mehr Kerne für den selben Preis.

Dort ist es aber; wie viel Leistung erhalte ich für das selbe Geld und nicht wie viel schneller ist ein neuer Kern gegenüber einen alten Kern.

Ich beharre dort so drauf, weil es bei der Bulldozer CPUs solch ein entscheidender Punkt ist gerade, wenn man auf die SMT Realisierung eingeht.

w0mbat

2010-01-01, 08:33:48

ich kann nicht genau sagen was fuer ein bench das war, aber es ging bestimmt nicht um verschluesselungen (das hab ich gefragt). das programm hatte zwei teile, einen um die stabilitaet zu testen und der andere war eben dieser "benchmark". ich bin mir ziemlich sicher dass damit auch neue instruktionen getestet wurden da die ausgabe nach den verschiedenen tests nicht nur die geschwindigkeit angab sondern ob die erbegnisse auch stimmen bzw ob es fehler gab (aber im vergleich zum stabilitaets test aben nicht primaer). da kam auch sowas wie "amd4" und "amd5" vor was nach meiner frage mit "das sind covernamen fuer neue "features"" quittiert wurde.

man wollte mir auch nicht sagen wieso nur 1gb ram benutzt wurden, koennte also noch probleme mim imc geben. der kuehler war mmn der normale amd boxed-kuehler und lieg leise, nach hand-test eher lauwarm.

reunion

2010-01-01, 11:16:26

Es ist auf jeden Fall beachtenswert das es jetzt schon Samples (vermutlich noch in 45nm) gibt. Auch wenn sich das bei einer neuen CPU-Generation schon mal verdammt lange ziehen kann bis zum Launch liegt man zumindest sehr gut im Zeitplan.

Gast

2010-01-01, 12:46:08

ich kanns kaum erwarten!!! hört sich alles sehr vielversprechend an :) AMD strikes back!

Advanced

2010-01-01, 14:15:23

mboeller

2010-01-01, 16:36:45

Gast

2010-01-01, 17:00:35

Darf man fragen wie du zu dieser Ehre kamst? :smile:

Sag bloß du glaubst ihm. Finde ich frech von ihm die Leute zu verarschen. Wie man sieht fallen viele drauf rein.

Knuddelbearli

2010-01-01, 17:13:56

tja wieder mal der gast feigling ^^

Coda

2010-01-01, 17:32:36

drei Buchstaben: O-M-G!
Kannst du bitte lesen was ich schreibe bevor du mich völlig aus dem Kontext zitierst?

Würde mich nicht wundern, wenn es Code gäbe, der dem K8/K10 so wenig liegt, dass er nur eine Instruktion pro Takt fertigstellen kann, den Bulldozer aber ungebremest 4-fach superskalar abfrühstücken kann.
Mich schon. Das ist mehr als illusorisch. Das einzige was K10 nicht ooO ausführen kann sind Stores. Und das Instruction-Window ist eigentlich auch schon groß genug.

Die Intel-Architekturen nehmen ihren Leistungvorteil auch vor allem durch die sehr intelligenten Prefetcher, nicht dadurch dass sie mehr durch die Einheiten bekommen. Bei vorhersagbaren Speicherzugriffen ist der Unterschied viel geringern.

mrt

2010-01-02, 15:19:43

Ein Bulldozermodul ist ein Kern und nicht zwei Kerne. Bei Suns SPARC wird die FPU geteilt, hier werden einfach nur die Ganzzahlenrechenwerke geteilt um SMT effizienter abarbeiten zu können.

Coda

2010-01-02, 15:31:00

reunion

2010-01-02, 15:37:53

Bitte nochmal?

Ein Bulldozer-Modul hat zwei komplett Frontends, Integer-Pipelines usw. Nur die FPU ist geteilt. Wenn reiner Integer-Code ausgeführt wird (oder nur eine Pipeline FP-Code verwendet) verhält sich ein Modul 100% wie zwei dedizierte Kerne.

AMD gibt 12% mehr Transistoren an, ist das nicht ein bisschen wenig für einen zweiten dedizierten Kern bis auf die FPU?

Coda

2010-01-02, 15:40:28

Physikalisch mögen Dinge optimaler verwoben sein, aber logisch funktioniert Bulldozer tatsächlich so, dass zwei Integer-Threads sich nicht gegenseitig blockieren.

Zumindest habe ich noch nichts gegenteiliges gehört. Wäre auch arg unsinnig ganze 4 Integer-Pipelines pro Thread einzubauen, wenn man sie von oben nicht füttern kann.

Gestrandet

2010-01-02, 15:41:45

AMD gibt 12% mehr Transistoren an, ist das nicht ein bisschen wenig für einen zweiten dedizierten Kern bis auf die FPU?
Wenn sie den Cache mitzählen, sicher nicht ;)
Und die FPU soll ja auch nicht die allerschlankste sein ... John Fruehe hat's irgendwo aufgeklärt, find's grad nit.

Avalox

2010-01-02, 15:56:19

Ein Bulldozermodul ist ein Kern und nicht zwei Kerne. Bei Suns SPARC wird die FPU geteilt, hier werden einfach nur die Ganzzahlenrechenwerke geteilt um SMT effizienter abarbeiten zu können.

Nein. Wie Coda auch sagt, es sind 2 komplett eigenständige Integer Kerne mit z.B. jeweils eigenen L1 Cache. (welcher beim Bulldozer klein ausfällt)

Die CPU muss dem heutigen Betriebssystem vormachen, dass sie SMT beherrscht, damit dieses mit den beiden Kernen überhaupt mit der auf die halbe Anzahl reduzierter FPUs auskommen.

Ein Bulldozer Modul besteht aus 2 Integer Cores mit jeweils eigenen L1 Cache, einen FPU Core ohne L1 Cache aber dafür mit einen eigenen Scheduler und natürlich einen gemeinsamen L2 Cache.

mrt

2010-01-02, 16:19:34

Aus dem veroffentlichten Material liest sich das aber anders, der TLB etc scheinen eben nicht verdoppelt worden zu sein. Ein BD-Kern (aka Modul) soll ja auch nur an einem Thread arbeiten können, zumindest deuten das die Informationen und Patente an.
Der Witz an CMT ist ja die physikalische Ebene, ein Kern mit 2 Threads und zugesischerten Resourcen (bei SMT eben nicht so).

Coda

2010-01-02, 16:21:18

Die CPU muss dem heutigen Betriebssystem vormachen, dass sie SMT beherrscht, damit dieses mit den beiden Kernen überhaupt mit der auf die halbe Anzahl reduzierter FPUs auskommen.
Nö, das muss es nur wissen damit es das Scheduling intelligenter macht.

Ansonsten könnte man ein Modul aus Sicht des Betriebssystems uneingeschränkt als zwei Kerne sehen.

Ein Bulldozer Modul besteht aus 2 Integer Cores mit jeweils eigenen L1 Cache, einen FPU Core ohne L1 Cache aber dafür mit einen eigenen Scheduler und natürlich einen gemeinsamen L2 Cache.
Die FPU wird natürlich aus dem L1-Cache des jeweiligen Cores gefüttert aus dem die Daten kommen.

Ein BD-Kern (aka Modul) soll ja auch nur an einem Thread arbeiten können, zumindest deuten das die Informationen und Patente an.
Ein Thread und 8 Integer-Einheiten. Ganz bestimmt nicht ;)

Avalox

2010-01-02, 16:22:59

Aus dem veroffentlichten Material liest sich das aber anders, .

Andreas Stiller hat es im Prozessorgeflüster gut beschrieben.

"Schließlich soll Bulldozer Intels AVX-Erweiterung übernehmen, die eigene schon veröffentlichte SSE5-Alternative wird AMD aller Voraussicht nach jetzt fallen lassen. Prozessorgeflüster-Leser wussten ohnehin schon, dass Bulldozer ein Konzept ist, bei dem sich jeder Kern aus zwei Integer-Subkernen mit eigenen L1-Caches, aber gemeinsamem L2-Cache sowie einem Gleitkomma-Subkern ohne L1-Cache zusammensetzt. Die L1-Caches sind dem Vernehmen nach recht klein, man hört von 8 KByte. Die beiden Integer-Subkerne arbeiten wie bei Intels Nehalem mit vier parallelen Pipelines, der Gleitkomma-Teil hat derer zwei, eine jede vermag 128-Bit-FMAC-Operationen auszuführen (Multiplikation und Addition in einem Schritt). Die 128-Bit-Angabe weist darauf hin, dass die 256 Bit breite AVX wohl zunächst in zwei Happen zerlegt wird, so wie früher etwa der Barcelona-Prozessor das 128-bittige SSE in zwei 64-Bit-Operationen aufteilte. Immerhin bietet der Bulldozer überhaupt FMAC – bei Intels erstem AVX-Prozessor Sandy Bridge wird diese wohl durch Abwesenheit glänzen.
Kerngeschäft

Damit bestehende Betriebssysteme mit AMDs Kernkonstruktion überhaupt klarkommen, muss die FPU irgendwie mit einer Art Hyper-Threading betrieben werden, damit man das Ganze dann nach außen als vollständigen Doppelkern sowohl dem Betriebssystem als auch dem Volke verkaufen kann. So ist 2011 für High-End-Desktops der Achtkerner Zambesi eingeplant, mit vermutlich vier solcher Doppelkerne. Im Rahmen von Fusion soll bei ihm auch ein Grafikprozessor mit auf den Chip, im AMD-Jargon heißt der Kombichip daher Accelerated Processing Unit (APU)."

http://www.heise.de/ct/artikel/Prozessorgefluester-862083.html

Coda

2010-01-02, 16:25:57

Der Mann sollte mal seine Fakten zusammenbekommen bevor er so einen Stuss schreibt.

SMT (auch bei Intel) betrifft ausschließlich das Scheduling, die Thread-States sind natürlich weiterhin komplett getrennt aus Sicht der Software.

mrt

2010-01-02, 16:29:25

Bitte nochmal?

Ein Bulldozer-Modul hat zwei komplett Frontends, Integer-Pipelines usw. Nur die FPU ist geteilt. Wenn reiner Integer-Code ausgeführt wird (oder nur eine Pipeline FP-Code verwendet) verhält sich ein Modul 100% wie zwei dedizierte Kerne.
Es gibt nur ein Frontend.

@Avalox
Das ist falsch was Andreas Stiller geschrieben hat, man braucht kein SMT oder dergleichen für eine gemeinsame FPU. Die (Int)Kerne sind für die Verwaltung der FPU zuständig. (siehe Sun)

Avalox

2010-01-02, 16:32:17

Die (Int)Kerne sind für die Verwaltung der FPU zuständig. (siehe Sun)

Bei Sun gibt es ja auch gleich das passende Betriebssystem mit eigenen angepassten Schedular dazu.

Coda

2010-01-02, 16:33:30

Es gibt nur ein Frontend.
Das eine Frontend kann aber mit an Sicherheit grenzender Wahrscheinlichkeit zwei Threads parallel berarbeiten (oder es läuft mit doppeltem Takt - was eher unwahrscheinlich ist).

Wie ich weiter oben schonmal gesagt habe ist es sonst absoluter Wahnsinn 2x4 Integer-Pipelines einzubauen. Das bekommst du aus einem Thread niemals gefüttert.

mrt

2010-01-02, 16:39:43

Natürlich kann das Frontend zwei Threads bedienen, sonst wärs wohl recht sinnlos, weil zu langsam. Doppelter Takt ist illusorisch, außer man will die CPU mit weniger als 2 GHZ bringen. :D
Bei Sun gibt es ja auch gleich das passende Betriebssystem mit eigenen angepassten Schedular dazu.
Auf den Prozessoren läuft auch Linux. Eine gemeinsame FPU hat nichts mit dem Scheduler des Betreibsystem zu tun.

Coda

2010-01-02, 17:08:31

Natürlich kann das Frontend zwei Threads bedienen, sonst wärs wohl recht sinnlos, weil zu langsam.
Wie das nachher in Logik gegossen ist (zwei getrennte Einheiten oder eine) sollte doch egal sein. Wobei man hier evtl. z.B. weniger Complex-Decoder eingebaut hat als bei zwei getrennten Einheiten nötig gewesen wären o.ä.

Ich sehe da schon Optimierungspotential.

Mir ging's aber um eine abstraktere Betrachtung. Und da kann man schon sagen, dass ein Bulldozer-Modul zwei Integer-Threads unabhängig ausführen kann.

reunion

2010-01-02, 17:13:20

AMDs CMT scheint auf jeden Fall eine sinnvolle Methode zu sein um mit wenig Transistoraufwand annähernd doppelte Leistung zu erreichen. Intels SMT kostet zwar nur um die 5% mehr Transistoren, kann je nach Situation allerdings auch mal Leistung kosten und bringt auch in best case selten mehr als 30%.

Wenn sie den Cache mitzählen, sicher nicht ;)
Und die FPU soll ja auch nicht die allerschlankste sein ... John Fruehe hat's irgendwo aufgeklärt, find's grad nit.

Wenn du es findest bitte melden. Der L1-Cache soll ja sehr klein werden.

mrt

2010-01-02, 18:06:40

Wie das nachher in Logik gegossen ist (zwei getrennte Einheiten oder eine) sollte doch egal sein. Wobei man hier evtl. z.B. weniger Complex-Decoder eingebaut hat als bei zwei getrennten Einheiten nötig gewesen wären o.ä.

Ich sehe da schon Optimierungspotential.

Mir ging's aber um eine abstraktere Betrachtung. Und da kann man schon sagen, dass ein Bulldozer-Modul zwei Integer-Threads unabhängig ausführen kann.
Getrennte Decoder wären in einigen Szenarien sicher schneller, kostet aber mehr Transistoren und ich kann, wenn zu wenige Threads vorhanden, nicht (praktikabel) den zweiten Int-Cluster (zusätzlich für den Thread auf Int-Core0) verwenden.
Naja zu abstrakt sollte man das nicht sehn, als Programmierer behandelt man BD-Kerne als Doppelkerner, aber diese Abstraktion ist doch bei der Betrachtung der Architektur nicht ziehlführend. ;)
Wenn du es findest bitte melden. Der L1-Cache soll ja sehr klein werden.
Die zwei Datencaches werden wohl ~32KB haben, jeweils natürlich, der Instruktionchache wohl 64KB (den teilen sich beide).

Zumindest sieht es nach den derzeitigen Informationen so aus.

Coda

2010-01-02, 18:14:10

Getrennte Decoder wären in einigen Szenarien sicher schneller
Das klingt so als würdest du den genauen Aufbau des Bulldozer-Decoders kennen. Na dann erzähl mal.

wenn zu wenige Threads vorhanden, nicht (praktikabel) den zweiten Int-Cluster (zusätzlich für den Thread auf Int-Core0) verwenden.
Ein Thread läuft immer nur durch eine Integer-Pipeline auf einem Modul, nicht auf beiden.

aylano

2010-01-02, 18:26:09

Ich verstehe nicht, warum L1 kleiner werden soll.

Im Vergleich zu Intel ist dieser eh schon ziemlich langsam.

Zwar hat Größe direkt nichts mit Geschwindigkeit zu tun, aber ein größerer L?-Cache hat ja auch seine Vorteile.

mrt

2010-01-02, 18:27:00

@coda
Dazu reichen mir die aktuellen Infromationen um das zu wissen. 12% mehr Transistoren und ein Decoder, der wird sicher nicht allzu komplex werden... Du hast es sogar selber schon angedeutet mit den Complexdecodern.

Wenn man ein gemeinsames Frontend und einen gemeinsamen L1I hat, kann wird man auch ein paar Transistoren verwenden um die Resourcen des anderen Int-Kerns zu nützen.

Nicht das überlesen: Zumindest sieht es nach den derzeitigen Informationen so aus.

@aylano
Die Cachegröße hat durchaus Auswirkungen auf die Zugriffgeschwindigkeit.

StefanV

2010-01-02, 18:39:28

Dafür gibts vielleicht noch 'nen Trace Cache, zumindest gibts entspechende AMD Patente, laut Dresdenboy (http://citavia.blog.de/).
Ich verstehe nicht, warum L1 kleiner werden soll.
1. Transistoren sparen
2. kürzere Zugriffszeit, entsprechend bessere Performance.

Im Vergleich zu Intel ist dieser eh schon ziemlich langsam.
Ja, aber ist er nicht ev. so langsam weil er so groß ist.

Zwar hat Größe direkt nichts mit Geschwindigkeit zu tun, aber ein größerer L?-Cache hat ja auch seine Vorteile.Doch, hats ;)
Ein größerer Cache ist idR langsamer als ein kleinerer, auch weil der Verwaltungsaufwand beim größeren Cache höher ist.

Coda

2010-01-02, 19:02:49

Wenn man ein gemeinsames Frontend und einen gemeinsamen L1I hat, kann wird man auch ein paar Transistoren verwenden um die Resourcen des anderen Int-Kerns zu nützen.
"Die paar Transistoren". Schau dir mal Tomasulo-Algorithmus an und sag das nochmal ohne ne Miene zu verziehen.

Ich verwette sonst was drauf, dass die Threads nicht beide Int-Kerne nutzen können. Sonst wäre das ganze auch einfach ein SMT-Chip mit 8 Integer-Pipelines und kein CMT mehr.

mrt

2010-01-02, 19:20:26

Man muss es nicht gleich übertreiben...

Coda

2010-01-02, 19:22:22

Was muss man nicht übertreiben?

Es ist wirklich sehr sehr unwahrscheinlich, dass ein Thread über beide Int-Cluster läuft. Wer sich mit Rechnerarchitektur auskennt wird mir da sicher zustimmen ;)

mrt

2010-01-02, 19:25:10

Ich nicht ;)
Ich geh aber auch davon aus, dass es sich hierbei nur um eine stark ausgebaute Variante von SMT handelt und physikalisch ein Kern arbeitet.

Coda

2010-01-02, 19:26:44

Dann sag mir was daran noch CMT sein soll?

Aber AMD trennt das Schaubild natürlich nur zum Spaß in zwei getrennte Integer-Scheduler und Pipelines und dazugehörigen L1-DCache auf:
http://ht4u.net/news2/news_images/amd_bulldozer_preview.jpg

Macht ja auch total Sinn, wenn ein Thread alle davon benutzen kann *facepalm*

mrt

2010-01-02, 19:28:29

So wie du dir das jetzt vorstellst, ist es doch geanu das was Sun macht. Wieso das ganze dann CMT nennen? Warum dann ein gemeinsames Frontend, TLB etc?

Naja Marketingfolien...
Die machen sicher aus 2 Int-ALU+AGU 4 Pipelines...

Coda

2010-01-02, 19:33:02

Ich stell mir gar nichts vor. Es ist schon mehr als schwer genug mit einem Thread vier Integer-Pipelines voll zu bekommen. Wer schonmal entsprechende Übungen und Überlegungen dazu gemacht hat weiß das auch.

Schau dir's an:
http://info.nuje.de/Bulldozer_Core_uArch_0.4.png

Warum ist wohl in den Int-Cores das "Thread Retirement" und nur der FP-Scheduler und das FP-Registerfile ist "shared"? Na?

Niagara T2 hat übrigens eine FPU per Core, da ist nichts mehr shared. T1 ist im Prinzip etwas ähnliches, aber die eine FPU für alle Cores ist durch deutlich höhere Latenzen und über einen Bus an sie angebunden. Das kann man so nicht direkt vergleichen. Die Bulldozer-FPU ist vollständig in das Modul eingebaut.

mrt

2010-01-02, 19:37:01

StefanV

2010-01-02, 19:38:36

Es ist wirklich sehr sehr unwahrscheinlich, dass ein Thread über beide Int-Cluster läuft. Wer sich mit Rechnerarchitektur auskennt wird mir da sicher zustimmen ;)
Das mag sein, es ist aber nicht unmöglich, hab letztens was von einem Andrew Glew (http://groups.google.com/group/comp.arch/browse_thread/thread/759bcccbfa0b8b07/3cd3bfa93b736a56?q=#3cd3bfa93b736a56) gesehen, der an CMT gearbeitet hat.

Der hat auch an dem sogenannte Speculative Multi Threading gearbeitet.
Das ist also durchaus möglich...

Coda

2010-01-02, 19:41:37

Das dachte ich mir ja Anfangs auch, allerdings bei nur 12% mehr Transistoren?
Ich halte Bulldozer für einen 4-fach superskalaren Kern, der, wenn 2 Threads aktiv sind, einem Thread fixe Resourcen, sprich zwei Int-ALUs+AGUs zuteilt.
Vielleicht hast du doch recht.

Nach dem Schaubild sind die "vier" Integer-Pipelines nämlich tatsächlich nur 2xAGU/ALU. Ich bin davon ausgegangen dass Bulldozer 2x4xAGU/ALU pro Cluster hat.

Aber evtl. ist das auch nur eine Falschinformation von dem der das Schaubild gemacht hat. Falls es wirklich so ist, dann sind die Voraussetzungen natürlich andere und es ergibt Sinn was du meinst.

Allerdings weiß ich dann immer noch nicht was noch der Unterschied zu SMT sein soll. Ich sehe keinen.

Der hat auch an dem sogenannte Speculative Multi Threading gearbeitet.
Das würde bedeuten, dass ein Thread bei einer Branch-Divergenz beide Cores benutzen kann. Das könnte sein, würde aber die Energieeffizienz schmälern.

StefanV

2010-01-02, 19:49:06

Das würde bedeuten, dass ein Thread bei einer Branch-Divergenz beide Cores benutzen kann. Das könnte sein, würde aber die Energieeffizienz schmälern.
Beide Cores?
Lass uns lieber von Int Clustern sprechen, die zusamen dann den (Bulldozer) Core bilden.

Aber ja, genau das würde es bedeuten.
Die Frage ist, ob AMD das (schon) implementiert hat und wenn ja, obs aktiv ist und wenns aktiv ist, wie viel es bringt bzw bringen könnte.

Also ich würd an dieser Stelle vermuten, das das im Design vorgesehen ist, man sich das aber für spätere Revisionen vorbehält.

Coda

2010-01-02, 19:50:23

Beide Cores?
Lass uns lieber von Int Clustern sprechen, die zusamen dann den (Bulldozer) Core bilden.
AMD bennent es andersrum, deshalb halte ich es auch so.

mrt

2010-01-02, 19:52:15

Bei SMT gibts keine zugesicherten Resourcen und die Abarbeitung erfolgt in den gleichen Pipelines.

Sollte ich auf dem Holzweg sein, was möglich ist, dann gibts mit Scoreboarding und spekulativer (Tread-) Ausführung Möglichkeiten die Resourcen zu nutzen, natürlich nicht so toll wie Tomasulo, dafür aber billiger.

Das Problem ist, dass 2x4-fach superskalare Kerne wohl mehr als 12% Transistoren im Vergleich zu einem K10-Kern brauchen. Ein weiteres, falls 2-fach superskalar stimmt, dass es verdammt mutig wäre schon 2011 mit vereinfachten Kernen zu kommen.

Coda

2010-01-02, 19:57:36

Bei SMT gibts keine zugesicherten Resourcen und die Abarbeitung erfolgt in den gleichen Pipelines.
Die Zugesicherte-Resourcen-Geschichte kannst du zwar als Argument bringen, aber in Wahrheit wird auch bei einem Nehalem kein Thread benachteiligt.

Das Problem ist, dass 2x4-fach superskalare Kerne wohl mehr als 12% Transistoren im Vergleich zu einem K10-Kern brauchen. Ein weiteres, falls 2-fach superskalar stimmt, dass es verdammt mutig wäre schon 2011 mit vereinfachten Kernen zu kommen.
Es kann auch einfach sein, dass sie das auf das ganze Die beziehen. Caches belegen schließlich inzwischen den größten Teil davon.

Für 2x4-fach superskalar wären die 12% rein pro Kern aber wirklich sehr wenig. Das schließt aber die 2x2-fach superskalar Möglichkeit nicht aus. Darauf würde ich in dem Fall nämlich wetten. Evtl. in Verbindung mit spekulativer Ausführung, wenn der andere Core frei ist.

Triskaine

2010-01-02, 20:08:54

Hier schwirrt einiges an Falschinformationen rum.

Klarstellung Nr.1: Die 12% beziehen sich auf die Transistoren die ein Integer Cluster zu einem gesamten Modul dazu addiert, nicht auf einen K10 Kern.

Klarstellung Nr.2: Der Instruction Cache von Bulldozer ist getrennt und wird nicht geshared(Quelle:http://it.anandtech.com/IT/showdoc.aspx?i=3681&p=3)

Klarstellung Nr.3: Der L1 Cache von AMD der K8/K10 Architektur ist dem der Core Architektur ebenbürtig, bzw. teilweise schneller. Assoziativität oder Größe sind nicht die entscheidende Messgröße, sondern Hitrate. (Quelle:http://www.realworldtech.com/page.cfm?ArticleID=RWT102808015436&p=7)

S940

2010-01-02, 20:16:46

Das "Schaubild" ist von Dresdenboy, k.A. wie das auf den niederländischen Server kam ;-)
(Sieht man auch an der Quellenangabe links unten)

Ob ein Kern jetzt 4 oder 2 issue ist weiss man nicht. Dresdenboy ist jetzt eher auch auf der 4issue Linie (er war zuvor 2issue "Fan", siehe Bild). Grund sind die Trace Caches, die können dafür sorgen, dass die 4 Pipes was zu tun bekommen.
A. Stillers 8 kByte L1 Cache Größe interpretiere ich deshalb eher als L0 Cache Größe ;-)

100% sicher ist aber nachwievor nichts.

Der I-Cache wird übrigens *nicht* gemeinsam sein, damit kann man auch die 1 Thread @ 2 Core Idee erst einmal begraben.
http://aceshardware.freeforums.org/post12356.html#p12356
(JF hats auf amdzone glaube ich auch nochmal bestätigt, hab aber gerade keine Zeit zum suchen.)
(Edit: Triskane hat es auch gepostet, sollte reichen.)

Das wiederum wäre auch ein Grund für 4issue: Nachdem es mit dem Verteilen eines Threads auf zwei 2issue Kerne nicht klappt, liegt eine Brachiallösung mit zwei (mehr oder minder) selbstständigen 4 issue INT Kernen nahe. Das Ding heißt schließlich Bulldozer und nicht Gänseblümchen.

Der SpecMT Ansatz wird vermutlich für den ersten CMT Kern zu komplex sein, die dürfen schon genügend andere Sachen debuggen. Ausserdem ist der vermeintliche Erfinder Glew ja nicht mehr verfügbar ;-)

ciao

Alex

mrt

2010-01-02, 20:20:00

Derzeit ist da einfach zu viel Spekulation dabei, die 12% beziehen sich allerdings tatsächlich auf ein Bulldozermodul.

Sofern sich Fruehe nicht irrt :D
http://blogs.amd.com/work/tag/bulldozer/
Die Zugesicherte-Resourcen-Geschichte kannst du zwar als Argument bringen, aber in Wahrheit wird auch bei einem Nehalem kein Thread benachteiligt.

Für 2x4-fach superskalar wären die 12% rein pro Kern aber wirklich sehr wenig. Das schließt aber die 2x2-fach superskalar Möglichkeit nicht aus. Darauf würde ich in dem Fall nämlich wetten. Evtl. in Verbindung mit spekulativer Ausführung, wenn der andere Core frei ist.
Benachteiligt nicht, aber das ist was anderes als zugesicherte Resourcen.
2x2 sicher nicht. Wenn ich mir Fruehes Blog so durchlese, wirds wohl doch auf eine Sun-Lösung hinauslaufen... dann ist aber die Bezeichnung CMT ein Witz. Allerdings ein Marketingmensch und eher vage Aussagen.

Coda

2010-01-02, 20:28:57

Wieso was sollte CMT deiner Meinung nach sonst beinhalten?

Das ganze Konzept zielt doch gerade darauf, dass man eben nur gewisse Teile zwischen zwei Kernen teilt - und eben nicht alle. Sonst hätte man ja wieder SMT ;)

mrt

2010-01-02, 20:31:13

Erstens empfinde ich es als unnötig Dingen einen neuen Namen zu geben und zweiten klingt das für mich eher nachdem was ich vorhin beschrieben habe.

Coda

2010-01-02, 20:41:17

Gerade hast du dich noch über die Bezeichnung CMT beschwert ;p

Gestrandet

2010-01-02, 20:42:34

(JF hats auf amdzone glaube ich auch nochmal bestätigt, hab aber gerade keine Zeit zum suchen.)

Auf amdzone findet man eh nix, das Board ist unaufgeräumter als ein Wühltisch beim Aldi in Bottrop.
Oder kann es sein, dass die Erläutungen Fruehes zum prozentualen Wachstum des BD-Moduls durch den 2. Integerkern von dort entfernt wurden? Finds nimmer.
Auf jeden Fall, um das nochmal klarzustellen, ging es bei den Prozenten immer nur um Bulldozermodul mit einem Int Core vs. Bulldozermodul mit 2 Int Cores.
Da war nie etwas relativ zum K10 gemeint.

mrt

2010-01-02, 20:57:19

Gerade hast du dich noch über die Bezeichnung CMT beschwert ;p
Na was ich auf der letzten Seite beschrieben habe. Allerdings empfinde ich 12% immernoch als wenig, immerhin wird der L1 auch verdoppelt.
Our engineers estimate that the amount of discrete circuitry that is added to each Bulldozer module in order to allow for a second integer thread to run only adds ~12% additional circuitry to each moduleThe Bulldozer architecture can provide up to 80% greater expected throughput when running 2 threads simultaneously compared to a single thread running on a single integer core.
Und vor allem "expected", wenn die noch keine lauffähigen Prototypen haben, dann wirds nichts mit 2011.

S940

2010-01-02, 21:58:28

Auf amdzone findet man eh nix, das Board ist unaufgeräumter als ein Wühltisch beim Aldi in Bottrop.
Oder kann es sein, dass die Erläutungen Fruehes zum prozentualen Wachstum des BD-Moduls durch den 2. Integerkern von dort entfernt wurden? Finds nimmer.
Auf jeden Fall, um das nochmal klarzustellen, ging es bei den Prozenten immer nur um Bulldozermodul mit einem Int Core vs. Bulldozermodul mit 2 Int Cores.
Da war nie etwas relativ zum K10 gemeint.
Ist egal, mrt hat oben seinen Blog verlinkt, da stehts auch.

Gast

2010-01-03, 00:13:26

Ich werde aus der ganzen Diskussion nicht ganz schlau:
http://blogs.amd.com/work/wp-content/uploads/2009/12/bulldozer-cache.jpg
http://www.blog.de/srv/media/media_popup_large.php?item_ID=3428291
http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=16128&stc=1&d=1251380135

Also ein BD-Modul hat 2 Integer und eine FPU Einheit.
Die Integer-Einheit hat je ein L1-Cache. Die FPU keins, aber benutzt den L1-Cache von beiden Integer-Einheiten.
Und jede der Integer-Einheiten hat je 2 AGU+ALU Einheiten.

Nun:
Das BD-Modul sieht für das OS wie ein Core aus?
Ein BD-Modul kann CMT ausführen?
Oder jedes der Integer-Einheiten kann noch zusätzlich SMT ausführen oder CMT?
Danke für die Aufhellung...

StefanV

2010-01-03, 01:24:45

Bei den Integer EInheiten ist noch nicht klar, obs 2 Agus + 2 AGUs sind oder obs 4 universelle sind, Dresdenboy glaubt momentan eher an die universellen Einheiten, die alles können.

Ein BD Modul schaut fürs OS auch wie ein 2 Kern Prozessor aus.

aylano

2010-01-03, 10:46:55

Und was ist der Unterschied zwischen einer Universellen & einer normalen Pipeline (AGU + ALU) ????

S940

2010-01-03, 11:09:46

Und was ist der Unterschied zwischen einer Universellen & einer normalen Pipeline (AGU + ALU) ????
Naja, grob gesehen ist es einfach, die universellen sind flexibler, sagt ja schon der Name :)

Anstatt fest auf 2 ALU plus 2 AGU festgelegt zu sein, hättest Du bei 4 Universalpipes mehr Kombinationsmöglichkeiten. Könnte z.B. praktisch sein, wenn die dicke FPU viele LD/STRs hat, für das müssen ja die INT Einheiten genutzt werden.

Angenommen die FPU bräuchte jetzt 2 AGUs, dann hingen die 2 ALUs beim 2+2 Ansatz mehr oder minder in der Luft, mit universalen 4 Pipes könnte man dagegen noch 1 Instruktion mit einem LD oder Str durch die beiden übrigen Pipes schleußen.

ciao

Alex

HOT

2010-01-03, 13:24:16

AMD spricht nur von "Pipelines". Sie werden wohl wirklich universell sein, also ALU/AGU. AMD führt zudem den SSE/AVX-Code jetzt wohl auch über die ALUs aus, nicht nur über die FPU - das könnte ein guter Grund sein, warum es 4 Pipelines sind.
BD kann also theoretisch in einem Takt 2x256Bit Int-SIMD und 1x256Bit fp-SIMD-Code pro Modul durchbringen und das gleichzeitig.

Gast

2010-01-03, 13:42:55

Schau dir's an:
http://info.nuje.de/Bulldozer_Core_uArch_0.4.png

Das Bild war nur die erste Version von Dresdenboy. Die zweite Version [vom 28.07.2009] sieht so aus:

http://info.nuje.de/Bulldozer_Core_uArch_0.5b.png

Link: http://citavia.blog.de/page/2/

Coda

2010-01-03, 16:14:17

Okay. Ist jetzt aber auch nicht aufschlussreicher als das alte was das Thema angeht.

StefanV

2010-01-03, 16:41:55

Ja, vorallen weil er seine Meinung zu den INT Einheiten geändert hat, auch andere Dinge.

Coda

2010-01-03, 17:41:22

Ich schrieb "nicht aufschlussreicher".

Gestrandet

2010-01-03, 17:50:04

Ich glaub StefanV wollte damit sagen, dass auch die 2. Version des Diagramms nicht mehr dem "Stand der Forschung" (von Dresdenboy) entspricht.

Gipsel

2010-01-04, 00:43:23

Die FPU wird natürlich aus dem L1-Cache des jeweiligen Cores gefüttert aus dem die Daten kommen.
Oder wenn der L2 schnell genug wird und die Pipeline der FPU sowieso entsprechend lang ist, füttert man die FPU aus dem L2. Beim P4 konnte man sowas in der Art schon mal sehen.
BD kann also theoretisch in einem Takt 2x256Bit Int-SIMD und 1x256Bit fp-SIMD-Code pro Modul durchbringen und das gleichzeitig.
Dann benötigt man aber wohl wirklich einen ziemlich breit angebundenen TraceCache (deutlich besser als der 3µOps/Takt-Quark beim P4). Das wird sonst nämlich unter Umständen eng, daß die Decoder so viel hergeben. Für 256Bit SIMD auf 4 x 64 Bit Pipelines benötigt man ja 4 µOps. Bei dem momentanen ALU/AGU-Paaren hält AMD ja den Verwaltungsaufwand dadurch gering, daß die kombinierten µOps erst in den reservation Stations gesplittet werden. Bei universellen Pipelines geht das dann nicht mehr. Weiterhin werden die 256Bit-Ops für die FPU auch aus mindestens zwei 128Bit µOps bestehen. Damit kommt man also schon auf mindestens 12 µOps/Takt für ein Modul, die man hoffentlich auch kontinuierlich irgendwo herbekommt.

Edit:
Ich ging von der Spekulation aus, daß die FPU entweder 2x128Bit FMA oder 2x128Bit ADD + 2x128Bit MUL kann.

Triskaine

2010-01-04, 11:33:08

Ich ging von der Spekulation aus, daß die FPU entweder 2x128Bit FMA oder 2x128Bit ADD + 2x128Bit MUL kann.

Laut John Fruehe von AMD kann die FPU entweder mit 256Bit rechnen oder mit 2 x 128Bit. Deswegen ist die 1x256Bit ADD + 1x256-bit MUl oder 1x256-bit FMA Variante meiner Meinung nach am wahrscheinlichsten, das wären 16 SP FLOPS pro Takt. Ich denke das sollte mit einem dicken Front End plus Trace Cache durchaus erzielbar sein.

Coda

2010-01-04, 11:42:38

256 bit? Auf welchem Datentyp jetzt?

Edit: Okay, 4x64 Bit Integer oder eben AVX. Gibt's XOP eigentlich auch bei Intel?

Triskaine

2010-01-04, 11:51:46

Von Intel weiß man nichts offizielles, aber ich bin mir sehr sehr sicher das Intel XOP nicht unterstützt, nicht unterstützen will und auch niemals unterstützen wird, genauso wie es bei allen anderen AMD eigenen ISA Erweiterungen geschah. Wenn ihnen einige Instruktionen von XOP gefallen, nehmen sie diese vielleicht in die nächste Version von AVX auf. x86 ist der Rekordhalter unter den ISAs was die Anzahl der Instruktionen betrifft und so wie es es aussieht wird sich auch in den nächsten Jahren [leider] nichts daran ändern.

reunion

2010-01-04, 11:58:15

FMA4 gibt es wohl auch nur von AMD nachdem Intel wieder zurück gerudert ist. Hier wird die Entwicklung sehr schon auf zwei Seiten beschrieben: http://www.planet3dnow.de/vbulletin/showthread.php?t=362353

S940

2010-01-04, 14:15:25

Wenn ihnen einige Instruktionen von XOP gefallen, nehmen sie diese vielleicht in die nächste Version von AVX auf.

Sehr, sehr unwahrscheinlich, wenn Ihnen was gefällt, dann bringen sie ein inkompatible Kopie mit eigenem C4h (VEX) Präfix heraus. Haben sie bisher immer so gemacht, ist einfacher für Intel, da sie a) Standards setzen können und so b) keine / weniger Änderungen am x86 Decoder gemacht werden müssen. Fürs AMD Präfix F8h wäre Mehraufwand.

Ist aber auch so unwahrscheinlich, AVX ist nicht viel mehr als eine teilweise 256bittige SSE5 Kopie. XOP wiederum sind die AMD eigenen SSE5 Überbleibsel, die Intel nicht in AVX übernommen hat.

Ergo: XOP interessiert intel nicht wirklich, sonst gäbs das bereits in AVX. Allerhöchstens könnte man noch darüber spekulieren, dass die jeweiligen Befehle zu schlecht in die Intel Architektur integrierbar gewesen wären. Aber das weiss erst einmal keiner ausser Intel.

ciao

Alex

Gipsel

2010-01-04, 14:16:20

Laut John Fruehe von AMD kann die FPU entweder mit 256Bit rechnen oder mit 2 x 128Bit. Deswegen ist die 1x256Bit ADD + 1x256-bit MUl oder 1x256-bit FMA Variante meiner Meinung nach am wahrscheinlichsten, das wären 16 SP FLOPS pro Takt. Ich denke das sollte mit einem dicken Front End plus Trace Cache durchaus erzielbar sein.
Das ist trotzdem noch nicht klar und es gibt durchaus ernst zu nehmende Spekulationen, daß eine FMA-Einheit eventuell nicht nur FMA sondern alternativ auch ADD und MUL separat durchführen kann. Da benötigt man "nur" ein paar zusätzliche Datenpfade, an den Recheneinheiten ist der Aufwand überschaubar.

Die Evergreen-GPUs von ATI haben übrigens eine ähnliche Funktionalität schon eingebaut ;). So kann der Wert in der FMA-Einheit im aktuellen Rundungsmodus vor der Addition gerundet werden (für das Rausschreiben des Zwischenwerts reicht allerdings die Bandbreite der Einheiten nicht). Außerdem können auch zwei Einheiten (in einem Spezialfall sogar 4) kaskadiert werden, so daß zwei (bzw. vier) abhängige Instruktionen in einem Takt abgesetzt werden können. Übrigens ohne Abschläge beim Durchsatz. Ziemlich nett :D. Die Kombination dieser beiden Eigenschaften könnte man dann vielleicht beim BD erwarten ;)

Gast

2010-01-15, 22:28:09

gibt es nichts neues zu Bulldozer?

was kommt nach dem Bulldozer? Wann wird ein Nachfolger eingeplant?

Bei Intel soll ja nach Snady Bridge > Ivy Bridge kommen

Wird man den Bullodzer nach 32nm shrinken und daraus ein Mega Monster machen?

bitte aufwachen ;)

Naitsabes

2010-01-16, 00:13:00

Bulldozer wird sowieso in 32nm gefertigt.

StefanV

2010-01-16, 00:34:03

Genau, der kommt eh in 32nm, nächstes Jahr...

Er hat auch nicht 4x unified Integer Pipes sondern 'nur' 2x Alu +2x AGU.

Coda

2010-01-16, 01:49:27

Das ist trotzdem noch nicht klar und es gibt durchaus ernst zu nehmende Spekulationen, daß eine FMA-Einheit eventuell nicht nur FMA sondern alternativ auch ADD und MUL separat durchführen kann. Da benötigt man "nur" ein paar zusätzliche Datenpfade, an den Recheneinheiten ist der Aufwand überschaubar.

Die Evergreen-GPUs von ATI haben übrigens eine ähnliche Funktionalität schon eingebaut ;). So kann der Wert in der FMA-Einheit im aktuellen Rundungsmodus vor der Addition gerundet werden (für das Rausschreiben des Zwischenwerts reicht allerdings die Bandbreite der Einheiten nicht). Außerdem können auch zwei Einheiten (in einem Spezialfall sogar 4) kaskadiert werden, so daß zwei (bzw. vier) abhängige Instruktionen in einem Takt abgesetzt werden können. Übrigens ohne Abschläge beim Durchsatz. Ziemlich nett :D. Die Kombination dieser beiden Eigenschaften könnte man dann vielleicht beim BD erwarten ;)
Was in GPUs geht muss noch lange nicht in CPUs funktioniert.

Die kritischen Pfade sind auf ganz andere Taktraten ausgelegt.

Gipsel

2010-01-16, 02:39:41

Was in GPUs geht muss noch lange nicht in CPUs funktioniert.

Die kritischen Pfade sind auf ganz andere Taktraten ausgelegt.
Trotzdem gibt es schon ein paar Schaubilder, die Bulldozer mit einer "bridged FMA"-Einheit zeigen. Ist ja im Prinzip nicht soo viel aufwendiger, würde aber eben 8 DP-Flops oder 16 SP-Flops pro Takt auch ohne explizite Verwendung von FMA-Befehlen erlauben. Gemäß den letzten Spekulationen wird das afaik sogar als wahrscheinlichste Lösung angesehen.

Die Evergreen-GPUs waren ja nur ein Beispiel, daß sowas prinzipiell geht (auch wenn das da in Ermangelung der Datenpfade dort etwas anderes ist). Und GPUs sind nicht nur auf geringere Taktraten ausgelegt, sie nutzen auch längst nicht so viele leakige, dafür aber schnelle Transistoren in den Ausführungseinheiten ;). Außerdem hat bei Evergreen ein madd eine Latenz von 4 Takten (bei Nutzung des dependent coissue), oder wie man am Fall des DP4 sieht wohl noch etwas weniger (da wird allerdings eine Normalisierung zwischendurch weggelassen). K10 hat 4 Takte Latenz für ein einfaches MUL, Core2/Core i7 haben 5 bzw. 6 Takte. Von Bulldozer erwarte ich auch eher 6 Takte, da kann also auch dann auch der Takt etwas höher sein, als wenn das Ergebnis schon nach 3 Takten oder so da sein muß ;)

Gast

2010-01-16, 12:43:02

ich meinte was kommt nach Bulldozer für 2012/2013, also der 32nm Nachfolger? evtl. 22nm....

Knuddelbearli

2010-01-16, 15:00:43

2013 dürfte man mit 22nm rechnen können wenn nix katastrophal schiefgeht ja

Gast

2010-01-17, 22:01:49

"This looks like an official confirmation for an integer core having 2 ALUs and 2 AGUs."

http://citavia.blog.de/2010/01/11/another-bulldozer-article-from-japan-7737558/

S940

2010-01-21, 02:30:40

Cachegrößen sind durchgesickert:

L1: 16kB
L2: 2 MB

Quelle:
http://www.realworldtech.com/forums/?action=detail&id=106752&threadid=106752&roomid=2

robbitop

2010-01-21, 08:50:08

Cachegrößen sind durchgesickert:

L1: 16kB
L2: 2 MB

Quelle:
http://www.realworldtech.com/forums/?action=detail&id=106752&threadid=106752&roomid=2
Soweit ich weiß sind es 16 kiB L1D.

S940

2010-01-21, 11:19:24

Soweit ich weiß sind es 16 kiB L1D.
Heißt das jetzt, dass Du eine eigene Quelle hast, oder wolltest Du nur auf ironische Weise die obige Info genauer spezifizieren ?

BlackBirdSR

2010-01-21, 12:22:33

Damit könnte man die Zugriffslatenz auf den L1-Cache absenken und/oder den Takt der Kerne erhöhen.

Allerdings wird durch den Zugriff auf den Shared L2-Cache mehr Zeit verbraten, also sollte eines davon schon passieren ;)

Edit: Sollten die Werte stimmen....

Undertaker

2010-01-21, 12:28:52

Heißt das jetzt kein L3? Oder ist der nur noch nicht bekannt?

robbitop

2010-01-21, 13:54:45

Heißt das jetzt, dass Du eine eigene Quelle hast, oder wolltest Du nur auf ironische Weise die obige Info genauer spezifizieren ?
Ich wollte es auf sachliche Weise präzisieren. Meine Quelle: http://www.planet3dnow.de/vbulletin/showpost.php?p=4125331&postcount=2250

Denn 16 kiB L1 klingen recht wenig. Da es 16 kiB L1-D sind, muss noch der L1-I hinzugerechnet werden. Und pro Modul sind 2x L1-D vorhanden.

Heißt das jetzt kein L3?

http://www.planet3dnow.de/photoplog/file.php?n=8212&w=o
L3 ist auf jeden Fall vorhanden.

Gast Stoffel

2010-01-21, 17:52:43

ist zwar ot aber S940 und opteron ist die selbe Person ;-) ansonsten kann ich auch das P3D Forum im Bezug auf Bulldozer empfehlen.
Auch wenn es öftermal meinen Horizont übersteigt.

HOT

2010-01-21, 23:36:21

Könnte so aussehen:
(xx kiB L0 pro Kern)
16kiB L1D pro Kern
32kiB L1I pro Modul
2MiB L2 pro Modul
8MiB L3 für 4 Module
= über 16MiB pro Die

(= 1 Orochi-Die, also Valencia, Interlagos, Zambezi-Basis)

Die Fusion-Kerne bekommen mMn auch in der BD-Generation keinen L3, sondern nur die high-End und Profi-Modelle, wie beim Phenom ja im Prinzip auch.

robbitop

2010-01-22, 08:54:20

Könnte so aussehen:
(xx kiB L0 pro Kern)
Kommt der L0 nur aus den Patentrecherchen von Dresdenboy? In den AMD Folien wurden L1 - L3 benannt aber kein L0. Warum sollte man soetwas tun? Ich tippe eher auf Wunschdenken (so wie auch das Spekulative CMT).

16kiB L1D pro Kern
32kiB L1I pro Modul
.
Der Data Cache ist doch pro Modul 2x vorhanden. Möglicherweise ist der L1I größer oder kleiner als der L1D. War beim Atom bspw. auch so.

HOT

2010-01-22, 22:26:28

Kommt der L0 nur aus den Patentrecherchen von Dresdenboy? In den AMD Folien wurden L1 - L3 benannt aber kein L0. Warum sollte man soetwas tun? Ich tippe eher auf Wunschdenken (so wie auch das Spekulative CMT).

Ich setzte es nicht umsonst in Klammern ;).

Der Data Cache ist doch pro Modul 2x vorhanden. Möglicherweise ist der L1I größer oder kleiner als der L1D. War beim Atom bspw. auch so.
Hm... ich bin mir jetzt nicht sicher, aber du beschreibst in Worten, was ich in der Aufstellung schrieb. 16kiB L1D pro Kern = 2 x 16kiB L1D pro Modul und 32kiB L1I pro Modul ist > je L1D :D.

robbitop

2010-01-23, 09:40:38

Ich setzte es nicht umsonst in Klammern ;).

Hm... ich bin mir jetzt nicht sicher, aber du beschreibst in Worten, was ich in der Aufstellung schrieb. 16kiB L1D pro Kern = 2 x 16kiB L1D pro Modul und 32kiB L1I pro Modul ist > je L1D :D.
L1I soll wohl auch 2x vorhanden sein.
Aber unabhängig davon meine ich, dass pro Kern L1D und L1I verschieden groß sein kann. Bspw 16 kiB L1D und 24 kiB L1I

BlackBirdSR

2010-01-23, 10:11:12

gut moeglich dass der l1 nur einmal vorhanden ist und von hier aus die befehle erst verteilt werden.

S940

2010-01-23, 11:57:16

gut moeglich dass der l1 nur einmal vorhanden ist und von hier aus die befehle erst verteilt werden.

Möglich wärs natürlich aber laut Johan (ehemals aceshardware) und seinen direkten AMD Quellen, gibts den 2x:

• Two integer clusters share fetch and decode logic but have their own dedicated Instruction and Data cache

http://it.anandtech.com/IT/showdoc.aspx?i=3681&p=3

Man könnte höchstens noch spekulieren, dass sie Ihn gezielt Falschinformationen zugesteckt haben.

Sinn des ganzen ... keine Ahnung, vielleicht sind ja die Dekoder double pumped und greifen abwechselnd auf die 2 Caches zu. Aber bei der Idee ist viel Fantasie dabei :)

ciao

Alex

Gestrandet

2010-01-23, 12:19:22

Man könnte höchstens noch spekulieren, dass sie Ihn gezielt Falschinformationen zugesteckt haben.
Wenn, dann denke ich eher dass sie ungezielt zugesteckt wurden. Aber wahrscheinlich sind bei AMD genau wie die Planned Production auch technische Spezifikationen einem steten Wandel unterworfen, alles ist im Fluss ...
nee, in dem Laden weiß doch oft die rechte Hand nicht was die Linke tut und das Bewusstsein, was eine Info in der Öffentlichkeit nach sich ziehen kann scheint vielen dort zu fehlen. Da wäre mal ne unternehmensweite Schulung angebracht. Da gibts zu viele, die zu gern mit ihrem Wissen protzen anstatt erstmal zu klären ob sie das a) preisgeben dürfen und es b) überhaupt stimmt.

BlackBirdSR

2010-01-23, 13:49:11

Sinn des ganzen ... keine Ahnung, vielleicht sind ja die Dekoder double pumped und greifen abwechselnd auf die 2 Caches zu. Aber bei der Idee ist viel Fantasie dabei :)

ciao

Alex

Ähm... ja.. viel zu viel.

Der Standardablauf ist ja: L1I-Fetch-Decode-Dispatch
Wenn die beiden Cluster sich das Fetch-Decode-Frontend teilen, aber jeweils einen einzelnen I-Cache haben, dann sollte dieser eigentlich eher nach Decode kommen, wäre dann ein L0-Cache. Das Konzept ist ja schonmal beim originalen K9 angesprochen worden.

Wenn Übersetzung, Adressgenerierung, Sprungvorhersage beim P4 schon ein Taktproblem darstellten, dann wird das bei AMD nicht anders sein. Höher getaktete Decoder halte ich erstmal für wenig erfolgversprechend mit Hinblick auf die weitere Taktskalierung.
Noch breiter als beim Core2 ist dann wieder ein Effizienzproblem, siehe original K9.

Wenn man mit Core2-ähnlichen Decodern sicherstellen kann, dass ca. 2-2.5 Operationen pro Takt durchgehen, dann reicht das ja völlig aus. Aktuelle CPUs sind ja schon froh, wenn am Ende 1-1.5 Ops die Pipeline wieder verlassen.

john carmack

2010-07-13, 12:03:46

Schade da man den Bulldozer so lange verschoben hat.

Jetzt muss er sich gegen die SandyBridge beweisen...
ob das gut geht?

Immerhin hat Intel mit der "Core" und "Nehalem" Architektur schon wirklich große schritte nach vorne gemacht.

Gönnen würde ich es allerdings AMD. Die haben es sich mal wieder verdient.

john carmack

2010-07-14, 13:43:35

Seitens Citavia gibt es neue Details zum kommenden Bulldozer-Prozessorendesign seitens AMD: Danach enthält wohl jeder der zwei Teilkerne eines Bulldozer-Kerns gleich vier ALUs (Arithmetic Logic Units) und drei oder vier AGUs (Address Generation Units), was ziemlich heftig wäre – denn bisher konnte man auch annehmen, daß sich die auf verschiedenen Schemabildern eingezeichneten vier Einheiten in einem Teilkern auch auf 2 ALUs und 2 AGUs aufschlüsseln lassen, nun ist es wohl das doppelte. Damit hat einer der beiden Teilkerne eines Bulldozer-Kerns schon mehr Integerpower als ein K10-Recherkern, welcher drei ALUs und drei AGUs aufbieten kann – und Bulldozer hat wie gesagt gleich zwei Integer-Minikerne in einem Rechenkern.

Natürlich muß diese geballte Rechenleistung auch anständig über den Scheduler gefüttert werden können, was derzeit alles noch im weitgehend unbekannten Bereich liegt – aber so ist zumindest das Potential dafür vorhanden, daß AMD bei der Pro/MHz-Leistung mal wirklich erhebliche Verbesserungen hinbekommt, um auf die diesbezüglich klar führende Nehalem-Prozessorenarchitektur von Intel aufschließen zu können. Schließlich sind Taktraten nun einmal vom Produktionsverfahren her begrenzt und kann AMD nicht ewig immer nur mit höheren Taktraten der besseren Pro/MHz-Leistung von Intel hinterherhecheln – irgendwann muß einfach mal ein größerer Sprung in die Richtung höhere Pro/MHz-Leistung auch bei AMD kommen. Bulldozer scheint ganz klar in diese Richtung zu gehen und hat sogar das Potential, Intel in dieser Frage richtig unter Druck zu setzen. Allerdings wird sich auch Bulldozer schon nicht mehr an der Nehalem-, sondern dann an der Sandy-Bridge-Architektur messen lassen müssen.

Leonidas

2010-07-15, 09:59:04

Link dazu, damit man es im Original lesen kann:
http://citavia.blog.de/2010/07/06/bulldozer-likely-with-4-alus-and-at-least-3-agus-per-core-8927293/

merfu

2010-07-18, 14:10:50

Bulldozers Tape-Out wohl erfolgt.

http://www.computerbase.de/news/hardware/prozessoren/amd/2010/juli/tape-out_amds_bulldozer/
http://hartware.net/news_49628.html

MfG
Merfu

Gast

2010-07-20, 15:16:29

http://www.stabroeknews.com/images/2009/04/20090306collapsed.jpg :D

john carmack

2010-07-21, 13:46:32

AMD Bulldozer-CPUs liegen im Zeitplan

Bulldozer ist der Codename für AMDs neue Prozessorgeneration, mit der man nicht nur mehr den Low-Cost- und Mainstream-Markt aufmischen möchte, sondern auch in der High-End-Sparte auf Intel aufschließen will. Bis dato hat AMD beteuert, mit der neuen Generation im ersten Halbjahr 2011 an den Start zu gehen. Der Zeitraum war dabei bewusst großzügig gewählt, um eventuelle Schwierigkeiten beim Fertigungswechsel - Umstieg auf 32 nm-SOI - einzukalkulieren.
Jetzt sind viel versprechende Details über den derzeitigen Entwicklungsstand der neuen AMD-CPUs nach außen gedrungen.

Wie AMD-CEO Dirk Meyer im Rahmen einer Telefonkonferenz zu Wort gegeben haben soll, haben die Bulldozer-CPUs, welche in der Desktop-Variante mit vier und acht Kernen Zambezi heißen sollen, bereits ihr Tape-Out im letzten Quartal gemeistert. Dies heißt, dass die sehnsüchtig erwarteten AMD-Boliden zwischen April und Juni dieses Jahres erstmals lauffähig waren. Man kann dies als gutes Zeichen auslegen, aber noch keinesfalls daraufhin schlussfolgern, wann letztendlich im Handel die Prozessoren zu erwerben sein werden. Denn üblicherweise werden mit neuen Steppings bis zur Marktreife noch (viele) Fehler korrigiert. Und wie eingangs erwähnt, entscheidet auch der neue 32 nm-SOI-Prozess, welcher auf den Bulldozer-CPUs erstmals Verwendung finden soll, über den Launchzeitpunkt.

Wie es weiter heißt, soll es in diesem Jahr aber noch erste Samples für die Desktop- und Server-Versionen geben. Den Zeitraum grenzt man aber auch hier nicht weiter ein, so dass theoretisch erst zu Weihnachten Samples vom Band laufen könnten. Bis dahin dürfte dann aber auch die Frage, ob die neuen Prozessoren mit dem derzeitigen Sockel AM3 abwärtskompatibel sein werden, beantwortet sein, welche erst vor wenigen Tagen wegen einer Fudzilla-Meldung neu aufflammte.

Weitere offizielle Informationen zu AMDs neuer Prozessorgeneration werden wahrscheinlich in gut einem Monat auf dem "Hot Chips"-Symposium am 24. August nach außen sickern.

http://www.hardware-infos.com/news.php?news=3624

Gast

2010-07-21, 13:56:25

Der CEO hat nur gesagt, dass der erste Bulldozer basierte Chip seinen Tape-Out hatte, aber nicht welcher. Kann also auch der Valencia gewesen sein.

Gast

2010-07-21, 13:57:37

Sorry für den Doppelpost

Wann bitte hat AMD den ersten Bulldozer für das erste Halbjahr angekündigt?

Sorkalm

2010-07-21, 15:15:52

IMHO hieß es immer nur 2011, ohne Halbjahre.

S940

2010-07-21, 15:38:09

IMHO hieß es immer nur 2011, ohne Halbjahre.Jupp so siehts aus, das mit dem Halbjahr war bei Llano.
Meine persönliche Prognose für Orochi ist frühestens Q3 - aber ich weiß selbstverständlich nix Genaues ;-)

Pirx

2010-07-21, 16:06:54

Das kannst du doch nicht ernst meinen, ich sitze ja jetzt schon deswegen wie auf glühenden Kohlen (bzw. auf einem lauwarmen X2).;(

Undertaker

2010-07-21, 16:09:34

Frage nur, womit lassen sich weitere >12 Monate ohne weitere Leistungsupgrades überbrücken? Der 45nm Prozess dürfte weitestgehend ausoptimiert sein, weitere Taktsteigerungen zumindest nicht ohne TDP-Erhöhung möglich.

Ich bin darum mal optimistischer und sage spätestens Q2. ;)

S940

2010-07-21, 17:06:35

Das kannst du doch nicht ernst meinen, ich sitze ja jetzt schon deswegen wie auf glühenden Kohlen (bzw. auf einem lauwarmen X2).;(
Nen vorgezogenen Opteronstart zum Opteron Geburstag im April mit nem früheren Stepping will ich nicht ausschließen. Aber das würde Dir dann auch nicht weiterhelfen ^^

Das ganze ist ne simple Pi*Daumen Rechnung. Vor einer B3 Revision hat AMD nichts auf den Markt geworfen, und erst die C Revision des Siliziums war wirklich brauchbar.

Tape-Out heißt, dass der A0 Plan im letzten Quartal fertig war. Wenn alles gut ging haben sie nach 2-3 Monaten Produktion in der Fab somit jetzt im Moment erstes A0 Silizium in Händen.
Ein Metalllayerswitch (Erhöhung der Zahl an zweiter Stelle, z.B: A0 -> A1), dauert 2-3 Monate zur Produktion, eine komplette Änderung (z.B. A0->B0) bis zu nem halben Jahr, minimal ca. 4 Monate.

Dazu kommt dann noch die Zeit der Fehlersuche, plus die Zeit die man zur Fehlerlösung benötigt. Also Mitte 2011 ist das beste was ich da sehe.

Große Unbekannte sind aber die Gerüchte, nachdem jemand schon im Dez. einen laufenden Bulldozer gesehen hätte.

Da könnte man über einen frühren Prototypen mit SSE5 statt AVX in 45nm spekulieren. Wenn dem so wäre, würde der aktuelle BD quasi schon mit Rev.B starten und die groben Bugs sollten schon alle ausgemerzt sein.

Aber tja ... wenn das Wörtchen wenn nicht wäre. Warten wir mal Ende August ab, vielleicht gibts dann Neues zum Fahrplan.

ciao

Alex

Undertaker

2010-07-21, 17:11:25

Genauergesagt, 24.8. um 5.00 pm Ortszeit gibts die Bulldozer-Keynote:

http://www.hotchips.org/program/conference-day-two/

john carmack

2010-07-21, 20:04:52

spannend... :-)

Wenn ich mal die Experten hier in der Runde fragen darf:
(auch wenn noch kaum echte Infos rund um die CPU´s gibt)

Welche CPU seht ihr nach dem entgültigen Release vorne?

Intel Sandy Bridge oder AMD Bulldozer?

robbitop

2010-07-21, 20:07:16

AFAIK gibt es schon seit einer Weile lauffähige Bulldozersamples bei AMD. Hat unser Freund von hardware-infos nicht sogar Benches an einem Bulldozer gesehen?
Das heißt, A0 ist schon eine ganze Weile weg. Ich nehme an, dass sie mit Tapeout den ersten Release Candidate für die Serienproduktion meinen.

y33H@

2010-07-21, 20:41:57

Türlich gibt's schon Pre-Samples und Sandy-ES wie Sand(y) am Meer ;D

MR2

2010-07-21, 21:58:48

Na w0mbat hat lauffähige Samples gesehen, aber das können auch noch 45nm Testsamples gewesen sein, da das schon ne Weile her war.

Opteron schriebs ja auf der letzten Seite....:

Große Unbekannte sind aber die Gerüchte, nachdem jemand schon im Dez. einen laufenden Bulldozer gesehen hätte.
Da könnte man über einen frühren Prototypen mit SSE5 statt AVX in 45nm spekulieren. Wenn dem so wäre, würde der aktuelle BD quasi schon mit Rev.B starten und die groben Bugs sollten schon alle ausgemerzt sein.

robbitop

2010-07-21, 22:03:22

Na w0mbat hat lauffähige Samples gesehen, aber das können auch noch 45nm Testsamples gewesen sein, da das schon ne Weile her war.
Halte ich für unwahrscheinlich. Man entwickelt ein Design für ein vorher definierten Prozess. Das Design für einen Vorgängerprozess zu adaptieren, um ein paar Pre-Samples zu haben, wäre viel zu aufwändig.
Wenn es Pre-Samples gab, dann waren sie im Zielprozess.

Ronny145

2010-07-21, 22:05:45

Na w0mbat hat lauffähige Samples gesehen, aber das können auch noch 45nm Testsamples gewesen sein, da das schon ne Weile her war.

Man sollte nicht immer alles glauben und schon gar nicht von wombat. :rolleyes:

MR2

2010-07-21, 22:09:07

Naja, die Bulldozer Architektur sollte schon 2009 erscheinen, wurde ja auf 2011 verschoben... Und wenn ich eigene Chipfabriken habe, wieso sollte es nicht schon ne Hand voll 45nm Samples geben?

Gast

2010-07-21, 22:12:01

Welche CPU seht ihr nach dem entgültigen Release vorne?

Intel Sandy Bridge oder AMD Bulldozer?
Bis Bulldozer kommt steht vermutlich schon der Sandy-Nachfolger in den Startlöchern, hoffentlich launcht AMD vorher. Bulldozer-Designs werden aber vor allem bei massiv parallelisierten Aufgaben oder als Server-Arbeitstiere die Nase vorn haben. Ich denke Bulldozer wird der robuste Ackergaul und Sandy eher die flinke Gazelle, je nach Einsatzzweck profitierst du vom einen oder anderen Prozessor und das Konkurrenzprodukt ist eher uninteressant.

Die Single-Thread Leistung wird sicher wenigstens so gut wie bei der K10.5-Architektur, eher sogar besser und in die Nähe von Nehalem kommen. Dafür können nativ 8 Threads bearbeitet werden, und dank AVX zieht man auch in Sachen Befehlssatz mit Intel gleich. Bleibt halt noch die Frage, wie hoch die Taktraten der ersten Generation gehen. Wenn wir gleich 3Ghz und mehr sehen, werden die Dinger Granaten.

Sorkalm

2010-07-21, 22:32:05

Naja, die Bulldozer Architektur sollte schon 2009 erscheinen, wurde ja auf 2011 verschoben... Und wenn ich eigene Chipfabriken habe, wieso sollte es nicht schon ne Hand voll 45nm Samples geben?

Das wurde viel früher verschoben IMHO ... da war man noch auf den Zeichenbrettern oder in Simulatoren...

Gast

2010-07-21, 22:54:42

Frage nur, womit lassen sich weitere >12 Monate ohne weitere Leistungsupgrades überbrücken? Der 45nm Prozess dürfte weitestgehend ausoptimiert sein, weitere Taktsteigerungen zumindest nicht ohne TDP-Erhöhung möglich.

ganz einfach, 10x K10.5 Kerne in 32nm auf einem DIE für den Dektop :D

Pirx

2010-07-22, 08:13:46

Würden ja vielleicht auch "schon" 4 @32nm mit unglaublich hohen Taktraten reichen.
Glaube ich zwar nicht dran, aber irgendwas muß doch AMD noch bis zum BD machen. Und der BD kommt ja sowieso erstmal für Server.

Undertaker

2010-07-22, 10:07:39

Das würde aber alles einen zusätzlichen Die erfordern - von einem solchen ist bisher nichts bekannt und ich halte ihn auch für eher unwahrscheinlich, da eine solche Übergangslösung für wenige Monate zu viele Ressourcen binden würde. Llano (4 Kerne) wird ohne L3 Cache und mit zusätzlicher IGP an Board (selbst wenn man diese deaktiviert) nicht ausreichen, um einen 6-Kern Thuban mit aktuell bis zu 3,2GHz abzulösen.

puntarenas

2010-07-22, 10:30:27

Es deutet doch sowieso einiges darauf hin, dass AMD das von uns hier im 3DCenter vielfach bevorzugte Segment der "Gamer-CPU" notgedrungen mehr oder minder aufgibt. Llano ist für Bürorechner, Mulltimedia und Omas Internetrechner bei Weitem schnell genug und dabei bestimmt sehr günstig und sparsam. Diese Marktsegmente sind außerdem riesig, da möchte AMD verständlicherweise ein Stück vom Kuchen. Bei Mobilrechnern lautet das Motto sowieso "Vision" und damit eine definierte Mindestperformance, die für verbreitete Anwendungsszenarios reicht.

Aus Bulldozer lassen sich Prozessoren für Serverbetrieb und parallelisierbare Anwendungen allgemein (Rendering, Softwareentwicklung, Transcoding...) schnitzen, aber im Moment scheint er eben vor allen Dingen in die Breite zu gehen, auch wenn einige von einer Single-Thread Leistung (IPC pro Core und Taktraten müssen stimmen) träumen, die Sandy Bridge samt Nachfolger alt aussehen lässt. Das wäre ein Sprung in der "IPC pro Kern" (gibt es dafür eigentlich einen handlicheren Begriff?) von mindestens 50% und das ist schon eine sehr kühne Hoffnung.

Ich denke, AMD hat sich auf zwei wesentliche, vielversprechende Felder konzentriert. Das eine verspricht Masse und das andere ordentliche Margen. Enthusiastische Gamer sitzen dazwischen und fallen ein wenig durch das Raster, auch wenn das natürlich alles spekulativ ist.

"Stop talking about processors...
...Start talking about usage" (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=487633)

robbitop

2010-07-22, 10:31:37

Das würde unglaublich viel Entwicklungsarbeit und eine eigene Maske benötigen. Sowas macht keiner. Nichtmal Intel.

Gast

2010-07-22, 11:14:59

http://www.computerbase.de/news/hardware/prozessoren/intel/2010/juli/sandy_bridge_ces-start_multiplikator/

Weiß Intel vielleicht mehr als wir und geht davon aus, dass die Performance des Bulldozers verdammt nah an die von Sandybridge kommt? Oder weshalb sollte Intel sonst Speicher von 2.133 MHz bis zu DDR3-2666+ unterstützen?

S940

2010-07-22, 11:20:11

Das wäre ein Sprung in der "IPC pro Kern" (gibt es dafür eigentlich einen handlicheren Begriff?) von mindestens 50% und das ist schon eine sehr kühne Hoffnung.
Äh wie meinst Du das ? Dass ein K10 bei gleichem Takt 50% langsamer als ein Nehalem ist ?
Das wäre wirklich eine kühne Behauptung :freak:

Enthusiastische Gamer sitzen dazwischen und fallen ein wenig durch das Raster, auch wenn das natürlich alles spekulativ istNa die Gamer können sich bei 2 oder 4 Threads über den Turbo Mode freuen.

IVN

2010-07-22, 11:23:46

Äh wie meinst Du das ? Dass ein K10 bei gleichem Takt 50% langsamer als ein Nehalem ist ?
Das wäre wirklich eine kühne Behauptung :freak:
Ne, ein Nehalem ist pro Takt 50% schneller bzw der PII ist pro Takt 33% langsamer.

Undertaker

2010-07-22, 11:27:43

puntarenas sprach von Sandy Bridge, nicht Nehalem.

puntarenas

2010-07-22, 11:34:48

Äh wie meinst Du das ? Dass ein K10 bei gleichem Takt 50% langsamer als ein Nehalem ist ?
Das wäre wirklich eine kühne Behauptung :freak:
Nein, da war nochmal Spekulation drin, dass Sandy (und ggf. deren Nachfolger, je nach Launchzeitpunkt) auch nochmal ein wenig zulegen. Nehmen wir halt von mir aus nur 30-40% an, die Zambezi in der Single-Thread-Leistung zulegen müsste, um zu Intel aufzuschließen. So genau kann man das über den Daumen sowieso nicht sagen, weil es auch hier von Anwendung zu Anwendung variiert. Auf jeden Fall finde ich Spekulationen, dass die "IPC pro Kern" (ich suche immer noch nach einem griffigen Begriff) zu Sandy aufschließen wird, ausgesprochen optimistisch und welche Taktraten sich von Beginn an erreichen lassen wissen wir auch noch nicht.

Na die Gamer können sich bei 2 oder 4 Threads über den Turbo Mode freuen.
Schön und gut, aber AMD operiert nicht im luftleeren Raum und muss sich immer dem Quervergleich zu Intel stellen.

S940

2010-07-22, 16:39:38

Hmm, also von welchen Programmen reden wir da .. im Mittel sind bei den ganzen PCGH Gametests doch nur so 20-25%.
Möglich, dass es bei SSE4.1 / AES Benches / Encodingtests mehr ist, aber das sollte man eher außen vor lassen, da das eher die Ausnahme ist. Wenn mans unbedingt in der Kalkulation drin haben möchte, dann kann man davon ausgehen, dass BD das aufholt, da ja die ganzen Intel ISA Erweiterungen erstmals auch mit dabei sind.

Ok, sagen wir mal Sandy bekommt 5-10% bessere IPC als Nehalem, dann kommen ich auf 30-35%, über die 5% Unterschied zu Dir will ich da dann mal nicht streiten.

Auf jeden Fall finde ich Spekulationen, dass die "IPC pro Kern" (ich suche immer noch nach einem griffigen Begriff) zu Sandy aufschließen wird, ausgesprochen optimistisch und welche Taktraten sich von Beginn an erreichen lassen wissen wir auch noch nicht.
Hmm tja ... BD ist eine komplett neue Architektur, mit den üblichen Kniffs mit denen Intel die Core2 Leistung steigerte:

MacroOp Fusion (bestätigt)
Trace Cache (unbestätigt)
4issue pipelines (bestätigt).

Der getrennte INT / FP Unit Ansatz ist dazu flexibler als Intels FP/INT Mischbetrieb. Intel hat nur 3 Ports für alle INT/FP Oops, AMD hat pro Modul 8 exklusive für INT und 4 exklusive für FP. Ein einzelner Thread kann max. 4+4 nutzen, wenn der 2te Cluster schläft. So sie keine Bremsen im Front-End eingebaut haben, ist das Ganze von der Sorte Klotzen nicht Kleckern.

Der 128bit SSE Durchsatz sollte z.B. doppelt so hoch sein wie bei Intel. "Sollte", weill man nicht sicher gehen kann, ob Intel nicht doch nen Kniff gefunden hat, auch zwei 128bit Ops pro Takt durch die Pipeline zu schleußen, obwohl die Ports nicht mehr wurden. Immerhin war der cinebench Wert im chin. Forum nicht übel, SSE sollte also schneller sein, aber vielleicht war das "nur" aufgrund der besseren Speicherperformance. Muss man halt noch abwarten.

Noch weitere Fragen:
a) Für was suchst Du nen Begriff ? IPC ist immer per Kern, zumindest hab ichs noch nicht anders gesehen. Wenn dann bräucht man ne neue Kenngröße für Multicorerechenleistung. Aber da ist mittlerweile ja SpecRATE und cinebench gebräuchlich.

b) Taktraten:
Sehe ich als kleineres Problem. Erstens ist das Deisgn nagelneu, also wenn das nicht auf hohe Taktraten ausgelegt ist, weiss ich auch nicht, und zweitens schließt AMD bei 32nm endlich wieder zu Intel auf, da sie dann auch high-k Interconnects verwenden. Das war mMn Intels Hauptvorteil. Dazu kommt dann noch SOI und ULK als Exklusivmerkmal, damit hat AMD unterm Strich nen Fertigungsvorteil, der sich sicher nicht negativ auf den Taktspielraum auswirken wird.

Einziges Fragezeichen ist, ob GF den Prozess rechtzeitig hinbekommt ... das verschiebt sich ja im Moment. Hoffen wir, dass sie es bis zum geplanten Massenprod. Start von Bulldozer im Griff haben.

Alles in Allem sehe ich keinen "äußersten" Optimismus. Optimismus ja, aber nicht "äußerst", dazu sind die Eckdaten schon zu klar. BD wird komplett neu, da muss man aufholen und die Indizien dazu sind schon bekannt, Sandy Bridge wird dagegen nur ein Nehalem Aufguss mit doppelt getakteter FPU und 256bit Zugriffen.

Kurz:
Wenn Sandy ein "Tock" ist, dann ist BD ein Tock² plus Tick in einem. Da kann / muss man große Sprünge erwarten.
Problematisch ist nur die Frage, ob sies (GF) gebacken bekommen :freak:

Meine Progose: Ich rechne mit Nehalem IPC und Anschluß zu Sandy durch etwas höherem Takt. In Sonderfällen, d.h. Neucompilaten mit AMDs Compiler und unter Ausnutzung der FMA(C) Befehle, die Sandy noch nicht hat, wirds dagegen einen (deutlichen) Vorteil pro AMD gegeben. Aber ausser bei Spec wird das sicher nirgendwo ein Thema sein, also die Ausnahme bleiben.

ciao

Alex

Coda

2010-07-22, 16:41:47

Die Core-Architektur hat keinen Trace-Cache.

Ein einzelner Thread kann max. 4+4 nutzen, wenn der 2te Cluster schläft.
Sehr unwahrscheinlich. Würde auch keinen Sinn ergeben, denn vier Ports sind bereits schwierig auszulasten. Das gibt die Decode-Bandwidth gar nicht her.

Übrigens kannst du die Ports so auch nicht vergleichen, denn bei Bulldozer müssen diese wohl Adress-Operationen mitmachen.

S940

2010-07-22, 16:45:51

Die Core-Architektur hat keinen Trace-Cache.
Gute Güte, dann nenn das Ding Loop Detector wie das Intel Marketing, bleibt sich gleich, immer diese Kleinigkeiten.
Sehr unwahrscheinlich.
Ich hab nur das Maximum angegeben, ich hab nicht gesagt, dass es andauernd und immer der Fall sein wird ;-)

Edit:
Übrigens kannst du die Ports so auch nicht vergleichen, denn bei Bulldozer müssen diese wohl Adress-Operationen mitmachen.

Ist noch nicht raus. Für die Annahme sprechen 1-2 Patete in Dresdenboys Portfolio, dagegen die letzten Compiler Optimierungen, da wird explizit von 4 ALUs+3 AGU OPs geredet. Wenn das nun nur auf 4 gemischte ALU/AGU Pipelines abgebildet werden würde, dann sollte man das etwas besser im Compiler behandeln. Aber gut - der Compiler ist noch nicht fertig, vielleicht kommts ja noch.
Warten wirs ab. In einem Monat sind wir hoffentlich schlauer :)

ciao

Alex

Coda

2010-07-22, 16:48:37

Gute Güte, dann nenn das Ding Loop Detector wie das Intel Marketing, bleibt sich gleich, immer diese Kleinigkeiten.
Der Loop-Decoder ist ganz bestimmt kein Trace-Cache. Woher nimmst du denn diese absurde These her?

Ich hab nur das Maximum angegeben, ich hab nicht gesagt, dass es andauernd und immer der Fall sein wird ;-)
Ich verwette sonstwas darauf, dass die andere Pipeline nicht die Integer-Resourcen der anderen verwenden kann. Um es klar zu machen. Das wäre schon von den Signalwegen totaler Irrsinn.

Ist noch nicht raus. Für die Annahme sprechen 1-2 Patete in Dresdenboys Portfolio, dagegen die letzten Compiler Optimierungen, da wird explizit von 4 ALUs+3 AGU OPs geredet.
Das kannst du auch getrost vergessen. Das lässt sich aus skalarem Code einfach nicht rausquetschen.

Übrigens halte ich auch das mit der "komplett neuen Architektur" für Blödsinn. K10 hat auch schon einen getrennten Scheduler für die FPU und die ALUs und AGUs sind im Gegensatz zu den Intel an Ports zusammengefasst. So weit weg davon ist das was bisher angedacht wird auch nicht.

Viel wichtiger als die Ausführungsresourcen ist in einer modernen CPU eh das Speichermanagement. Cache-Misses sind weitaus teurer als fehlende Rechenleistung. Aus dem Punkt hat Intel seit Conroe def. auch am meisten Leistung rausgequetsch ggü. AMD.

Ich erwarte übrigens auch viel von BD. Aber verabschiedet euch mal von dieser Masse-Machts-Architektur-These. Einfach zusätzliche Ports anflanschen und hoffen das die Performance in die Höhe schießt funktioniert nicht. Das weiß jeder Student der mal Rechnerarchitektur gehört hat.

S940

2010-07-22, 17:14:32

Der Loop-Decoder ist ganz bestimmt kein Trace-Cache. Woher nimmst du denn diese absurde These her?In beiden Fällen werden µOps gespeichert, ich seh da keinen großen Unterschied.
Wenns einen gibt und Dir die Erklärung nichts ausmacht, lerne ich gerne dazu, falls es einen Link gibt ist der ebenfalls gern gesehen.

Ich verwette sonstwas darauf, dass die andere Pipeline nicht die Integer-Resourcen der anderen verwenden kann. Um es klar zu machen. Das wäre schon von den Signalwegen totaler Irrsinn.
Öh welche "andere Pipeline "? 4+4 bezieht sich auf einen INT Cluster mit 4 Pipelines und der kompletten FPU, die im single thread Fall nicht geteilt werden muss. Von reversed Hyperthreading o.ä. hab ich nicht gesprochen.

Das kannst du auch getrost vergessen. Das lässt sich aus skalarem Code einfach nicht rausquetschen.Naja ... für die FMA4 OPs könnte es doch was bringen, oder nicht ?

Übrigens halte ich auch das mit der "komplett neuen Architektur" für Blödsinn. K10 hat auch schon einen getrennten Scheduler für die FPU und die ALUs und AGUs sind im Gegensatz zu den Intel an Ports zusammengefasst. So weit weg davon ist das was bisher angedacht wird auch nicht.
Na komm "Blödsinn" ist jetzt zuviel Polemik. Natürlich wird das Rad nicht neu erfunden, der Chip besteht nachwievor aus bewährten Transistoren, die es seit den ~1950er gibt, und es werden auch weiterhin Binärzahlen verwendet. Wenn Du Dich auf den Standpunkt begeben willst ok. Aber wenn das nun "Blödsinn" ist, was ist dann Sandy Bridge ? Laut intel ist das (ebenfalls) ne neue Architektur, ein ganz entscheidenter, riesiger "Tock" Schritt ...
In Relation dazu ist BD wirklich "komplett" neu ;-) So wars gemeint.
Viel wichtiger als die Ausführungsresourcen ist in einer modernen CPU eh das Speichermanagement. Cache-Misses sind weitaus teurer als fehlende Rechenleistung. Aus dem Punkt hat Intel seit Conroe def. auch am meisten Leistung rausgequetsch ggü. AMD.Hmm, was meinst Du da genau ? Den IMC im Nehalem, oder den low-latency L2 ?
Ich erwarte übrigens auch viel von BD. Aber verabschiedet euch mal von dieser Masse-Machts-Architektur-These. Einfach zusätzliche Ports anflanschen und hoffen das die Performance in die Höhe schießt funktioniert nicht. Das weiß jeder Student der mal Rechnerarchitektur gehört hat.
Lol, ja, deswegen schrieb ich ja, dass das Front-end auch Schritt halten muss. Und selbst da wäre man dann mit einer IPC von ~1,5-2 fantastisch gut bedient. Aber ich hab das nur so optimistisch geschrieben, um zu zeigen, dass da einiges passiert, und die Annahme, dass BD also zur Intel IPC aufschließen kann, somit nicht überoptimistisch ist, bzw. im Bereich der Fantasten und Fanboys liegt.

ciao

Alex

Coda

2010-07-22, 17:19:29

In beiden Fällen werden µOps gespeichert, ich seh da keinen großen Unterschied.
Es ist ein riesen Unterschied. Ein Trace-Cache speichert ganze Code-Traces (mehrere tausend Micro-Ops), der Loop-Decoder nur ein paar wenige die zusammen eine kleine Schleife bilden. Der Loop-Decoder sitzt auch mitten in der Pipeline und nicht am Anfang.

Öh welche "andere Pipeline "? 4+4 bezieht sich auf einen INT Cluster mit 4 Pipelines und der kompletten FPU, die im single thread Fall nicht geteilt werden muss. Von reversed Hyperthreading o.ä. hab ich nicht gesprochen.
Dann ist ja gut

Naja ... für die FMA4 OPs könnte es doch was bringen, oder nicht ?
FMA wird nur von der FPU verwendet.

Na komm "Blödsinn" ist jetzt zuviel Polemik. Natürlich wird das Rad nicht neu erfunden, der Chip besteht nachwievor aus bewährten Transistoren, die es seit den ~1950er gibt, und es werden auch weiterhin Binärzahlen verwendet. Wenn Du Dich auf den Standpunkt begeben willst ok. Aber wenn das nun "Blödsinn" ist, was ist dann Sandy Bridge ? Laut intel ist das (ebenfalls) ne neue Architektur, ein ganz entscheidenter, riesiger "Tock" Schritt ...
Ist auch nur Marketing. Nehalem zeigt bei speziellen Instruction-Sequenzen immer noch exakt die gleichen Macken wie ein Pentium Pro. Da verschluckt sich dann die Pipeline für eine bestimmte Anzahl an Ticks. Natürlich reiner Zufall ;)

Hmm, was meinst Du da genau ? Den IMC im Nehalem, oder den low-latency L2 ?
Keins von beidem. Ich reden vom intelligenten Prefetching. Core 2 hat effektiv eine niedrigere Speicherlatenz als ein K10 - und das trotz FSB.

Das dürfte der wichtigste Punkt sein mit dem Intel bei Conroe diesen riesigen Performancesprung gemacht hat, nicht so sehr die Verbesserungen an den Ausführungsresourcen.

BlackBirdSR

2010-07-22, 17:37:03

Beim Thema Trace Cache bin auch ganz fest der Meinung von Coda.

S940

2010-07-22, 18:18:53

Es ist ein riesen Unterschied. Ein Trace-Cache speichert ganze Code-Traces (mehrere tausend Micro-Ops), der Loop-Decoder nur ein paar wenige die zusammen eine kleine Schleife bilden. Der Loop-Decoder sitzt auch mitten in der Pipeline und nicht am Anfang.
Ok, dass v.a. die Größe ein Unterschied ist, hab ich auch schon mitbekommen.

Nur kommt jetzt dann die Preisfrage. Angeblich wird der Loop Detector bei Sandy jetzt aufgebohrt auf einige 100 vielleicht auch 1000 µOps. Kann man das dann ein Trace Cache nennen, obwohl es in der Mitte der Pipeline liegt ?

FMA wird nur von der FPU verwendet.
Ok.

Ist auch nur Marketing. Nehalem zeigt bei speziellen Instruction-Sequenzen immer noch exakt die gleichen Macken wie ein Pentium Pro. Da verschluckt sich dann die Pipeline für eine bestimmte Anzahl an Ticks. Natürlich reiner Zufall ;)Auch ok :)

Keins von beidem. Ich reden vom intelligenten Prefetching. Core 2 hat effektiv eine niedrigere Speicherlatenz als ein K10 - und das trotz FSB.
Das dürfte der wichtigste Punkt sein mit dem Intel bei Conroe diesen riesigen Performancesprung gemacht hat, nicht so sehr die Verbesserungen an den Ausführungsresourcen.Ah die Prefetcher, ja die waren damals wirklich gut, stimme ich zu. Aber soviel ich mitbekommen habe, ist AMD da seit K10 auch wieder auf Augenhöhe, oder nicht ?

Was mir gerade noch einfällt ist: Da gabs bei Core2 doch auch noch was, das "memory disambiguation" hieß, beschrieben u.a. hier:
http://techreport.com/articles.x/10351/2

Als wie wichtig siehst Du das ? Hab ich bei AMD glaube ich - noch nicht gehört.

ciao

Alex

Coda

2010-07-22, 18:21:40

Ok, dass v.a. die Größe ein Unterschied ist, hab ich auch schon mitbekommen.
Nein, da ist nicht nur "vor allem die Größe" der Unterschied.

Nur kommt jetzt dann die Preisfrage. Angeblich wird der Loop Detector bei Sandy jetzt aufgebohrt auf einige 100 vielleicht auch 1000 µOps. Kann man das dann ein Trace Cache nennen, obwohl es in der Mitte der Pipeline liegt ?
Nein. Ein Loop-Decoder speicher immer nur aktuelle Befehle, ein Trace-Cache ist wie sein Name sagt ein Cache, der auch derzeit nicht gebrauchte Traces verwaltet. Das ist weitaus aufwendiger.

Ah die Prefetcher, ja die waren damals wirklich gut, stimme ich zu. Aber soviel ich mitbekommen habe, ist AMD da seit K10 auch wieder auf Augenhöhe, oder nicht ?
Bei weitem nicht, sonst würden sie nicht in speicherintensiven Sachen regelmäßig so abkacken. Die reine Rechenleistung von K10 ist nämlich gar nicht viel geringer als die von Nehalem, wenn man ihm entsprechenden Code mit schön sequenziell ablaufenden Speicherzugriffen gibt.

Ich geh davon aus, dass Intel seit Core 2 so etwas wie "Memory Access Prediction" einsetzt.

S940

2010-07-22, 18:45:27

Nein, da ist nicht nur "vor allem die Größe" der Unterschied.

Nein. Ein Loop-Decoder speicher immer nur aktuelle Befehle, ein Trace-Cache ist wie sein Name sagt ein Cache, der auch derzeit nicht gebrauchte Traces verwaltet. Das ist weitaus aufwendiger.
Ok, aber wenn Sandys "Loop Detector" jetzt größer wird, dann kann man davon ausgehen, dass da nicht nur aktuelle Befehle drin landen, da ja riesig viel Platz ist. Falls dem so wäre, dann wäre das also quasi die Mutation vom LSD zu Trace Cache ?
Falls ja, macht die mittige Position noch was aus ?

Auf alle Fälle schon vielen Dank für die bisherige Erklärung :)

Bei weitem nicht, sonst würden sie nicht in speicherintensiven Sachen regelmäßig so abkacken. Die reine Rechenleistung von K10 ist nämlich gar nicht viel geringer als die von Nehalem, wenn man ihm entsprechenden Code mit schön sequenziell ablaufenden Speicherzugriffen gibt.HMm also Stream und SpecFP laufen doch seit den Snoop Filtern ganz ordentlich, meinst Du was anderes ?
Ich geh davon aus, dass Intel seit Core 2 so etwas wie "Memory Access Prediction" einsetzt.Ah ok, na dann schauen wir mal, was AMD im BD bastelt, ob sie ähnliches bringen. Da geistert ja ab und an schon transactional Memory in der Gerüchte Küche herum, aber naja bei BD 1.0 wohl noch nicht.

ciao

Alex

P.S: Loop (stream) Detector, nicht Decoder ;-)

Coda

2010-07-22, 18:45:58

Ok, aber wenn Sandys "Loop Detector" jetzt größer wird, dann kann man davon ausgehen, dass da nicht nur aktuelle Befehle drin landen, da ja riesig viel Platz ist.
Kann man nicht, sonst ist es kein Loop-Stream-Detector mehr.

Wie der Name schon sagt kümmert er sich um den aktuellen Loop. Dass man diesen dann auch nicht sinnlos groß macht sollte klar sein. Inner-Loops bestehen in der Regel nicht aus sehr vielen Ops.

HMm also Stream und SpecFP laufen doch seit den Snoop Filtern ganz ordentlich, meinst Du was anderes ?
Du bringst schon wieder alles durcheinander. Der Snoop-Filter ist dazu da den Hypertransport-Traffic um die Cache-Kohärenz zu gewährleisten zu minimieren. Das hat direkt nichts mit Speicherzugriffen zu tun.

Ah ok, na dann schauen wir mal, was AMD im BD bastelt, ob sie ähnliches bringen.
Wenn nicht floppt das Ding massiv. Das ist praktisch gesichert.

S940

2010-07-22, 19:37:16

Du bringst schon wieder alles durcheinander. Der Snoop-Filter ist dazu da den Hypertransport-Traffic um die Cache-Kohärenz zu gewährleisten zu minimieren. Das hat direkt nichts mit Speicherzugriffen zu tun.
Ja eben, und dieser unsinnige Kohärenz Traffic kostet Bandbreite, die dadurch nicht mehr sinnvoll genutzt werden kann.
Hast Du die Stream Werte mit/ohne Filter nicht gesehen ?

Da besteht meiner Meinung schon ein Zusammenhang, wenn auch indirekt.

Am besten ist Du nennst einfach mal das Programm / Sachverhalt, was Du genau meinst, dann ist das eindeutig :)

ciao

Alex

Coda

2010-07-22, 19:54:00

Ja eben, und dieser unsinnige Kohärenz Traffic kostet Bandbreite, die dadurch nicht mehr sinnvoll genutzt werden kann.
Entschuldige, aber das ist trotzdem etwas völlig anderes. Vor allem spielt es auf dem Desktop überhaupt keine Rolle.

BlackBirdSR

2010-07-22, 20:23:07

Ok, aber wenn Sandys "Loop Detector" jetzt größer wird, dann kann man davon ausgehen, dass da nicht nur aktuelle Befehle drin landen, da ja riesig viel Platz ist. Falls dem so wäre, dann wäre das also quasi die Mutation vom LSD zu Trace Cache ?
Falls ja, macht die mittige Position noch was aus ?

Sorry aber da kannst Du noch so lange rumreiten darauf,
der Trace-Cache ist ein vorgelagerter Speicher und Logik-Bereich, dessen Funktion den L1-I-Cache vollkommen ersetzen kann. Gespeichert werden zudem nicht einfch nur µOps, sondern ganze Traces (also spezifische Befehlsfolgen) von Threads.

Wenn Du unbedingt willst: Der Loop-Detector hat bestimmt auch einige Puffer, also ist das sicher auch eine Art von Speicher, wie der Trace-Cache, der L1-Cache, der L2-Cache die Festplatte und mein Diskettenlaufwerk ;)

S940

2010-07-23, 00:49:28

Entschuldige, aber das ist trotzdem etwas völlig anderes. Vor allem spielt es auf dem Desktop überhaupt keine Rolle.Lol, ja sag doch einfach was Du meinst und lass mich nicht rumraten, ich komm mir ja langsam vor wie bei ner Quizzshow.

Du hattest geschrieben:
Bei weitem nicht, sonst würden sie nicht in speicherintensiven Sachen regelmäßig so abkacken. Die reine Rechenleistung von K10 ist nämlich gar nicht viel geringer als die von Nehalem, wenn man ihm entsprechenden Code mit schön sequenziell ablaufenden Speicherzugriffen gibt.
Und bei speicherintensiven Anwendungen fiel mir nunmal Stream und SpecRate ein, die sind nachweislich speicherintensiv und wurden durch den Snoop Filter schneller.

Wenn Du was jetzt andres meinst, dann sags doch einfach, ich würde gerne Gedanken lesen, aber kann es nunmal leider nicht :(
Oder soll ich das Publikum fragen ? ;-)

@BlackBirdSR:
Ich will hier nicht irgendwen reiten, mir gehts nur um die Begriffsdefinition bzw. den Unterschied zw. Trace Cache und LSD. So wie ich das sehe wisst ihr außer einem "das ist nicht das Gleiche, Basta" auch nichts Genaueres.

Grund für meine Neugierde:
One of the most interesting things to note about Nehalem is that the LSD is conceptually very similar to a trace cache. The goal of the trace cache was to store decoded uops in dynamic program order, instead of the static compiler ordered x86 instructions stored in the instruction cache, thereby removing the decoder and branch predictor from the critical path and enabling multiple basic blocks to be fetched at once. The problem with the trace cache in the P4 was that it was extremely fragile; when the trace cache missed, it would decode instructions one by one. The hit rate for a normal instruction cache is well above 90%. The trace cache hit rate was extraordinarily low by those standards, rarely exceeding 80% and easily getting as low as 50-60%. In other words, 40-50% of the time, the P4 was behaving exactly like a single issue microprocessor, rather than taking full advantage of it's execution resources. The LSD buffer achieves almost all the same goals as a trace cache, and when it doesn’t work (i.e. the loop is too big) there are no extremely painful downsides as there were with the P4's trace cache. http://www.realworldtech.com/page.cfm?ArticleID=RWT040208182719&p=5

Aufgrund obigen Artikels sehe ich keinen großen Unterschied. Wenn jetzt jemand was anderes behauptet, dann hätte ich deshalb gerne ne Erklärung. Frage ist hier im Forum ja hoffentlich noch erlaubt.

Wenns nur die Pipeline-Position und/oder Größe ist, ändert sich vom Konzept her nicht viel, von daher versteh ich nicht, wieso Du/Ihr darauf "rumreitet", dass das was komplett ganz Anderes sei.

ciao

Alex

Coda

2010-07-23, 01:27:27

Das Problem ist, dass man einen Aufsatz von meheren Seiten schreiben müsste um den Unterschied wirklich klar zu machen. Das ganze ist nämlich nicht gerade ein triviales Thema. Ich hoffe du verstehst, dass ich dazu nicht unbedingt große Lust habe.

Die Erklärung, dass ein LSD nur die aktuelle Schleife cacht, und ein Trace-Cache Micro-Op-Traces des ganzen Programms muss dir reichen. Der Komplexitätsunterschied ist enorm. Gegenbeispiel für die These "LSD und Trace-Cache sind das gleiche": Ein LSD kann nur Micro-Ops von der Schleife cachen in der sich der Programmzeiger derzeit befindet, der Trace-Cache von jeglichem Code, der in letzter Zeit verwendet wurden. Q.e.d.

Was RWT dort schreibt ist sehr irreführend. Ich bezweifel auch die angegebenen Hit-Rates was den P4 angeht. Die meiste Zeit von Programmen wird in Inner-Loops verbracht und die dürften praktisch immer getroffen werden. Da fehlt auch explizit eine Quelle für diese Zahlen. Sieht nicht gerade nach vollstem Verständnis der Gegebenheiten aus.

Und bei speicherintensiven Anwendungen fiel mir nunmal Stream und SpecRate ein, die sind nachweislich speicherintensiv und wurden durch den Snoop Filter schneller.
Nein, ich meine Algorithmen, die sehr undurchschaubare Zugriffsmuster liefern. Da drehen die Intel-Chips Kreise um AMD. Mit Bandbreite hat das nichts zu tun, die kann eh nur ausgenutzt werden, wenn dies eben nicht der Fall ist.

john carmack

2010-07-23, 08:43:48

Kann mir jemand sagen welche CPU zumindest (auch wenn es nicht der Realität entspricht) auf dem Papier besser aussieht?

Gast

2010-07-23, 09:33:37

Llano (4 Kerne) wird ohne L3 Cache und mit zusätzlicher IGP an Board (selbst wenn man diese deaktiviert) nicht ausreichen, um einen 6-Kern Thuban mit aktuell bis zu 3,2GHz abzulösen.

Das ist nicht bloß eine IPG, das sind Stream-Co-Prozessoren, diese wird man mit sicherheit nicht deaktivieren. Höchstens den 2D-Teil für High-End.

puntarenas

2010-07-23, 11:38:23

Hmm, also von welchen Programmen reden wir da .. im Mittel sind bei den ganzen PCGH Gametests doch nur so 20-25%.

PCGH sucht aber ausdrücklich nicht nach Worst-Case-Szenarien. Auch wenn die Benchmarks dort sehr gewissenhaft erfolgen, ein wenig sind die Prozessorbalken vermutlich doch einmal hier und da glattgebügelt. Ist aber geschenkt, zumindest von meiner Seite, denn das sind sowieso nur grobe Durchschittswerte und ich würde halt am Launchtag nur gern sehen, dass die IPC und das Taktpotential von Zambesi auf Augenhöhe mit Sandy liegt. Ich halte das für ambitioniert, du hälst das für durchaus wahrscheinlich, kein Problem.

Noch weitere Fragen:
a) Für was suchst Du nen Begriff ? IPC ist immer per Kern, zumindest hab ichs noch nicht anders gesehen. Wenn dann bräucht man ne neue Kenngröße für Multicorerechenleistung. Aber da ist mittlerweile ja SpecRATE und cinebench gebräuchlich.

In Ordnung und vielen Dank! Ich werde zukünftig auf Rumgeeier verzichten und von IPC reden (im Sinne von taktbereinigter Leistungsfähigkeit eines einzelnen Kerns der betreffenden Architektur), wenn irgendein Nitpicker dann ums Eck kommt verweise ich ihn höflich aber bestimmt an dich. :tongue::smile:

Da du die Entwicklung und Gerüchteküche offenbar sehr intensiv verfolgst noch eine kleine Frage, auf die Gefahr hin dass es in den Untiefen des Threads schon einmal aufgekommen ist. Gibt es schon Spekulationen zu den Stromsparmechanismen der Bulldozer-Prozessoren? Wird es einen C6-State geben?

BlackBirdSR

2010-07-23, 12:29:49

Aufgrund obigen Artikels sehe ich keinen großen Unterschied. Wenn jetzt jemand was anderes behauptet, dann hätte ich deshalb gerne ne Erklärung. Frage ist hier im Forum ja hoffentlich noch erlaubt.

Wenns nur die Pipeline-Position und/oder Größe ist, ändert sich vom Konzept her nicht viel, von daher versteh ich nicht, wieso Du/Ihr darauf "rumreitet", dass das was komplett ganz Anderes sei.

ciao

Alex

Nur weil etwas konzeptiell ähnlich ist, muss es nicht heißen, dass es keinen großen Unterschied gibt. Das mit dem großen Unterschied sind deine Worte, und daran stören wir uns.
Ja der L1-Cache und der L3-Cache sind konzeptiell sehr ähnlich, aber es sind im Detail eben ganz andere Dinge.

Wenn etwas an einer anderen Stelle oder gar vor der Pipeline sitzt, ändert sich extrem viel daran, vor allem für den Rest der CPU. Der Loop-Detector hat nahezu keine Auswirkungen auf die ALUs z.B., während bei P4 ganze Blocks speziell auf den Trace-Cache hin getrimmt werden mussten.

AnarchX

2010-07-23, 15:25:15

Diskussion zu Undertakers Benchmark: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=487928

S940

2010-07-23, 17:15:20

Das Problem ist, dass man einen Aufsatz von meheren Seiten schreiben müsste um den Unterschied wirklich klar zu machen. Das ganze ist nämlich nicht gerade ein triviales Thema. Ich hoffe du verstehst, dass ich dazu nicht unbedingt große Lust habe.
Hehe, klar aber da Du Dich meistens immer recht gut auskennst, wollte ichs mal versuchen Dir eine Antwort zu entlocken. lerne immer gerne dazu und v.a. bei solchen Details ist Fachwissen in den Foren sonst sehr, sehr dünn :)

Die Erklärung, dass ein LSD nur die aktuelle Schleife cacht, und ein Trace-Cache Micro-Op-Traces des ganzen Programms muss dir reichen. Der Komplexitätsunterschied ist enorm. Gegenbeispiel für die These "LSD und Trace-Cache sind das gleiche": Ein LSD kann nur Micro-Ops von der Schleife cachen in der sich der Programmzeiger derzeit befindet, der Trace-Cache von jeglichem Code, der in letzter Zeit verwendet wurden. Q.e.d.Ok, Unterschied ist dann klar. Wäre noch nett, wenn Du kurz Deine Meinung über einen großen LSD geben könntest. Wäre es eventuell möglich, dass der dann auch ganze Traces speichert ? Oder wird das wirklich nur ein sehr, sehr großer Schleifen Cache ? Frage mich halt im Moment, was Intel durch das starke vergrößern des LSD bezwecken will, für kleine Schleifen reichts jetzt doch auch schon, oder ?

Was RWT dort schreibt ist sehr irreführend. Ich bezweifel auch die angegebenen Hit-Rates was den P4 angeht. Die meiste Zeit von Programmen wird in Inner-Loops verbracht und die dürften praktisch immer getroffen werden. Da fehlt auch explizit eine Quelle für diese Zahlen. Sieht nicht gerade nach vollstem Verständnis der Gegebenheiten aus.Hmm ok, bilde mir ein, dass auch an anderer Stelle einmal etwas zum schlechten P4 Trace Cache stand, aber kann mich irren, eventuell war es nur ein anderer RWT Artikel ;-)

Nein, ich meine Algorithmen, die sehr undurchschaubare Zugriffsmuster liefern. Da drehen die Intel-Chips Kreise um AMD. Mit Bandbreite hat das nichts zu tun, die kann eh nur ausgenutzt werden, wenn dies eben nicht der Fall ist.Na also, jetzt ist dann klar was gemeint ist, sags das doch gleich, so verstehen wir uns. Danke :)

In Ordnung und vielen Dank! Ich werde zukünftig auf Rumgeeier verzichten und von IPC reden (im Sinne von taktbereinigter Leistungsfähigkeit eines einzelnen Kerns der betreffenden Architektur), wenn irgendein Nitpicker dann ums Eck kommt verweise ich ihn höflich aber bestimmt an dich.
Lol, mach das, oder frag Ihn einfach selbst, wo er zuvor eine "multicore IPC" gesehen hat ^^
IPC ist eh ne sehr schwammige Aussage, da es vom Programmmix abhängt. Siehe aktuell Undertakers JAVA Progrämmchen ... Faktor 3 Unterschied, in dem Fall ist die Intel IPC "etwas" besser.
Da du die Entwicklung und Gerüchteküche offenbar sehr intensiv verfolgst noch eine kleine Frage, auf die Gefahr hin dass es in den Untiefen des Threads schon einmal aufgekommen ist. Gibt es schon Spekulationen zu den Stromsparmechanismen der Bulldozer-Prozessoren? Wird es einen C6-State geben?Das ist noch zu speziell. Da gibts noch keine Infos. Das einzige was man weiss, ist, dass es einen Turbo Mode geben wird. Da braucht es also schlafende Kerne bzw. Kerne im untersten P State. Aber das wars dann.

Nur weil etwas konzeptiell ähnlich ist, muss es nicht heißen, dass es keinen großen Unterschied gibt. Das mit dem großen Unterschied sind deine Worte, und daran stören wir uns.
Ja der L1-Cache und der L3-Cache sind konzeptiell sehr ähnlich, aber es sind im Detail eben ganz andere Dinge.
Ok verstanden, damit ist das Mißverständnis jetzt geklärt.
Ich würde aber auch schreiben, dass L1/L3 keinen "großen" Unterschied aufweisen. Konzept = gleich, Unterschied nur im Einsatzgebiet.
Aber mit "konzeptionell ähnlich" kann ich sehr gut leben, werde ich in Zukunft dann verwenden, Danke :)

Wenn etwas an einer anderen Stelle oder gar vor der Pipeline sitzt, ändert sich extrem viel daran, vor allem für den Rest der CPU. Der Loop-Detector hat nahezu keine Auswirkungen auf die ALUs z.B., während bei P4 ganze Blocks speziell auf den Trace-Cache hin getrimmt werden mussten.Dumme Frage (mal wieder): Würde es Sinn machen in einer CPU Trace Cache und LSD einzubauen ? Quasi Trace Cache für die großen Blöcke und LSD für die Loops ? Oder reichte ein Trace Cache, um alle Fälle abzudecken ?

Danke für alle Antworten & Erklärungen

Alex

Dresdenboy

2010-08-01, 00:55:54

Halte ich für unwahrscheinlich. Man entwickelt ein Design für ein vorher definierten Prozess. Das Design für einen Vorgängerprozess zu adaptieren, um ein paar Pre-Samples zu haben, wäre viel zu aufwändig.
Wenn es Pre-Samples gab, dann waren sie im Zielprozess.
Ich halte das für möglich. Vom K8 gab es 180nm SOI Samples, von denen ich mich mit eigenen Augen überzeugen konnte. Es ist auch ein Unterschied, ob man ein Design, welches mal für 45nm gedacht war, noch für diesen Prozess zu Testzwecken wegen des Zeitgewinns fertigstellt. Das ist eine andere Hausnummer als alle Tests und Validierungsmaßnahmen für die Produktion sowie die Produktionsvorbereitungen durchzuführen. Die Verschiebung wurde schließlich erst (was ich finden konnte) im März 2009 bekannt. Ende des Jahres hätte der 45nm BD kommen sollen. Womit wir auch den Punkt, ein Design für einen vorher definierten Prozess zu entwickeln, erfüllt hätten.

HOT

2010-08-01, 10:28:59

Kann man nicht, sonst ist es kein Loop-Stream-Detector mehr.

Wie der Name schon sagt kümmert er sich um den aktuellen Loop. Dass man diesen dann auch nicht sinnlos groß macht sollte klar sein. Inner-Loops bestehen in der Regel nicht aus sehr vielen Ops.
[...]
Bei 10000µOps machts dann doch keinen Sinn mehr zu beschränken oder? Also doch Trace-Cache? Hat sich ja bewährt die Technik. Der BD wird wohl auch einen bekommen.

BlackBirdSR

2010-08-01, 11:38:46

Ok verstanden, damit ist das Mißverständnis jetzt geklärt.
Ich würde aber auch schreiben, dass L1/L3 keinen "großen" Unterschied aufweisen. Konzept = gleich, Unterschied nur im Einsatzgebiet.
Aber mit "konzeptionell ähnlich" kann ich sehr gut leben, werde ich in Zukunft dann verwenden, Danke :)

Das Konzept ist nicht gleich. Es sei denn Du abstrahierst bis zum Umfallen. Etwas, das man lieber den Politikern überlassen sollte.

Nochmal:
Auch ein Hund ist konzeptionell ähnlich zu einem Menschen.
Ein Baum ist das auch.
Selbst ein Virus baut konzeptionell auf die gleichen Mechnismen.
Hier auf biegen und brechen "konzeptionell ähnlich" zu schreiben, halte ich persönlich für einen großen Fehler und würde ich für mich nie akzeptieren.

Wenn Intel Tausend und mehr µOps speichert, dafür noch Logik hinzugibt und ganze "Ausführungsschleifen" speichert, hast Du deinen Trace-Cache. Ansonsten ist es ein µOps-Cache. Konzeptionell ähnlich dahingehend, dass µOps gespeichert werden nach den Decodern. Konzeptionell nicht ähnlich, dahingehend, wie genau verfahren wird.

Also bitte schreib das nicht so, wenn das möglich ist. Hat für mich immer den bitten Beigeschmack, dass man unbedingt ein rotes Auto haben will, und wenn jeder sagt, es wäre weiß, dann hat man eben ein hellrotes.....

Coda

2010-08-01, 15:27:26

Der BD wird wohl auch einen bekommen.
Es ist zwar nicht ausgeschlossen, aber ich habe da starke Zweifel.

Gast

2010-08-01, 16:27:43

Der BD wird wohl auch einen [Trace-Cache] bekommen.

oder auch nicht:

OTOH instead of wider decoders there could also be a trace cache as already speculated. What we'll hear about at Hot Chips depends on what has won the performance/power/leakage contest. E.g. a trace cache could have too much leakage because of it's area, so that in the end refetching and redecoding the predecoded instructions from instruction cache might be more efficient.

Link: http://citavia.blog.de/2010/07/30/gcc-scheduler-code-for-bulldozer-9074571/

Tiamat

2010-08-01, 17:06:03

Wie Coda schon gesagt hat, sind das zwei Paar Stiefel.

Von oben betrachtet ist der Trace-Cache eine Verbesserungsmöglichkeit für die Effizienz (z.b mehrere Sprünge pro Takt oder inteligentere Umsortierung der Instruktionsfolgen) der spekulativen Abarbeitungsschritte von Out-of-Order Prozessoren. Was der Trace-Cache speichert, sind kurz gesagt spekulative Befehlsfolgen.

Der Loop-Stream-Detector schaltet, sofern natürlich festgestellt wird, dass ein Loop stattfindet, den Out-of-Order Kram an dieser Stelle für die Dauer des Loops aus.

Das ist eigentlich der wesentliche Unterschied.

Gruß
Tiamat

Coda

2010-08-01, 17:47:49

Von oben betrachtet ist der Trace-Cache eine Verbesserungsmöglichkeit für die Effizienz (z.b mehrere Sprünge pro Takt oder inteligentere Umsortierung der Instruktionsfolgen) der spekulativen Abarbeitungsschritte von Out-of-Order Prozessoren. Was der Trace-Cache speichert, sind kurz gesagt spekulative Befehlsfolgen.
Soweit ich weiß werden nur bereits ausgeführte Befehle im Trace-Cache gespeichert. Da ist nichts spekulativ.

Der Loop-Stream-Detector schaltet, sofern natürlich festgestellt wird, dass ein Loop stattfindet, den Out-of-Order Kram an dieser Stelle für die Dauer des Loops aus.
Wat? Das tut er natürlich nicht. Nur der Decoder wird nicht mehr benötigt.

Tiamat

2010-08-01, 18:22:19

Hi,

und wer sagt, dass das nicht auch für spekulative Ausführungen benutzt wird ?
Immerhin werden diese Befehlsfolgen nicht automatisch in den Trace-Cache gespeichert, sondern erstmal per Trace Selection zwischengespeichert. Wird der Trace kein zweites Mal benötigt, gelangt er somit nie in den Trace-Cache.

Bei der zweiten Sache muss man zwischen Core2Duo und Nehalem unterscheiden.
Hier ist das gut erklärt.
http://www.anandtech.com/show/2594/4

Coda

2010-08-01, 18:46:15

und wer sagt, dass das nicht auch für spekulative Ausführungen benutzt wird ?
Das Intel-Paper. Beim P4 war es jedenfalls nicht so.

Bei der zweiten Sache muss man zwischen Core2Duo und Nehalem unterscheiden.
Hier ist das gut erklärt.
http://www.anandtech.com/show/2594/4
Und wo steht da irgendwas davon dass Out-Of-Order deaktiviert wird? Das ist totaler Blödsinn, dann würde bei jeder Schleife die Performance ins Bodenlose fallen. Man hat doch nicht riesige Instruction-Windows, viele Ausführungseinheiten und Reorder-Buffer ohne sie zu benutzen.

robbitop

2010-08-01, 18:58:13

Ich halte das für möglich. Vom K8 gab es 180nm SOI Samples, von denen ich mich mit eigenen Augen überzeugen konnte.
Hm - war der K8 damals nicht in 130 nm Bulk als Samples ausgeführt?

Tiamat

2010-08-01, 19:27:40

Das Intel-Paper. Beim P4 war es jedenfalls nicht so.

Ok.

Und wo steht da irgendwas davon dass Out-Of-Order deaktiviert wird? Das ist totaler Blödsinn, dann würde bei jeder Schleife die Performance ins Bodenlose fallen. Man hat doch nicht riesige Instruction-Windows, viele Ausführungseinheiten und Reorder-Buffer ohne sie zu benutzen.

Ja hier meinte ich eigentlich, dass der Loop abgearbeiten werden kann, ohne über den klassichen Weg Sprungvorhersage und Fetch-Phase gehen zu müssen. Da hab ich wohl aus Tauben Kanonen gemacht :D

Gast

2010-08-03, 17:28:07

In seinem neu gestarteten Blog rund um das Thema „Bulldozer“ hat AMD erste Vorhersagen zu der Performance abgeliefert. Demnach soll einer der neuen 16-Kern-Prozessoren für das Server-Segment um bis zu 50 Prozent schneller sein als ein aktuelles Modell mit zwölf Kernen.

So schön diese Zahlen doch auf den ersten Blick klingen, so nüchtern sehen sie bei genauerer Betrachtung aus. Denn sieht man sich den Wert allein an, wurde er bereits durch 33 Prozent mehr Kerne erkauft. Hinzu kommt die Formulierung „bis zu“, die bei Herstellerbenchmarks gern das absolute Maximum darstellt; im Mittel sind es zumeist deutlich weniger. Selbst wenn es im Mittel optimistische Zwei-Drittel dieser besagten „bis zu 50 Prozent“-Steigerung sind, kommt man auf einen Wert von 33 Prozent. Und diese hochgerechnete Leistung wurde eben durch 33 Prozent mehr Kerne erkauft.
Erste Performanceangaben von AMD zu „Bulldozer“ (http://www.computerbase.de/news/hardware/prozessoren/amd/2010/august/erste_performanceangaben_amd_bulldozer/)

Au weia, das wird dann eher keiner CPU für den Heimgebrauch. Damit wischt ja Lynnfield in Spielen schon den Boden auf und Sandy kommt ja auch noch vor Zambezi. :ulol:

Coda

2010-08-03, 17:47:20

Kaffeesatzleserei. Abwarten.

w0mbat

2010-08-03, 20:45:41

@Gast: CB schreibt mal wieder news ohne sich vorher zu informieren. ein 16-core interlagos heißt nur so, der hat nämlich keine 16 kerne sonder 8 BD module.

und ein CMT modul ist weniger als 2 "echte" kerne. klar, mehr als SMT, aber aben deutlich weniger als 2 kerne und braucht laut JF-AMD auch nur 20% mehr die-size.

CB rechnet hier aber 12 "echte" kerne vs. 16 "echte" kerne anstatt vs. 8 CMT kerne.

man sollte eben wissen, dass ein "16-core interlagos" ein 8-core CMT BD ist.

Coda

2010-08-03, 21:15:30

Außerdem ist auch fraglich ob sie da einen linearen oder realistischen Speedup angenommen haben. Zudem kommt es bei BD auch stark auf den Code an, mit reinem Integer-Code ist er natürlich um längen überlegen bei Serveranwendungen.

AffenJack

2010-08-03, 21:20:23

Naja, 50% ist wenn mans so nimmt trotzdem nicht soviel find ich.
Intel hat mit Westmere fast nur nen schrink durchgeführt und 50% cores geaddet und kriegt da seine 30-40% mehrleistung im durchschnitt.
Amd wechselt auf ne neue Architektur, führt nen shrink mit einführung von hkmg ein, was auch noch gut was bringen sollte und schafft trotzdem nur 50% mehrleistung?

Coda

2010-08-03, 21:23:21

Gast

2010-08-03, 21:28:24

Ein besserer Vergleich wären also 12 Cores gegen 16 Module (32 "Cores") gewesen.
Für Server toll, aber für Gamer... :confused:

Coda

2010-08-03, 22:04:45

Ich kann aus dem Vergleich überhaupt keinen Rückschluss auf die IPC-Leistung ziehen, deshalb wäre ich da ziemlich vorsichtig.

Ein Kern wird schon schneller sein, alles andere wäre für den Entwicklungsaufwand und die vermutete Breite der Architektur eher komisch.

Gast

2010-08-03, 22:05:23

Undertaker

2010-08-03, 22:10:36

Du darfst nicht vergessen, dass ein 32nm Bulldozer mit 8 Modulen ziemlich sicher kleiner ist als ein 45nm 6 Core Istanbul. Ein 12 Core Magny-Cours ist also mehr als doppelt so groß.

Ein besserer Vergleich wären also 12 Cores gegen 16 Module (32 "Cores") gewesen.

Würde ich wie der Gast mal ganz stark anzweifeln - für Desktop sind "nur" 4 Module geplant, das dürfte auf 200-300mm² hinauslaufen, für den riesigen Serversockel G34 mit 8 Modulen entsprechend das doppelte.

Man darf nicht vergessen: Bei ähnlicher Die-Size wie ein 4-Kern Deneb dürfte ein 4-Modul Bulldozer die Performance grob verdoppeln. Das wäre mehr als ordentlich. :)

Coda

2010-08-03, 22:16:47

Würde ich wie der Gast mal ganz stark anzweifeln
Was gibt's da anzuzweifeln? Ein BD-Modul ist angeblich 20% größer als ein K10-Core, der Shrink auf 32nm hat exakt doppelte Transistor-Dichte. (6 * 2) / 1.2 = 10

Auf gleicher Fläche wie die Istanbul-Cores würden theoretisch also 10 BD-Module passen, als 20 Cores. Selbst wenn es weniger sind gibt's an einem deutlichen Trend nichts zu leugnen.

Gast

2010-08-03, 22:18:12

Glaube ich nicht. Mehr als 4 BD Module wird es nicht geben in 32nm. Interlagos ist bereits ein MCM.

Daraus lässt sich allerdings schlussfolgern das bei üblicher Die-Size von 200-300mm² ein BD Modul die Größe von drei Phenom Kernen haben sollte. Natürlich skaliert auf den selben Fertigungsprozess. Dh ein BD-Kern müsste verdammt fett sein, gerade wo AMD den Zuwachs durch die CMT-Fähigkeiten mit den zweiten INT-Einheiten nur auf 20% beziffert.

Gast

2010-08-03, 22:19:34

Was gibt's da anzuzweifeln? Ein BD-Modul ist angeblich 20% größer als ein K10-Core, der Shrink auf 32nm hat exakt doppelte Transistor-Dichte. 6 * 2 * 1.2 = 14.4.

Auf gleicher Fläche wie die Istanbul-Cores würden theoretisch also 14 BD-Module passen, als 28 Cores. Selbst wenn es weniger sind gibt's an einem deutlichen Trend nichts zu leugnen.

Falsch. Laut AMD kostet die CMT-Fähigkeit, also die doppelten INT-Einheiten mit zwei Threads 20% mehr Die-Size.

Coda

2010-08-03, 22:22:25

Falsch. Laut AMD kostet die CMT-Fähigkeit, also die doppelten INT-Einheiten mit zwei Threads 20% mehr Die-Size.
Und was ist daran der Unterschied gegenüber dem was ich gesagt habe?

Gast

2010-08-03, 22:24:43

Und was ist daran der Unterschied gegenüber dem was ich gesagt habe?

AMD vergleicht einen hypothetischen BD Single-Core mit einem BD-Modul (also mit den doppelten INT-Einheiten und zwei Threads), du vergleichst mit einem K10.

Coda

2010-08-03, 22:26:52

Gast

2010-08-03, 22:31:54

Ach so - hatte mich auch schon immer über die Zahl gewundert.

Hatte oben aber auch falsch gerechnet. Hab's mal korrigiert. Mit 50% mehr Fläche sind's dann immer noch 8 Module auf gleicher Fläche, also 16 Cores.

Ähm, nochmal es gibt keine Aussage im Vergleich zu einem K10, du kannst also gar nicht wissen wieviele BD Module man statt K10 Kerne verbauen kann.

Coda

2010-08-03, 22:56:35

Nein, aber ein BD-Modul wird wohl kaum doppelt so groß sein wie ein K10-Kern.

Undertaker

2010-08-04, 08:03:30

Ich tippe mal auf etwas zwischen 50% und doppelter Größe - auch durch wachsende Caches. Die aktuellen 350mm² von Thuban sind sicherlich keine Dauerlösung.

Gast

2010-08-04, 21:10:39

sind 8 Bulldozer Module auf einem DIE für den Desktop überhaupt möglich?

Gast

2010-08-04, 23:14:27

sind 8 Bulldozer Module auf einem DIE für den Desktop überhaupt möglich?

von der größe her wahrscheinlich schon weil ein modul nur etwa so groß sein soll wie ein k10 kern.

allerdings ist fraglich ob die 8 modul bulldozer nicht aus 2 dies wie magny cours bestehen, dann wäre es natürlich nicht möglich

john carmack

2010-08-05, 12:49:56

Hm - war der K8 damals nicht in 130 nm Bulk als Samples ausgeführt?

Jup...

ich hab noch einen K8 Newcastle Kern (A64 3500+ 130nm)

Undertaker

2010-08-05, 12:55:05

von der größe her wahrscheinlich schon weil ein modul nur etwa so groß sein soll wie ein k10 kern.

Fertigungsbereinigt? Oder in 32nm vs. 45nm? Mit Caches? Spekulation oder gibt es dafür eine Quelle?

Geschätzt hätte ich zumindest eine ähnliche Größenordnung - 4 Module bei ca. 260mm² klingt realistisch für das vorläufige Desktop-Topmodell.

robbitop

2010-08-05, 13:01:10

Jup...

ich hab noch einen K8 Newcastle Kern (A64 3500+ 130nm)
Nein - Verkauft wurden nur SOI 130 nm Kerne. Mir geht's um Bulk statt SOI.

john carmack

2010-08-11, 15:13:51

nur noch 2 Wochen... :-)

http://www.hotchips.org/program/conference-day-two/

Gast

2010-08-11, 16:40:57

nur noch 2 Wochen... :-)

http://www.hotchips.org/program/conference-day-two/

und danach gibts immer noch zu 90% offene fragen die keiner bis zum launch verratet.

john carmack

2010-08-11, 16:50:50

das immer ein da sein muss der alles in den Dreck zieht!

Gast

2010-08-11, 17:26:36

und danach gibts immer noch zu 90% offene fragen die keiner bis zum launch verratet.
Nein, die Arch. wird zu 100% offen gelegt. Was übrig bleibt sind höchstens Fragen wie entgültige Taktfrequenzen, 100% AM3 Kompatibilität und Preis.
Achja und natürlich richtige Benchmarks, die gibt es erst zum entgültigen Launch.

Triskaine

2010-08-11, 20:08:26

Die AMD Person sagt:

Zitat von JF-AMD
Yes, I went over the slides last night. There will be data on ALU/AGU, extensions, front end, Flex FP and more.

The slides will not have the same depth that the talk will because an engineer will be doing the voice over. We hope to get some of them to blog later, but the 20 questions blog should allow us to get some of the details out.

People just shouldn't expect Hot Chips to be a big unveiling. It is sharing details. Just don't want people getting to hyped on it.

Gast

2010-08-11, 20:53:48

das stand bei AMDZONE

john carmack

2010-08-11, 22:23:43

Bulldozer: Papiertiger oder Rechenwunder?

Gast

2010-08-11, 23:00:41

1 Bulldozer Modul wird 70% schneller als ein K8 Core

john carmack

2010-08-11, 23:07:07

Kann mir mal jemand sagen was den Fusion/Llano mit dem Bulldozer zu tun hat?

Wie soll das aussehen?

Ich meine bei SandyBridge ist die Grafikeinheit wohl immer an board.

Gast

2010-08-11, 23:07:07

bei welchem Code? wie kommst du auf 70% ?

laut JF, Interlagos vs. Magny Cours soll es weit weniger sein!

zwischen K8 & K10 liegen bei der IPC 20% unterschied

das wäre 50% Speedup, als pro Core 25% schneller als ein K10.

Gast

2010-08-11, 23:09:01

Kann mir mal jemand sagen was den Fusion/Llano mit dem Bulldozer zu tun hat?

garnichts

Bulldozer = Neue Architektur ohne IGP

Llano = alte K7-K10 Architektur mit Redwood IGP

john carmack

2010-08-11, 23:11:37

Wo steht das mit der K7-K10 Architektur?

davidzo

2010-08-11, 23:12:13

richtig, allerdings ist der Llano Nachfolger mit FusionAPu auf Bulldozerbasis auch schon in der pipe... - von der architektur zum fusionprodukt dauerts halt ein bisschen länger. höchstwahrscheinlich dann mit northern islands apu

DarkFox

2010-08-11, 23:16:56

Ist die Info, dass der Desktop-Bulldozer mit Sockel AM3r2 aka AM3+ kommt und abwärtskompatibel zu AM3 ist, noch aktuell?

john carmack

2010-08-11, 23:18:01

ich denke ja...

Gast

2010-08-11, 23:20:05

Wo steht das mit der K7-K10 Architektur?

google mal bischen

stell dir einfach vor, ein Athlon II mit IGP in 32nm

Zielgruppe > Mainstream Markt bis 150 $

john carmack

2010-08-11, 23:31:29

aha... also gar nix besonders. Da wird wohl Sandy Bridge noch die Nase vorn haben - Wenn auch nur Intel IGP.

Gast

2010-08-11, 23:45:50

aha... also gar nix besonders. Da wird wohl Sandy Bridge noch die Nase vorn haben - Wenn auch nur Intel IGP.

AMD kann nur durch die Grafik Power punkten, dafür hat man gleich
400 Shader vom R800.

Llano Quad Core vs. Sandy Bridge Dual Core, so wirds AMD machen.

Bulldozer wird im High End & Server eine Rolle spielen

Mainstream = Llano

High End = Bulldozer

john carmack

2010-08-13, 15:11:06

Na dann hoffe ich mal das AMD, wie damals zu A64 Zeiten, ein ähnlich großer Wurf gelingt.

Glaubt jemand daran?

Pirx

2010-08-13, 15:39:45

Na dann hoffe ich mal das AMD, wie damals zu A64 Zeiten, ein ähnlich großer Wurf gelingt.

Glaubt jemand daran?
Natürlich!:D

Wird's für Desktop eigentlich nur den Sockel AM3+ geben, oder auch noch einen mit breiterem RAM-Interface?

john carmack

2010-08-13, 15:56:28

Natürlich!:D

Wird's für Desktop eigentlich nur den Sockel AM3+ geben, oder auch noch einen mit breiterem RAM-Interface?

Wie geil aber auch, wie als würde es nix dranzu zweifeln geben... ;D

Konami

2010-08-13, 16:23:00

Na dann hoffe ich mal das AMD, wie damals zu A64 Zeiten, ein ähnlich großer Wurf gelingt.

Glaubt jemand daran?
Ist noch zu früh, um das sagen zu können. Aber wir hoffen es wohl alle. ;)

Gast

2010-08-13, 22:32:38

Na dann hoffe ich mal das AMD, wie damals zu A64 Zeiten, ein ähnlich großer Wurf gelingt.

Glaubt jemand daran?

was heist großer Wurf ? damals 2,2 Ghz K8 vs. 3,2 Ghz P4, das ist vorbei, heute ist AMD der P4 und Intel ist der A64.

Intel hat aktuell bis zu 30% mehr IPC Power als AMD und mit Sandy Bridge wird der Abstand noch größer.

Intel wird für den Desktop 8 Kerne anbieten, ja 8 Monster Kerne mit über 3 Ghz

Wenn ihr ein großen Wurf von AMD sehen wollt, dann muss ein Bulldozer Core 50% schneller als ein K10 sein um überhaupt mit einem Sandy Bridge mithalten zu können, nicht 8 AMD Kerne vs. 4 Intel Kerne, Cores sind Cores, nicht Äpfel mit Birnen vergleichen.

Gast

2010-08-13, 23:39:36

was heist großer Wurf ? damals 2,2 Ghz K8 vs. 3,2 Ghz P4, das ist vorbei, heute ist AMD der P4 und Intel ist der A64.

Intel hat aktuell bis zu 30% mehr IPC Power als AMD und mit Sandy Bridge wird der Abstand noch größer.

Intel wird für den Desktop 8 Kerne anbieten, ja 8 Monster Kerne mit über 3 Ghz

Wenn ihr ein großen Wurf von AMD sehen wollt, dann muss ein Bulldozer Core 50% schneller als ein K10 sein um überhaupt mit einem Sandy Bridge mithalten zu können, nicht 8 AMD Kerne vs. 4 Intel Kerne, Cores sind Cores, nicht Äpfel mit Birnen vergleichen.

bei entsprechend parallelisierter software macht es wohl keinen unterschied ob die leistung von mehr cores oder takt/ipc kommt, man sieht es ja gut an magny cours der bietet bessere leistung und geringeren stromverbrauch und preis als vergleichbare xeons.

im desktop markt schaut es leider schlechter aus was da betrifft aber hoffentlich tut sich bis 2011 mal was mit multi core support

Psychopat

2010-08-14, 01:20:07

Wenn ihr ein großen Wurf von AMD sehen wollt, dann muss ein Bulldozer Core 50% schneller als ein K10 sein um überhaupt mit einem Sandy Bridge mithalten zu können, nicht 8 AMD Kerne vs. 4 Intel Kerne, Cores sind Cores, nicht Äpfel mit Birnen vergleichen.

"Cores sind Cores" geht mit Bullozer dann leider nicht mehr, die Unterschiede in der Architektur zwischen Intel und AMD sind dann zu groß, als das man das so vergleichen könnte. nVidia und ATI vergleicht man ja auch nicht Cores gegen Cores, weil es einfach nicht passt. Um die (absolute) Effizienz eines Designs zu beurteilen, könnte man am ehesten noch nach Die-Größe vergleichen. Ist aber letztlich auch egal (siehe Grafikkarten), das einzige was wirklich interessiert (uns als Verbraucher) ist der Vergleich nach Preis.

deekey777

2010-08-14, 21:20:48

http://blogs.amd.com/fusion/2010/08/12/unveiling-the-innovation-of-%E2%80%9Cbobcat%E2%80%9D-and-%E2%80%9Cbulldozer%E2%80%9D/

Gast

2010-08-14, 21:37:55

http://blogs.amd.com/fusion/2010/08/12/unveiling-the-innovation-of-%E2%80%9Cbobcat%E2%80%9D-and-%E2%80%9Cbulldozer%E2%80%9D/

und?

john carmack

2010-08-18, 17:52:28

Kommen die Bulldozer eigentlich mit 8 Cores für den Desktop?

Sorkalm

2010-08-18, 18:08:04

Kommen die Bulldozer eigentlich mit 8 Cores für den Desktop?

4 BD-Modulen, also "8 Kernen", ja...

dildo4u

2010-08-18, 18:10:01

Kommen die Bulldozer eigentlich mit 8 Cores für den Desktop?
Muss wie willst du sonst einem x6 User die neue CPU's verkaufen?Selbst wenn die Pro Core Leistung 30% besser ist,wird keiner von 6 auf 4 zurückrüsten oder auf 6 Sidegraden.

Gast

2010-08-18, 21:33:15

Mal was von P3D: AMDs Bulldozer-Architektur - ein Puzzle zusammengesetzt

http://www.planet3dnow.de/vbulletin/showthread.php?t=384394

Gast

2010-08-18, 21:42:15

http://img827.imageshack.us/img827/3146/filewl.jpg

Gast

2010-08-18, 22:01:00

Gast

2010-08-18, 22:18:05

hauptsache Intel baut in Zukunft keine Bulldozer Kopie

S940

2010-08-18, 22:38:32

Es gibt Gerüchte, dass Intel den Sandy-Bridge-Kern als Reaktion auf Bulldozer derzeit überarbeitet. Dieser neue Kern soll Version 1.1 darstellen und neue Fähigkeiten aufweisen, die ihn konkurrenzfähiger machen sollen. Wenn er nicht bis zum geplanten Erscheinungstermin produktionsreif sein sollte, würde die jetzige Version auf den Markt kommen. Solche Entscheidungen würden natürlich das Profitabilitätsfenster sowohl von Sandy Bridge als auch Bulldozer beeinflussen. So wie es aktuell ausschaut wird aber Sandy Bridge vorgezogen. Dadurch betrüge der Vorsprung vor AMDs Bulldozer ca. ein halbes Jahr, was ein gutes Profitabilitätsfenster ergäbe.

Die Gerüchte gabs vor längerer Zeit, als Sandy noch nicht auf Q4 gesetzt wurde. Von daher kann man die jetzt vergessen, da Sandy in Q4 kommt.

Eventuell basierte das Ganze auch nur auf nem Mißverständnis, da später in 2011 ja eh die 8 Kern Sandys kommen. Wenn man will, kann man das als Sandy 1.1 sehen, obwohl am einzelnen Kern nichts verändert sein wird, dafür aber halt am Uncore. Aber das bitte dann im Sandy Thread nachfragen.

=Floi=

2010-08-19, 01:32:20

die bulldozer idee halte ich schon für gut und es wäre nicht schlecht wenn intel das auch kopieren würde.

gerade intel verbaut mehr kerne und ermöglicht so eher eine leistungssteigerung. (bei anwendungen, welche nur 1-4 threads nützen)
wenn intel mit echten 8 kernen kommt, dann könnte man damit auch eine anwendung mit 4 kernen maximal beschleunigen und unter anderen umständen dank HT auch eine anwendung mit 16 threads bearbeiten.
gerade das wäre eine geniale kombination und würde vor allem bei den richtig großen cpus im alltagsbetrieb mehr bringen.

bei amd scheitert es eh wieder am normalen quad core, weil hier die anwendung nicht alle 4 cores nützen darf um in den genuss der gesteigerten leistung pro thread zu kommen.

SavageX

2010-08-19, 08:26:13

gerade intel verbaut mehr kerne und ermöglicht so eher eine leistungssteigerung. (bei anwendungen, welche nur 1-4 threads nützen)
wenn intel mit echten 8 kernen kommt, dann könnte man damit auch eine anwendung mit 4 kernen maximal beschleunigen und unter anderen umständen dank HT auch eine anwendung mit 16 threads bearbeiten.
gerade das wäre eine geniale kombination und würde vor allem bei den richtig großen cpus im alltagsbetrieb mehr bringen.

Es ist schwer dem zu folgen. Meinst Du "je mehr Kerne, desto heftiger der TurboBoost"?

Richtig, aber desto geringer der Basistakt. Ein Vielkern-Prozessor kommt im Endeffekt nicht auf höhere Taktraten bei Teillast als ein Prozessor, der mit der "richtigen" Anzahl der Kerne kommt.

bei amd scheitert es eh wieder am normalen quad core, weil hier die anwendung nicht alle 4 cores nützen darf um in den genuss der gesteigerten leistung pro thread zu kommen.

Hmmm?

john carmack

2010-08-19, 08:48:24

4 BD-Modulen, also "8 Kernen", ja...

?

meinst du jetzt 4 cores + AMD HyperThreading

oder

meinst du jetzt 8 echte Physikalische Cores?

BlackBirdSR

2010-08-19, 08:51:14

?

meinst du jetzt 4 cores + AMD HyperThreading

oder

meinst du jetzt 8 echte Physikalische Cores?

Die Übersicht nicht gesehen?

1 Modul besteht aus 4 traditionellen Kernen, von denen jeder 2 Integer-Cluster hat. Diese Cluster werden wohl abwechselnd vom Front-End bedient und können je nach dem was AMD nun gemacht hat, komplett unabhängig arbeiten - ergo 2 Threads/Kern.
4x2 = 8

john carmack

2010-08-19, 09:00:00

Es gibt Gerüchte, dass Intel den Sandy-Bridge-Kern als Reaktion auf Bulldozer derzeit überarbeitet.

Quelle?

Undertaker

2010-08-19, 09:00:41

Gast

2010-08-19, 09:05:58

Quelle?
Brainfart...

Derzeit wird nichts mehr an SNB überarbeitet, da dieser kurz vor der Massenproduktion steht.
Wenn dann gibt es eine Reaktion auf Bulldozer, abhängig davon ob überhaupt nötig und vom Zeitpunkt, wann Intel relevante Informationen zu BD besaß, wohl frühestens mit dem nächsten Tick 2012.

john carmack

2010-08-19, 09:08:31

Wenn man will, kann man das als Sandy 1.1 sehen, obwohl am einzelnen Kern nichts verändert sein wird, dafür aber halt am Uncore. Aber das bitte dann im Sandy Thread nachfragen.

Was ist ein Uncore?

john carmack

2010-08-19, 09:29:06

Die Übersicht nicht gesehen?

1 Modul besteht aus 4 traditionellen Kernen, von denen jeder 2 Integer-Cluster hat. Diese Cluster werden wohl abwechselnd vom Front-End bedient und können je nach dem was AMD nun gemacht hat, komplett unabhängig arbeiten - ergo 2 Threads/Kern.
4x2 = 8

wie jetzt - 1 Modul = 4 Kerne?

Nach AMD-Nomenklatur besitzt ein Modul zwei Kerne mit je einem Thread.

Das sind dann aber keine 2 vollständinge (2 x 100% vollwertige) Kerne, oder?

+++++++

Das Bild sagt mir jetzt nicht so viel...

Undertaker

2010-08-19, 10:29:06

Das sind dann aber keine 2 vollständinge (2 x 100% vollwertige) Kerne, oder?

Rein nach Definition nicht - es gibt z.B. nur eine, wenn auch aufteilbare, FPU. Wie es mit der Performance eines BD-Moduls im Vergleich zu zwei K10.5 Kernen aussieht ist dann schon wieder eine andere Frage, hier sollte ein Modul mit entsprechenden Taktraten doch durchaus etwas schneller sein.

Gast

2010-08-19, 10:32:28

Das sind dann aber keine 2 vollständinge (2 x 100% vollwertige) Kerne, oder?

Die entscheidenden INT-Einheiten sind vollständig doppelt vorhanden, deshalb sollte sich ein solches Modul in der Regel wie zwei vollwertige Kernen verhalten. FP benötigt man ohnehin nicht oft, braucht aber viel Die-Size, deshalb halte ich die Lösung für sehr intelligent und sinnvoll.

=Floi=

2010-08-19, 10:32:34

http://img1.imagebanana.com/img/gv7ybz07/Capture.PNG
ich meinte das mit der sache wo eben 2 cores zu einem zusammengeschaltet werden. dafür brauche ich erst mal genug cores, damit es auch wirklich etwas bringt. Da würde intel einfach besser dastehen, weil sie dann auch 8 cores haben werden.

Gast

2010-08-19, 10:41:54

Ich kann doch genauso behaupten, dass 1 Modul 2 Cores hat.
Das ist genau so richtig oder falsch wie zu behaupten, dass ! Modul 1 Core ist.
Das Marketing wird da sicher nicht leiden.

Der_Korken

2010-08-19, 11:47:37

ich meinte das mit der sache wo eben 2 cores zu einem zusammengeschaltet werden. dafür brauche ich erst mal genug cores, damit es auch wirklich etwas bringt. Da würde intel einfach besser dastehen, weil sie dann auch 8 cores haben werden.

AMD verbaut doch insgesamt 4 Module, ergo 8 Kerne, wenn man so will. Damit würde man 4 Threads zusätzlich beschleunigen können (wenn AMD denn tatsächlich eine solche Technik implementiert hat). Aber selbst, wenn es nur 1 oder 2 Module wären, verstehe ich das Problem daran nicht. Dann kann der Prozessor eben nur 2/4 Threads abarbeiten oder wahlweise 1/2 Threads mit Speedup. Wäre doch auch kein Problem.

Pirx

2010-08-19, 12:29:03

Ein 4-Moduler mit sozusagen "8 Kernen" wird doch bestimmt mindestens kommen, es gibt ja auch noch die kleinere Fertigungstechnologie und man spart wegen des Moduldesigns ggü. einem 8-Kern K10.5 bestimmt einiges an Transistoren..

john carmack

2010-08-19, 12:35:30

Die entscheidenden INT-Einheiten sind vollständig doppelt vorhanden, deshalb sollte sich ein solches Modul in der Regel wie zwei vollwertige Kernen verhalten. FP benötigt man ohnehin nicht oft, braucht aber viel Die-Size, deshalb halte ich die Lösung für sehr intelligent und sinnvoll.

Wo kann ich das nachlesen? Ganz ehrlich? Ich raff das noch nicht so ganz!

Gast

2010-08-19, 12:41:53

Wo kann ich das nachlesen? Ganz ehrlich? Ich raff das noch nicht so ganz!

ist wohl doch etwas forgeschrittener als die "von neumannsche maschine" ;D;D;D;D;D

Mit der von Neumann Architektur hat das Nicht zu tun.
Ein Rechner mit Bulldozer CPU ist genau so eine von Neumann Architektur wie fast alle anderen vorher auch.

S940

2010-08-19, 16:51:14

1 Modul besteht aus 4 traditionellen Kernen, von denen jeder 2 Integer-Cluster hat. Diese Cluster werden wohl abwechselnd vom Front-End bedient und können je nach dem was AMD nun gemacht hat, komplett unabhängig arbeiten - ergo 2 Threads/Kern.
4x2 = 8
Uhh aufpassen, dass ist unvorteilhaft formuliert, da AMD den Begriff Modul mit dem gleichsetzt, was Du "traditionellen Kern" nennst ...
Nimm anstatt Modul besser Chip oder DIE.

@john carmack:
Alles ausserhalb des L2 ist "Nichtkern" ;-)

Also L3, Hypertransport, Speicherkontroller, der ganze I/O Krams.

ciao

Alex

S940

2010-08-19, 16:52:47

Wo kann ich das nachlesen? Ganz ehrlich? Ich raff das noch nicht so ganz!

Da:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1282159277

Was Besseres gibts z.Zt. zum Thema Bulldozer nicht.

Wenn Du nicht alles kapierst, frag nach :)

Aja noch eine Anmerkung, das mit dem "vollwertig" muss man immer inkl. Skalierungsverluste sehen, die 2 Cluster eines Bulldozer Moduls sollen laut AMD Marketingaussage zusammen 180% Leistung bringen. Also nicht 200%, die 2 einzelne Kerne hätten, aber allemal besser als das max. Leistungsplus von Intels Hyperthreading, welches bei ~135% liegt, im schlimmsten Fall aber auch Leistung kosten kann.

ciao

Alex

puntarenas

2010-08-19, 18:00:56

Aja noch eine Anmerkung, das mit dem "vollwertig" muss man immer inkl. Skalierungsverluste sehen, die 2 Cluster eines Bulldozer Moduls sollen laut AMD Marketingaussage zusammen 180% Leistung bringen. Also nicht 200%, die 2 einzelne Kerne hätten, aber allemal besser als das max. Leistungsplus von Intels Hyperthreading, welches bei ~135% liegt, im schlimmsten Fall aber auch Leistung kosten kann.
Da ich absolut kein professioneller Anwender bin und ich als Spieler mit Llano sicher nicht gemeint sein kann, habe ich in Bezug auf Zambezi mit seinen 4 Modulen eigentlich nur drei Fragen:

1) Wie viel Single-Thread-Leistung bringt Zambezi taktbereinigt maximal aufs Parkett (von mir aus wenn der Thread ein Modul für sich exklusiv nutzen kann) und zwar im Vergleich zu einem Lynnfield-Kern?

2) Wie viele Threads können gleichzeitig in den Genuss dieser Maximalleistung kommen?

3) Welche Taktraten sind bei solch einer Lastsituation erreichbar?

Ich bin grundsätzlich gern bereit, einen Zambezi als "Quadcore aus Spielersicht" zu betrachten, das würde mir reichen und wenn die IPC deutlich über einem K10.5 läge, hätte AMD wieder einen Gamer-Prozessor. Wenn AMD bei 4 Modulen dann gleichzeitig von einem Achtkernprozessor spricht, ist mir das prinzipiell auch egal. Ich befürchte nur, AMD wird bis zum Launch marketingfreundlich brav die Verwirrung aufrecht erhalten und man wird sie nicht darauf festnageln können, welche Aussage sich denn nun auf einen Cluster, ein Modul oder einen Kern bezieht.

Dann bleiben natürlich noch die Fragen, ob Zambezi ohne große Einschränkungen auf derzeitigen AM3-Boards laufen wird, wie seine Energieeffizienz aussieht und ob Microsoft wieder zwei Windowsversionen braucht, um dem Sheduler geeignete Strategien beizubringen. Außerdem sehne ich Informationen zu den Stromsparmechanismen herbei, zum Beispiel ob auch bei AMD ein segensreicher C6-State Einzug hält.

Mal sehen, ob die Hot Chips Conference mit AMDs serverorientiertem Auftritt erste Antworten bringt.

S940

2010-08-19, 18:07:35

Na die Sache mit dem Scheduler ist gegessen, solange AMD seine 2 Cluster als logische Kerne tarnt, quasi als Hyperthreading verkauft.

Machen sie sicherlich, alles andere wäre arg dumm ;-)
Wenn ich mich recht erinnere, dann setzte schon der erste X2 das Hyperthreading Flag.

Deine 3 Fragen kann Dir im Moment aber keiner beantworten, Fragen nach Takt und genauer Mehrleistung sind immernoch viel zu speziell. Irgendwas zw. 0 und 100% Mehrleistung wird es werden und wg. 32nm wird der Takt sicherlich nicht weniger werden ;)

Das muss Dir im Moment leider genügen ^^

Kurz: Mehr als in Dresdenboys Artikel auf P3D gibts im Moment nicht, genaue Antworten gibts erst nach/beim BD Launch - falls davor nichts irgendwas durchsickert.

puntarenas

2010-08-19, 18:10:20

Das muss Dir im Moment leider genügen ^^

Weiß ich doch, aber wenn man auf Kohlen sitzt tut es einfach gut, gelegentlich mal Mimimi zu machen. :smile:

john carmack

2010-08-19, 18:33:13

Kurz: Mehr als in Dresdenboys Artikel auf P3D gibts im Moment nicht, genaue Antworten gibts erst nach/beim BD Launch - falls davor nichts irgendwas durchsickert.

in ein paar tagen gibts ja daas hier: http://www.hotchips.org/

Da kommen bestimmt mehr infos zum BullDozer

uns so wie die Agenda aussieht nix neues zur HD6000

john carmack

2010-08-19, 18:42:15

Deine 3 Fragen kann Dir im Moment aber keiner beantworten, Fragen nach Takt und genauer Mehrleistung sind immernoch viel zu speziell. Irgendwas zw. 0 und 100% Mehrleistung wird es werden und wg. 32nm wird der Takt sicherlich nicht weniger werden ;)

Können den irgendwelche TechnikFans sagen wieviel mehleistung Theoretisch drin sind?

Bzw. wie sich der BullDozer % gesehen zu einem Nehalem verhalten würd?

Alles ganz theoretisch natürlich.

BlackBirdSR

2010-08-19, 19:21:07

Können den irgendwelche TechnikFans sagen wieviel mehleistung Theoretisch drin sind?

Bzw. wie sich der BullDozer % gesehen zu einem Nehalem verhalten würd?

Alles ganz theoretisch natürlich.

technisch nö!
Marktwirtschaftlich: zwischen 10 und 30%. Mehr in Sonderfällen. So wie immer halt.

Undertaker

2010-08-19, 19:23:18