News Offizielle Details zu „Bobcat“ und „Bulldozer“ von AMD

[Complication]

Das wird für die ALUs spekuliert:
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137878&p=187844

Ok guys,another maybe a bit far fetched idea as integer cores go(brace for a trip down the memory lane): if the other core is not utilized,in a single thread case for instance, could there be a double pumping of the ALUs,now that we know AMD aims high with regards to clock speeds in Bulldozer?It could be a sort of "accelerate" mode,where 2+2 pipelines are double pumped(2x the frequency) and when they are utilizing the whole 4+1 issue decoder? Some may think this is a P4-like feature,but if the power figures for double pumped 2ALUs and 2AGUs are not a problem ,then maybe AMD thought about this idea?

Aber da weiss man auch noch nichts genaues.

Was die FPU betrifft, so ist ja die FPU bei Sandy Bridge 256 bit breit - Bulldozer hat 2 FPUs die jeweils 128 bit breit sind und je nach Notwendigkeit beide einem Integer oder jeweils einem Kern zugewiesen werden können - das soll sogar pro Takt möglich Sein. Das wiederum würde heissen dass ein Integer Kern in einem Singlethread 2x128bit FPUs nutzen kann.

Lediglich bei 256 bit breiten AVX Anweisungen würde die FPU nur noch 1 Thread pro Modul abarbeiten können und Sandy Bridge hätte hier doppelt so viele FPUs zur Verfügung wenn massiv Multithreaded AVX nutzende Software zum Einsatz kommt - ich erwarte die ersten Hauseigenen Intel Benchmarks die genau das nutzten werden
Zumindest würde ich damit die Markteinführung unterstützen
Für die Praxis wohl noch auf Jahre hinaus nicht relevant und für Desktop wohl überhaupt nicht.

 

[silent-efficiency]

Die Leistungseinschätzung von AMD wurde bezogen auf Multithreading gemacht. Man hat also den Durchsatz gemessen und dann das ganze pro Kern geteilt und gesagt, so pro Kern gibt es also mehr Leistung. Das ist ja so weit ok, nur hat das nichts mit Single-Threading-Leistung zu tun, sondern nur mit Durchsatz pro Kern bei einer Multihreading-Anwendung.

Was genau ist der Unterschied?

Single Threading Anwendung sieht ein AMD Modul:
Große Dekoder, große FPU, alles bestens!
Nun will sie aber Integerdaten berechnen. Was kriegt sie? Zwei Integerpipliens.

Zwei Threads kommen an:

Dekoder müssen geteilt werden, FPU muss geteilt werden.

Pro Thread immer noch zwei Integerpiplienes.

Also 1 Thread: 2 Integerpilines
Zwei Threads: 2 Integerpilienes pro Thread und gemeinsame Nutzung anderer Resourcen.

-----


Jetzt kommt die Anwendung an Intels SMT-Kern

Single-Thread Anwendung bekommt: 3 Integerpilienes
Zwei Threads bekommen: 1,5 Integerpilenes pro Thread

-----

Man sieht also, dass AMDs Lösung bei Multithreading mehr Durchsatz als ein INtel-SMT-Core durch die Integerpilenes theoretisch durchjagen kann. Im Falle einer Single-Thread-Anwendung ist aber genau andersherum, da dort der Intelkern die Resourcen bündelt, während bei AMD nur die FPU gemeinsam genutzt werden kann.

---

Natürlich könnte AMD die Integer-Kerne höher Takten um das Single-Thread-Problem zu lösen, wenn nur ein Thread auf dem Modul läuft, aber dazu gibt es ja noch keine Infos...

 

[Fetter Fettsack]

@ Posts #138 und #139

Danke für die für die Nachhilfe.^^

Wegen des Atom-Bobcat-Vergleiches:

Das heißt dann, dass der Atom ein ineffizienteres Verfahren anwendet, weil Bobcat mehr Teilbefehle zur gleichen Zeit abarbeiten kann?

 

[gruffi]

70% mehr bei 33% mehr Integer-Kernen sind ein großer Sprung (grob Nehalem-Niveau!), die FPU sieht überzeugend aus. Sollte das so weiter gehen, wird Bulldozer wohl zumindest im Server-Markt mit SB mithalten können - Desktop aber nicht.

Ist hier schon wieder der Wunsch der Vater des Gedanken?

Nach bisherigem Kenntnisstand schaut es wie folgt aus. In Multithreaded Szenarien arbeitet ein Bulldozer Modul wie eine 2x2 OoO Engine. Mit 2-fach superskalar deckst du bereits etwa 80-90% der theoretisch erreichbaren Performance ab. Die Konsequenz ist klar, hoher Durchsatz, hohe Energieeffizienz. Super für Server. In Singlethreaded Szenarien arbeitet ein Modul hingegen wie eine 1x4 OoO Engine, vergleichbar mit Nehalem / Sandy Bridge. Also hohe Singlethreaded Performance, hohe Leistungsaufnahme. Wobei letzteres aufgrund des vorhandenen Energiebudgets vernachlässigbar ist.
Ich sehe es eher so, dass Bulldozer und Sandy Bridge im Client Markt auf vergleichbarem Level liegen. Intel sollte sich maximal mit einem 8-Kern Sandy Bridge absetzen können. Der wird aber auch recht gross und recht teuer. Bei Servern sollte Bulldozer, im Speziellen Interlagos, die Konkurrenz hingegen abhängen können.

Also für den Laien (also mich^^) heißt das: mehr IPC?

Wie Complication schon schrieb, Singlethreaded Performance ist das Produkt aus IPC und Takt. Beide Faktoren sollen laut AMD mit Bulldozer gesteigert werden.

Das wird für die ALUs spekuliert:
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137878&p=187844

Aber da weiss man auch noch nichts genaues.

Lies mal zwei Beiträge weiter.

No, that is not happening.

Double pumped EUs können wir bei Bulldozer damit wohl ausschliessen. Bei Sandy Bridge hingegen könnte die FPU tatsächlich double pumped sein. Laut Die Shots hat sich an der FPU nichts grundlegend geändert, physisch also weiterhin 128-bit. Double Pumped wäre eine Möglichkeit, den Durchsatz pro Takt auf 256-bit zu erhöhen.

Lediglich bei 256 bit breiten AVX Anweisungen würde die FPU nur noch 1 Thread pro Modul abarbeiten können und Sandy Bridge hätte hier doppelt so viele FPUs zur Verfügung wenn massiv Multithreaded AVX nutzende Software zum Einsatz kommt

Nicht wirklich. Es wird dann davon abhängen, wie viele Kerne bzw Module die jeweilige CPU haben wird. Wenn wir mal ein Bulldozer Modul und einen Intel Kern pro Takt gegenüberstellen (beide haben 2 logische Prozessoren):

Bulldozer - SSE - 2x 128-bit
Bulldozer - AVX - 1x 256-bit

Sandy Bridge - SSE - 1x 128-bit (?)
Sandy Bridge - AVX - 1x 256-bit

Bei AVX dürfte es rein von den Kapazitäten also ausgeglichen sein. Bei SSE könnte Bulldozer im Vorteil sein.




Noch etwas zu den ALUs. Man sollte nicht denken, nur weil K10 pro Kern 3 ALUs + 3 AGUs hat und Bulldozer pro (Integer) Kern voraussichtlich nur noch 2 ALUs + 2 AGUs würde die IPC sinken. Ausführungseinheiten sind letztendlich nur Mittel zum Zweck. K10 schaut gut aus, man kann theoretisch 6 Integer Micro-Ops pro Takt verarbeiten. Das nützt einem nur herzlich wenig, da das Frontend lediglich 3 x86 Instruktionen bzw 3 Macro-Ops pro Takt ausspucken kann. Die Integer Ausführungseinheiten werden also die meiste Zeit nicht ausgelastet.
Die durchschnittliche IPC liegt bei aktuellen CPUs in realen Anwendungen irgendwo bei 1. Das gilt für AMD sowie Intel. Integer Operationen pro Takt liegen noch deutlich darunter. Also streng genommen sind selbst 2 ALUs + 2 AGUs noch überdimensioniert. Unwichtig sind sie deshalb trotzdem nicht, um Spitzen zu kompensieren. Nicht in jedem Takt müssen gleich viele Integer Operationen ausgeführt werden. Zudem ist die Hauptaufgabe der AGUs ja die Berechnung von Speicheradressen. Loads und Stores machen bereits einen grossen Teil des Codes aus.
Kurzum, IPC hängt hauptsächlich davon ab, was Frontend und Pipeline pro Takt an die Ausführungseinheiten ausspucken können. Und hier ist Bulldozer pro Kern 4-fach superskalar ausgelegt, K10 war lediglich 3-fach superskalar. Das ist theoretisch 33% mehr Durchsatz pro Takt. Die Ausführungseinheiten müssen dann lediglich ausreichend dimensioniert sein, um diese Menge von Instruktionen bewältigen zu können. Und dafür können 2 ALUs + 2 AGUs schon vollkommen ausreichend sein, wenn sie entsprechend flexibel einsetzbar sind.
Bei AMDZone wurde übrigens ein interessantes Patent diskutiert, welches eine sogenannte AMU (Add/Move Unit) beschreibt, die an die AGU gekoppelt wird und deren Logik mitbenutzt. Man hätte hier also einen weiteren Port zur Verfügung, wo man MOVs (Zuweisungen) und ADDs (Additionen) bewältigen kann. Damit ergäben sich ebenfalls bis zu 6 Micro-Ops pro Takt, genauso wie bei K10.
Also bitte nicht voreilig irgendwelche Rückschlüsse anhand der Anzahl der ALUs/AGUs ziehen, bevor man keine genauen Details kennt.

 

[gruffi]

bzgl. den FPUs und den 256-bit AVX Instructions bin ich natürlich von einem 1:1 zählen der Kerne ausgegangen, sprich Integer Kernen, wie es im Marketing wohl sein wird.
Also z.B 4(8 Core) Modul Bulldozer vs. 8 Core Sandy.

Hatte ich mir schon fast gedacht. Man sollte aber eher ein Modul mit einem SMT Kern von Intel vergleichen. Beide haben halt 2 logische Prozessoren. Auch wenn uns das AMD Marketing ein Modul als zwei Kerne verkaufen will, auf Ingenieursebene ist ein Modul im Grunde ein Kern mit 2 Integer Clustern. Man kann es ja auch gut auf dem Orochi Die Shot, was ein "Kern" ist. Die maximale Ausbaustufe wird zudem ein Bulldozer mit 8 Modulen und ein Sandy Bridge mit 8 SMT Kernen darstellen.

ja das ist in etwas dieses was bei Planet3D auch steht:
http://www.planet3dnow.de/vbulletin/showthread.php?t=384581&garpg=2#content_start
Diese zusätzliche Integer-MAC-Einheit.

Nicht wirklich. Diese IMAC Einheit (Integer Multiply/Accumulate) bezieht sich auf die SIMD Einheiten. Die von mir angesprochene AMU ist nochmal etwas anderes.

 

[Complication]

Ja ich hatte erst nach meinen Posting die weiterführenden Beiträge in deinem Link gelesen - das erklärt dann vielleicht auch die AGen Bezeichnung anstatt AGU - hier wird es wohl noch mehr Überraschungen geben

Ja das mit den Kernen fällt mir schwer zu akzeptieren - die SMT Logik unterscheidet sich so grundlegend dass es mir schwer fällt hier von einem "logischen Kern" zu sprechen. Auch wenn das tatsächlich korrekt ist. Dann müsste man anfangen die SMT Kerne mit einzubeziehen und die Leistung statt mit 4 Kernen mit 8 Kernen rechen - irgendwie erscheint mir das nicht gerade sinnvoll
Auch was die Performance der SMT Kerne angeht fällt es mir schwer das als vollwertigen logischen Kern zu bezeichnen.

 

[Fetter Fettsack]

Übrigens, ich möchte nur festhalten, dass mein Post oben nur auf die Umgangsformen bezogen war. Fachlich gefällt mir der Thread gut.


@ gruffi

Wie Complication schon schrieb, Singlethreaded Performance ist das Produkt aus IPC und Takt. Beide Faktoren sollen laut AMD mit Bulldozer gesteigert werden.

War mir schon bewusst, dass da der Takt auch noch dazugehört. Ich habe das nur deshalb auf den IPC-Wert reduziert, weil er bei den momentanen AMD-CPUs schlechter als bei den Intel-Pedants ist. Der Takt hätte ja gereicht (mutmaße ich jetzt einmal kühn^^).

 

[HappyMutant]

Ich habe mal etwas aufgeräumt: https://www.computerbase.de/forum/threads/782875/

Es sei auch diesmal wieder angemerkt, dass weniger das Fachliche selbst das Problem ist, als viel mehr das shreddern des Threads durch den unnötigen Schlagabtausch darüber wer im Grunde zu doof ist, den anderen zu verstehen.

Ich bitte wieder einmal darum, dass unterschiedliche Standpunkte und Sichtweisen von beiden Seiten zu tolerieren sind und speziell um Spekulationen und Formulierungen absolut kein Fass über die Deutungshoheit aufgemacht werden muss. Weiterhin sei euch versichert, dass ihr euch alle regelmäßig irren könnt, also kommt damit klar, dass ihr nicht die einzigen seit, die die Aussage des anderen anzweifeln dürft. Ebenso müsst ihr nicht aus eurer eigenen Unfehlbarkeit heraus jede minimal andere Aussagen direkt als komplett abwegig bezweifeln.

Hier nun zurück zum Thema, wie üblich könnt ihr euch per PN bei mir dazu äußern.

PS. Wie üblich wurde versucht die sonstige Diskussion nicht allzu sehr in Mitleidenschaft zu ziehen, weshalb nicht jeder stehengebliebene Beitrag unbedingt auch einwandfrei sein muss.

PPS. Da es offenbar so ist, dass die ganze Diskussion schon alleine deswegen verkorkst ist weil der eine meinte die Ausführungen seien falsch und der andere damit nicht ums verrecken leben kann und der andere auch sagen muss, dass das nun wieder völlig falsch sei und der erste damit auch nicht leben kann habe ich dann eben alles ab da versenkt.

Pech, dass da nun durchaus interessante und vielleicht auch weiterführende Links flöten gegangen sind, aber solange die beiden Protagonisten nicht vernünftig Kritik üben können oder wenigstens mit ihrer eigenen Medizin leben können, solange muss das dann wohl leider sein. Es spricht ja nichts gegen eine erneute vernünftige Einbindung in den Thread.

 

[Schaffe89]

Nicht wirklich. Es wird dann davon abhängen, wie viele Kerne bzw Module die jeweilige CPU haben wird. Wenn wir mal ein Bulldozer Modul und einen Intel Kern pro Takt gegenüberstellen (beide haben 2 logische Prozessoren):

Was ja auch ein mit Grund dafür gewesen sein könnte, warum man die Bulldozer von 2009 auf 2011 vorschoben hat.

AMD erhöht die Single Thread Performance etwas mehr als die Dual Thread Performance, wegen den 80% des zweiten Kerns, aber das dürfte jetzt eigentlich jeder wissen.

 

[Complication]

Hier gibt es neues von Bobcat auf der IFA:
AMD zeigt den Ontario auf der IFA 2010
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1283637747

Im Einzelgespräch mit John Taylor, dem Produktmanager für die Fusion-Prozessoren, wurde uns nochmals bestätigt, dass die Auslieferung der ersten APU an die Kunden vorzeitig noch im vierten Quartal 2010 erfolgen wird und darauf basierende Produkte sehr früh im ersten Quartal 2011 erhältlich sein sollen. Auf die zweite wesentlich potentere APU „Llano“ werden interessierte Kunden allerdings noch wesentlich länger warten müssen, laut AMD soll der Launch erst spät im zweiten Quartal 2011 erfolgen. Damit ist wohl erst im zweiten Halbjahr mit einer breiten Verfügbarkeit entsprechender Produkte zu rechnen. Wie man uns nochmals bestätigte, wird die Leistungsfähigkeit der x86-Kerne des „Llano“ oberhalb der aktuellen AMD Phenom II liegen.
[...]
Durch die direkte Anbindung an die x86-Kerne auf dem selben Die und dem daraus resultierenden Wegfall des PCIe-Bottlenecks soll die Energieeffizienz enorm gesteigert werden. John Taylor sprach mehrfach von Akkulaufzeiten oberhalb von zehn Stunden. Zu den Fähigkeiten der neuen UVD3-Einheit hielt man sich auch bedeckt, mit ihr soll aber die Beschleunigung weiterer Codecs unterstützt werden.
[...]
Parallel zur Entwicklung der APUs will AMD mit wichtigen Partner-Firmen ein entsprechendes Software-Ökosystem erschaffen, damit Endkunden auch von den neuen Fähigkeiten der Fusion-Prozessoren profitieren können.
[...]
Als zweite Demo wurde das Computerspiel „City of Heroes" gezeigt. Das Spiel lief subjektiv bei stark reduzierten Einstellungen flüssig. In der dritten Demo wurde die APU zur Wiedergabe eines 1080p HD-Videos genutzt, was die integrierte UVD3-Einheit problemlos meisterte. Abschließend durfte das „Ontario“-Testsystem noch ein paar flüssige Folienübergänge berechnen.Die wesentlich anspruchsvolleren Folienübergänge, für die Microsoft PowerPoint 2010 die GPU zur Berechnung nutzt, waren absolut flüssig. Alle Demos sollen in der nativen Auflösung des Displays von 1366 x 768 gelaufen sein. Der kleine Aluminiumkühler auf der APU wurde dabei unter Last gerade handwarm.

Das ganze wie gesagt auf der Netbook APU Ontario:

Der bereits seit einer Weile umhergeisternde Codename „Zacate“ wurde bestätigt. Dabei handelt es sich um die 18 Watt TDP Version des „Ontario“ (9 Watt TDP), die dank höherer Taktfrequenzen eine höhere Performance bieten soll. Mit dem „Zacate“ zielt man auf den unteren Mainstream des Notebook- und Desktop-Marktes. Der „Ontario“ soll dagegen in Netbooks verbaut werden, dabei aber eine höhere Leistung als die aktuellen Atom-Prozessoren von Intel bieten.

Hier ein Vergleich der Die Fotos zwischen Ontario und Atom Dualcore:
Quelle Hans de Vries: http://www.xtremesystems.org/forums/showpost.php?p=4537355&postcount=41

Ergänzung (5. September 2010)

Laut diesem Bericht von dem selben Event:
http://www.hardware-infos.com/news.php?news=3681
Soll es sich allerdings bei dem Testsystem um einen Zacate (18W TDP) handeln.

Zudem verriet uns eine firmennahe Quelle, dass zum Beispiel StarCraft II auch auf mittleren Settings spielbar sein soll.
[...]
Zacate weist, wie bereits erwähnt, eine TDP von 18 Watt auf, der "kleine" Bruder Ontario mit 9 Watt genau die Hälfte. Beide Modelle werden sich weder in der Kernanzahl (Dual-Core) noch im Funktionsumfang unterscheiden, lediglich die Taktraten werden bei Ontario geringer ausfallen.

 

[gruffi]

Was ja auch ein mit Grund dafür gewesen sein könnte, warum man die Bulldozer von 2009 auf 2011 vorschoben hat.

Das hatte vor allem zwei Gründe, 32 nm und SSE5/AVX.

 

[Schaffe89]

Für AVX brauchte man aber die 256bit, deswegen mein Post.
Aber was genau ist denn an AVX nun so bahnbrechend, kann das jemand erläutern?

 

[Complication]

Ich denke besser und ausführlicher kann man es nicht erklären als hier:
http://www.planet3dnow.de/vbulletin/showthread.php?t=362353

2007 - AMDs SSE5
Bereits 2007 präsentierte AMD seine neuen Instruktionen und taufte das durchaus umfangreiche Paket SSE5. Neben Permuatationsbefehlen stechen vor allem die FMA- und Mehroperandenbefehle hervor. Bisher werden nur zwei Operanden (also Variablen) pro Befehl abgearbeitet, nicht mehr. FMA steht für Fused Multipy-Add und bedeutet, dass ein einziger Befehl für eine Kombination aus Addition und Multiplikation angeboten wird, womit Funktion wie A * B + C einfach beschrieben werden können. So etwas ist vor allem im wissenschaftlichen Bereich mit vielen Berechnungen praktisch, weshalb FMA-Befehle im High Performance Bereich (HPC) schon länger genutzt werden. Beispiele für Prozessoren mit Mehroperandenbefehle sind der Itanium und einige Prozessoren der Power-Architektur.
[...]
Intels AVX
Intel zeigt sich von AMDs Vorschlag eher pikiert. Nach der gezwungenermaßen Adaption von AMDs x86_64 Befehlssatz, der im Hause Intel zuerst versteckt IA32e, dann EM64T, mittlerweile aber stolz Intel 64 heißt, hat man sich wohl nach wie vor noch nicht erholt. [4]

Seitdem könnte man den Eindruck gewinnen, dass Intel aus Prinzip keine AMD-Entwicklung mehr adaptiert. So wurde SSE5, wie schon 3DNow!, diesmal erst recht abgelehnt und an etwas Eigenem gebastelt. Das Ergebnis wurde den anwesenden Entwicklern und Reportern auf Intels Hausmesse IDF im Frühjahr 2008 unter dem Namen AVX präsentiert.[5] Also nachdem AMDs SSE5 längst auf Kiel gelegt war und Intel sich hätte anschließen können.

Neidlos muss man anerkennen, dass dabei von Seite Intels wirklich nicht gekleckert, sondern geklotzt wird. Nicht nur, weil Intel die SSE Registergrößen gleich auf 256 Bit verdoppelt und das flexiblere FMA4 anbietet, sondern auch, weil Intel ein cleveres OpCode Schema vorstellte. Dabei werden Codes alter 8/16bit Befehle als Befehlspräfix, genannt VEX, wiederverwendet, die im AMD64-Modus ungültig sind bzw. gestrichen wurden.
Einziger Nachteil dabei ist, dass im virtuellen 8086 Modus kein AVX funktioniert, was aber zu verschmerzen sein sollte.[6]
[...]
Aus AMDs SSE5 wird XOP, FMA4 and CVT16
Nachdem nun der Ball wieder im AMD-Lager war, durfte man auf AMDs Entscheidung gespannt sein. Selbige gab es es nun Anfang Mai. Zuerst wurde klamm und heimlich AMDs Programmierleitfaden für SSE5 aktualisiert. Der Titel wechselte dabei von "AMD64 Technology - 128-Bit SSE5 Instruction Set" [7] in "AMD64 Architecture Programmer’s Manual Volume 6: 128-Bit and 256-Bit XOP, FMA4 and CVT16 Instructions". [8]

Schon am Titel fällt auf: SSE5 ist tot. Liest man weiter im Dokument fällt sofort das neue Befehlsformatschema auf, das Intels AVX entspricht. Sieht man allerdings genauer hin, stellt man fest, dass gelegentlich dann aber doch ein paar Bits unterschiedlich sind. Zum Beispiel gibt es kein VEX-Präfix sondern ein XOP Präfix:

 

[.fF]

Danke, Complication, für das Zusammenstellen der Infos.

 

[Complication]

Hier ist ein weiterer Artikel zu Bobcat auf Planet3DNow zu finden der die Infos sehr schön zusammen fasst:
http://www.planet3dnow.de/vbulletin/showthread.php?t=385065#content_start
Interessante Punkte sind hier z.B. der Cache des Bobcat:

Auf den ersten Blick ist alles vorhanden, was man bei einer state-of-the-art CPU benötigt. Im Vergleich zum K8/K10 fallen die L1 Caches nur halb so groß aus, dafür wurde aber an der Assoziativität geschraubt. Der Datencache ist nun anstatt 2fach, 8fach assoziativ, und entspricht nach einer Daumenregel, somit einem 2fach assoziativen Cache von 128 kbyte. Also ist das eher eine Verbesserung, denn eine Verschlechterung.

Da immer wieder nur die schiere Menge an Cache erwähnt wird, wird es wohl auch bei Bulldozer wichtig sein nicht nur zu schauen wie viel Cache verbaut ist, sondern auch ob dieser Cache ebenfalls 8-fach assoziativ ist.

Auch das Thema "Pipeline" wird dort gut beleuchtet, was ja für diejenigen relevant ist die Wert auf die Einschätzung der IPC legen:

Auffallend beim Bobcat ist die lange L2 Pipeline/Wartezeit im Vergleich zum K8/K10 Design. Das liegt vermutlich daran, dass der L2-Cache, ähnlich wie schon der L3-Zwischenspeicher des K10s, nicht mir vollem Kerntakt betrieben wird. Laut AMD wird er nur mit der Hälfte des Kerntaktes laufen.

Auch die FPU hat hier wohl eine gravierende Umwandlung durchgemacht:

Zweitens fällt bei genauerer Betrachtung die FPU Größe auf. Denn deren Fläche ist verschwindend gering, fast hat man Schwierigkeiten die FPU zu finden. In etwa entspricht sie der Größe des 32kB L1 Caches. Im Vergleich zu alten K8 oder gar K10 Zeiten ein deutlicher Unterschied. In Dresdenboy Blog war einmal eines IEEE Papers zu finden, in dem eine neue FPU beschrieben wird, die in nur 40 Prozent der Fläche der K8 FPU fast die gleiche Leistung bringt und dabei auch noch weit weniger Energie verbraucht. 40 Prozent Fläche käme gut hin. Die Wahrscheinlichkeit ist groß, dass die beschriebene FPU im Bobcat Verwendung findet.

Stromverbrauch Betrachtung im Marktumfeld:

Das untere Marktsegment wird mit den vollintegrierten Bobcat-Kernen neu definiert. Selbst der aktuelle integrierte Pineview-Atom ist in allen Belangen unterlegen. Wenn man den Vergleich auf den ganzen Chip, inklusive ATI-Grafikteil ausweitet, wird der AMD Vorteil eher noch größer ausfallen. Selbst beim Verbrauch liegt Atom nicht vorne. Intel gibt für einen Einzelkern-Pineview mindestens 7 Watt an. Für den Zweikerner fallen schon 15 Watt an [Quelle]. Ontario und Zacata werden sich dagegen zwischen 9 und 18 Watt eingruppieren. Angesichts der deutlich höheren Rechen- und Grafikleistung absolut akzeptabel.

 

[Schaffe89]

Danke an Complication, dass er alles so gut analysiert.

Hat denn Intel schon neue Modelle verlauten lassen, welche als Gegenstück zum Bobcat präsentiert werden?
Oder siehts so aus als würde es beim aktuellen Atom zweikerner bleiben?

 

[Complication]

Der Stromverbrauch-Vergleich ist auf den aktuellen Pineview Atom bezogen - aus dem Artikel:

Selbst der aktuelle integrierte Pineview-Atom ist in allen Belangen unterlegen.

Intel zielt derzeit mit neuen Atoms wie Z600 (Moorestown) wohl auch verstärkt auf den Tablet und Mobilen Sektor, so dass ein direkter Konkurrent zu dem Ontario wohl nicht in 2011 zu erwarten ist. AMD verzichtet ja vollständig auf das Handy Geschäft, was auch zu weniger Kompromissen führt in der Bobcat Architektur. Es war bei Intel wohl auch einer der Hauptgründe auf die in-Order Architektur zu setzen beim Atom um den Handy Sektor mit x86 CPUs zu bedienen.
http://www.heise.de/ct/artikel/Atom-Handys-993734.html

Intels Prozessor Atom Z600 für Smartphones und Tablets

Schon lange will Intel seinen Atom-Prozessor auch in Smartphones und anderen kleinen Mobilgeräten sehen, doch erst die jetzt vorgestellte Z600-Modellreihe ist dafür energieeffizient genug. Dafür musste Intel alte Zöpfe abschneiden – nicht zuletzt die Windows-Kompatibilität.

Aber das ist dann ein anderes Themenfeld -> Smartphones

 

[gruffi]

Für AVX brauchte man aber die 256bit

Nicht unbedingt, siehe Sandy Bridge. Der scheint physisch weiterhin lediglich eine 128-bit FPU zu haben, erreicht einen Durchsatz von 256-bit aber mittels Double Pumping. Gut möglich, dass der originale Bulldozer auch lediglich einen 128-bit FMAC hatte und nicht zwei.


@topic

Also die Kerne bei Bobcat schauen schon verdammt klein aus. Laut Hans de Vries ist ein solcher in 40 nm nicht mal halb so gross wie beim aktuellen Atom (45 nm). Letzter hat zwar SMT, ist aber auch lediglich In Order. Bobcat könnte in Zukunft vielleicht sogar wichtiger werden als Bulldozer. Richtig spannend dürfte der in 28 nm High-K werden.

 

[Complication]

Ich glaube dass der Fertigungsprozess für Bobcat der neue 28nm High Performance Plus (HPP) von Global Foundries sein wird in 2011:
http://www.xbitlabs.com/news/other/...ther_28nm_Fabrication_Process_to_Roadmap.html

The new 28HPP will boost performance of chips compared to the typical 28nm process by 10% and will allow to make chips with 2GHz clock-speed.
[...]
In addition, a rich RF CMOS offering also is available, making the 28nm HPP technology an ideal platform for the next generation of high-performance system-on-chip (SoC) designs with a broad addressable market ranging from low-power to high-performance devices.
[...]
All 28nm technologies feature gate first approach to HKMG, which offers a substantially smaller die size and cost, as well as compatibility with proven design elements and process flows from previous technology nodes.

Bobcat wurde ja schon so designed um problemlos direkt auf 28nm skalieren zu können.

 

[y33H@]

Es gibt gewisse äh Andeutungen in diese Richtung. Könnte also gut sein.