Was kommt (nach den ersten Deneb (K10.5+)) fuer den Desktop bis zum Launch der BD(APUs)?

Ergaenzend moechte man sagen (auch wenn es diesmal wieder kein Desktop CPU ist), warum kein Atom Konkurrent?
Denn wenn diese Prognosen stimmen, darf und kann man als ernsthafter x86 Produzent dieses Segment nicht mehr ignorieren - selbst wenn man sich selbst in das besonders duenne Fleisch bei den Mobil CPUs schneidet.
http://en.wikipedia.org/wiki/AMD_700_chipset_series

AMD hat ja schon heute den M740G in 55nm als Shrink des 690E zur Verfügung.

Spätestens per 'Regor' und teildeaktivierten Cores / Cache wäre ein Alternativ-Design machbar.
Wobei ich mir angesichts der Änderungen bei Intel eine Kombination CPU-DIE zzgl. GPU auf einem Träger erwarte.
 
Aus dem Atom Geschäft sollt sich AMD ruhig raus halten, damit macht selbst Intel kaum Gewinn und die haben die Die extra dafür entwickelt. Das Atom Paket bringt Intel ca. 30$ Umsatz, das ist ein Witz wenn man sieht für wie viel die Endgeräte teilweise angeboten werden. AMD macht das mit Yukon schon ganz richtig. Die Kunden die sich heute Netbooks kaufen werden sich danach meist nach etwas mehr Performance und Features umschauen, und steht Yukon von Leistung und Ausstattung nicht schlecht da. Gut das sehe ich vielleicht auch etwas zu positiv, denn für mich hat Netbook auch keine Daseinsberechtigung zumindest nicht wie sie derzeit angeboten werden.

Zum Silizium: Ich denke AMD wird sich kaum die mühe machen für den Mobilbereich eigen Dies zu entwickeln. Yukon hat mit dem Huron gefilterte K8 Dies und sowas wie den Griffin wird sich AMD auch nicht mehr Leisten müssen wenn Regor raus ist. Der dürft auch bei niedriger TDP genug Leistung habe für den Mobileinsatz da muss man nicht nachschrauben an Befehlssatz und L2 wie mit den derzeitigen Turion Ultra. Ich halte drei native Dies derzeit für gut, mehr brauchts nicht für AMD.

Zum vermeintlichen billig QC Konkurrent Q7900:
Ob es ihn gibt oder nicht kann keiner sagen. Offiziell wurde nichts angekündigt, nur auf der Intel Seite war er kurz zu sehen, aber gleich wieder weg. Das gleiche ein paar Tage später mit einem E8700 der kurz zu sehen war und am nächsten Tag von der Seite verschwunden ist. Scheinbar hat Intel mit den Entlassungen beim Marketing begonnen das sich jetzt auf AMD Niveau befindet :P
 
Zuletzt bearbeitet:
Da die Diskussion recht interessant ist, melde ich mich auch mal wieder. Grüße an alle, die mich noch kennen! :-) Nun möchte ich noch etwas Diskussionsbeitrag liefern, welchen ich schonmal auf WO veröffentlichte, aber dort nicht soviel Anklang fand.

Was ich denke, ist Folgendes:

Es ist schade um den G3-Sockel, aber der G34-Sockel dürfte für AMD günstiger sein. Obwohl laut Patenten wohl schon lange an moderneren Speicheranbindungen gearbeitet wird (a la FB-DIMM), bietet der G34-Sockel die einfache Möglichkeit, zwei 6-Core-CPUs mit je 2 DDR3-Interfaces und 4 HT-Links als Gesamtpackage mit 4 DDR3-Interfaces u. den nicht intern verwendeten HT-Links nach außen zu führen. Das sparte die Weiterentwicklung der G3MX-Controller inkl. aller relevanten Kosten.

Aber was den Core selbst angeht, fand ich auch einige interessante Dinge. Es folgt gleich ein Bild, welches ich aus Abbildungen von Patentanmeldungen AMDs vom letzten Jahr zusammengestellt habe. Es zeigt eine Multicore-Architektur (aktuell waren 4 Cores abgebildet), welche in dieser Form schon mehrfach auftauchte u. in ähnlicher Form schon länger in den Patenten unterwegs ist (z.B. die Funktionseinheiten-Cluster).

Speziell U.S. Patent Application 20080209173 dürfte manchen interessieren. Diese enthält eine etwas ausführlichere Darstellung u. Beschreibung einer exemplarischen CPU mit SMT u. einer interessanten Konfiguration dafür:
  • Teile der Pipeline shared zw. den Threads
  • dazu min. 2 dedizierte Integer-"Cluster" mit eigenen Schedulern, Ausführungseinheiten, Load/Store-Units und L1 Data Caches (!)
  • eine FPU für alle Cluster u. Zugriff auf alle L1 Data Caches u. evtl. auch auf die jeweiligen Load/Store-Units

Das würde die physisch vorhandene Integer-Kapazität sowie Load/Store- und L1-Cache-Bandbreite pro Core nahezu verdoppeln bzw. im SMT-Einsatz deutlich mehr bringen, als die normalerweise schon gut ausgelasteten Integereinheiten noch unter Threads aufzuteilen. Für die FPU ist die Lage etwas anders, da diese nur mit starker (Hand-)Optimierung gut ausgelastet werden kann (und selbst da kann es algorithmenseitig Einschränkungen geben, die die Erreichung hoher Durchsätze behindern), aber bei normalem Compiler-Code weiter vom Optimum entfernt ist als Integer-Einheiten.

Es klingt alles nach dem Versuch, ein ausbalanciertes System zu schaffen. Derzeit sind z.B. Fetch+Decoding "zu gut" für Integer-Code u. gerade ausreichend für SSE-Code. Dazu kommt die oben angesprochene Auslastung usw. Dagegen ändert sich alles außerhalb der Cores von der Architektur her kaum (schon ab dem L2-Cache), wobei dort noch genug Potential vorhanden ist, z.B. Prefetching, bessere Policies bei Cache Misses usw.(dazu sind auch Patent Applications in der Pipe).

Sollte AMD den Bulldozer-Kern so konzipiert haben, sehe ich darin einen potentiellen Vorteil gegenüber Nehalem. Schlecht daran ist, dass diese Cores wohl erst in 2 Jahren zu erwarten sind. Gründe sind uns ja nicht bekannt. Evtl. ist AMD noch nicht soweit.

Oder AVX spielt hier eine Rolle. Da hat Intel kürzlich an den Specs herumgekürzt, siehe Beitrag
http://aceshardware.freeforums.org/intel-avx-kills-amd-sse5-t538-30.html#9509

architektur.png


Viele Grüße
Matthias
 
Da die Diskussion recht interessant ist, melde ich mich auch mal wieder. Grüße an alle, die mich noch kennen! :-) Nun möchte ich noch etwas Diskussionsbeitrag liefern, welchen ich schonmal auf WO veröffentlichte, aber dort nicht soviel Anklang fand.
Hiho, schön wieder was vom Patentefuchs No.1 zu lesen ;)

Es ist schade um den G3-Sockel, aber der G34-Sockel dürfte für AMD günstiger sein. Obwohl laut Patenten wohl schon lange an moderneren Speicheranbindungen gearbeitet wird (a la FB-DIMM), bietet der G34-Sockel die einfache Möglichkeit, zwei 6-Core-CPUs mit je 2 DDR3-Interfaces und 4 HT-Links als Gesamtpackage mit 4 DDR3-Interfaces u. den nicht intern verwendeten HT-Links nach außen zu führen. Das sparte die Weiterentwicklung der G3MX-Controller inkl. aller relevanten Kosten.
Jo stimmt schon, wobei ich mir Sorgen wegen des boardlayouts mache. Gleich 4 DDR3 Kanäle .. Bei FBD gehts ja, das hat ja weniger Leitungen, aber DDR3 ...
Naja vielleicht im Serverbereich egal, ein paar Boardlayers mehr, das interessieren keinen.


Speziell U.S. Patent Application 20080209173 dürfte manchen interessieren. Diese enthält eine etwas ausführlichere Darstellung u. Beschreibung einer exemplarischen CPU mit SMT u. einer interessanten Konfiguration dafür:
  • Teile der Pipeline shared zw. den Threads
  • dazu min. 2 dedizierte Integer-"Cluster" mit eigenen Schedulern, Ausführungseinheiten, Load/Store-Units und L1 Data Caches (!)
  • eine FPU für alle Cluster u. Zugriff auf alle L1 Data Caches u. evtl. auch auf die jeweiligen Load/Store-Units

Das würde die physisch vorhandene Integer-Kapazität sowie Load/Store- und L1-Cache-Bandbreite pro Core nahezu verdoppeln bzw. im SMT-Einsatz deutlich mehr bringen, als die normalerweise schon gut ausgelasteten Integereinheiten noch unter Threads aufzuteilen.
Hmm, interessant .. noch ein Mittelding zw. CMT und SMT, SMT mit extra Clustern.Performacemäßig sicherlich ne gute Idee. Im Vergleich zu Suns Rock kommen mir die dezidierten L1 Caches ziemlich luxuriös vor. Aber bei "nur" 4 Kernen und 32nm muss AMD wohl nicht mit Die Platz geizen.
Abgesehen davon erinnert mich das Design etwas an den Niagara 2, der hat ja ebenfalls 2 extra INT-ALUs:
http://www.realworldtech.com/page.cfm?ArticleID=RWT090406012516&p=2

Aber ein AMD Cluster wird da ja gleich mehrere ALUs haben, da böte sich dann eigentlich "echtes" SMT an, oder sind die aktuellen INT ALUs bei AMD wirklich immer voll ausgelastet ? Allein die eventuellen Wartezeiten aufs RAM lassen die ALUs ja oft ideln.

Es klingt alles nach dem Versuch, ein ausbalanciertes System zu schaffen. Derzeit sind z.B. Fetch+Decoding "zu gut" für Integer-Code u. gerade ausreichend für SSE-Code. Dazu kommt die oben angesprochene Auslastung usw. Dagegen ändert sich alles außerhalb der Cores von der Architektur her kaum (schon ab dem L2-Cache), wobei dort noch genug Potential vorhanden ist, z.B. Prefetching, bessere Policies bei Cache Misses usw.(dazu sind auch Patent Applications in der Pipe).
Jo, das ist halt das immer das "Hilfe für wo am Nötigsten".
Hauptflaschenhals beim K10 ist jetzt INT, die FP Unit mit den 128bit reicht erstmal :)

Oder AVX spielt hier eine Rolle. Da hat Intel kürzlich an den Specs herumgekürzt, siehe Beitrag
http://aceshardware.freeforums.org/intel-avx-kills-amd-sse5-t538-30.html#9509
Hmmm AVX ... glaub ich weniger, eher Fusion :)
Eigentlich muss AMD an der FPU auch nichts mehr großartig verbessern, das machen ab 2011 die ATi Vector/ShaderProzessoren. 2006 wurden da mal R600 Niveau versprochen, also 320 Stück. Aber mit der Verschiebung auf 2011, dem 32nm Prozess und die letzten Design-Schrumpfkuren bei den R7xx Chips wird man eher mit der doppelten Menge rechnen dürfen.

ciao

Alex

P.S: Was ist "WO" ?
 
Zuletzt bearbeitet:
Charlie Demerjian vom Inquirer, der laut eigener Aussage 2006 die ersten Blockdiagramme zum Bulldozer gesehen hat, sagte, diese sahen aus wie ''Niagara auf LSD''. Deshalb denke ich das Dresdenboy hier auf der richtigen Spur ist. Die Decoder des K8 sind auch in Patenten Jahre vor seinem Erscheinen aufgetaucht, das könnte für Bulldozer diesmal auch wieder zutreffen. Desweiteren sagte Fred Weber schon 2005 das er soetwas wie FPU-Sharing purem SMT vorzieht. Dresdenboy, hättest du noch andere Patente interessante Patente?
 
Zuletzt bearbeitet:
Charlie Demerjian vom Inquirer, der laut eigener Aussage 2006 die ersten Blockdiagramme zum Bulldozer gesehen hat, sagte, diese sahen aus wie ''Niagara auf LSD''. Deshalb denke ich das Dresdenboy hier auf der richtigen Spur ist. Die Decoder des K8 sind auch in Patenten Jahre vor seinem Erscheinen aufgetaucht, das könnte für Bulldozer diesmal auch wieder zutreffen. Desweiteren sagte Fred Weber schon 2005 das er soetwas wie FPU-Sharing purem SMT vorzieht. Dresdenboy, hättest du noch andere Patente interessante Patente?
Jo, aber ob das Teil von 2006 schon Bulldozer war, oder weiss wohl keiner.
Fred Weber ist auch schon seit ner halben Ewigkeit nicht mehr bei AMD:
http://www.heise.de/newsticker/Fred-Weber-verlaesst-AMD--/meldung/63710

ciao

Alex
 
Ich denke nicht das AMD alles was damals für den originalen Bulldozer entwickelt wurde, verworfen hat. Fred Weber mag zwar weg sein (*schnieff* leider) doch ich bin mir sich das viele seiner Ideen geblieben sind.
 
Erst mal ein fettes Danke an Drestenboy für den Post. Leider kann ich spätestens jetzt nicht mehr mit reden... dafür reicht meine Wissen aus Rechenarchitekturen1 nicht mehr aus *buck*.
 
Hiho, schön wieder was vom Patentefuchs No.1 zu lesen ;)
Danke! Stürzen wir uns als alte Haudegen gleich mal in die Diskussion ;) Achso, WO ist Wallstreet-Online.

Hmm, interessant .. noch ein Mittelding zw. CMT und SMT, SMT mit extra Clustern.Performacemäßig sicherlich ne gute Idee. Im Vergleich zu Suns Rock kommen mir die dezidierten L1 Caches ziemlich luxuriös vor. Aber bei "nur" 4 Kernen und 32nm muss AMD wohl nicht mit Die Platz geizen.
Abgesehen davon erinnert mich das Design etwas an den Niagara 2, der hat ja ebenfalls 2 extra INT-ALUs:
http://www.realworldtech.com/page.cfm?ArticleID=RWT090406012516&p=2

Aber ein AMD Cluster wird da ja gleich mehrere ALUs haben, da böte sich dann eigentlich "echtes" SMT an, oder sind die aktuellen INT ALUs bei AMD wirklich immer voll ausgelastet ? Allein die eventuellen Wartezeiten aufs RAM lassen die ALUs ja oft ideln.
Ich vermute derzeit 2 ALUs + 2 AGUs (+ 1 IMUL) pro Cluster, da es ähnlich schon in älteren Patenten auftauchte. Vom Multithreading-Standpunkt aus wäre die Verteilung in der Beispielarchitektur (mehr wissen wir ja nicht) etwa so:

shared (MT): L1-I$, Fetch, Decoder, Branch Predictor, FPU
dedicated (ST): I-Scheduler, ALU+AGUs, L1-D$.

Das scheint mir auch ganz sinnvoll für viele Workloads, da bei bisher im x86-Bereich üblichem SMT neben architekturbedingten Engpässen wie z.B. I-Fetch die ganz normalen SMT-Effekte z.B. durch geteilte L1-D$ und Register-File und zuwenig der für jeden Thread wichtige Einheiten wie Load/Store vermieden werden.

Bei schlecht prefetchten Speicherzugriffen können auch die Integer-Einheiten des K10 schwach ausgelastet sein, was auch einen SMT-Ansatz ohne Cluster rechtfertigen würde. Aber hier handelt es sich wohl um ein Trade Off zwischen max. verfügbaren Einheiten für einen Thread u. der Gesamtzahl für mehrere Threads unter dem Aspekt der Energieeffizienz.

Hmmm AVX ... glaub ich weniger, eher Fusion :)
Eigentlich muss AMD an der FPU auch nichts mehr großartig verbessern, das machen ab 2011 die ATi Vector/ShaderProzessoren. 2006 wurden da mal R600 Niveau versprochen, also 320 Stück. Aber mit der Verschiebung auf 2011, dem 32nm Prozess und die letzten Design-Schrumpfkuren bei den R7xx Chips wird man eher mit der doppelten Menge rechnen dürfen.
Fusion ist natürlich auch möglich, ebenso die gewünschte Wirtschaftlichkeit der derzeitigen 45nm-Produkte bzgl. Entwicklung und Produktion. Angeblich waren es ja die Kunden, die die Verschiebung wünschten.
 
shared (MT): L1-I$, Fetch, Decoder, Branch Predictor, FPU
dedicated (ST): I-Scheduler, ALU+AGUs, L1-D$.

Das scheint mir auch ganz sinnvoll für viele Workloads, da bei bisher im x86-Bereich üblichem SMT neben architekturbedingten Engpässen wie z.B. I-Fetch die ganz normalen SMT-Effekte z.B. durch geteilte L1-D$ und Register-File und zuwenig der für jeden Thread wichtige Einheiten wie Load/Store vermieden werden.
Jo die load/store Einheiten wären dann wohl auch doppelt. Interessant wäre dann, welchen Cluster die FPU nutzt, oder ob die vielleicht sogar beide gleichzeitig nutzen könnte *suspect*

Bei schlecht prefetchten Speicherzugriffen können auch die Integer-Einheiten des K10 schwach ausgelastet sein, was auch einen SMT-Ansatz ohne Cluster rechtfertigen würde. Aber hier handelt es sich wohl um ein Trade Off zwischen max. verfügbaren Einheiten für einen Thread u. der Gesamtzahl für mehrere Threads unter dem Aspekt der Energieeffizienz.
Jo höchstwahrscheinlich. AMD geht es wohl nachwievor um single-thread Leistung / IPC. Verwundert mich dann doch einwenig, den SMT bringt ja v.a. in (Web)servern die Mehrleistung, und bisher war ja immer die Server/Opteronleistung Designkriterium No.1. Aber gut, vielleicht bringt es bei OOO CPUs vielleicht dann auch nicht mehr soviel wie bei Suns/IBMs InOrdern Ansätzen :)
Fusion ist natürlich auch möglich, ebenso die gewünschte Wirtschaftlichkeit der derzeitigen 45nm-Produkte bzgl. Entwicklung und Produktion. Angeblich waren es ja die Kunden, die die Verschiebung wünschten.
Ja auch gut möglich, dass AMD ersteimal die Lust an großen Monster Dies mit dem K10 65nm Fiasko vergangen ist und Bulldozer deswegen auf 32nm wartet :)

Mal was Andres .. so ein Design mit nem einzelnen Kern, wäre doch auch ein guter Mobilprozessor, oder ? Bobcat geistert ja auch noch im Hintergrund herum.

Edit:
@Woerns:
Die Leakagepatente, die ich kenne stammen eigentlich alle von Transmeta, haben sowohl Intel als auch AMD lizenziert. Such mal unter LongRun/LongRun2.

ciao

Alex
 
Zuletzt bearbeitet:
@Matthias
Es gibt auf wo durchaus Teilnehmer, die Deinen Beitrag wertgeschätzt haben. :)

Allerdings ist Deine Patentrecherche unter der Rubrik "Was kommt nach Deneb" besser aufgehoben als dort, wo man den Thread inzwischen nur mit langer Ignoreliste aushält.

Mich interessiert neben der Architektur der Logik auch, ob es Patente seitens AMD oder Intel gibt, die sich speziell auf das Beherrschen der Leakage beziehen, also auf das Ein- und Abschalten ganzer Logikbereiche. Intel hat verlautbaren lassen, dass der Nehalem quasi um solche Stromsparfeatures "herumdesignt" worden ist.

Wie die meisten hier vielleicht wissen, hat der Anteil statischer Leakage mit jedem Fertigungsnode weiter zugenommen. Er hat bereits bei 65nm den Anteil dynamischer Leakage übertroffen und dominiert unter 45nm weitgehend. Darin sehe ich auch den Grund, dass der Phenom II jetzt wieder höher taktbar ist. Denn ich vermute, dass der Phenom von Anfang an ein 45nm Design war, in dem das Beherrschen der statischen Leakage Priorität hatte. Der 65nm Vorgänger hatte daher absehbare Kinderkrankheiten (ich will hier nicht auf TLB- und andere -Bugs hinaus), und die dynamische Leakage ist mit steigendem Takt aus dem Ruder gelaufen.

Unter 32nm geht der Trend in gleicher Richtung weiter, insofern halte ich es für interessant, ob die notwendigen Designentscheidungen durch Patente abgesichert oder eben behindert sind. MfG
 
Aber was den Core selbst angeht, fand ich auch einige interessante Dinge.
Es folgt gleich ein Bild, welches ich aus Abbildungen von Patentanmeldungen AMDs vom letzten Jahr zusammengestellt habe. Es zeigt eine Multicore-Architektur (aktuell waren 4 Cores abgebildet), welche in dieser Form schon mehrfach auftauchte u. in ähnlicher Form schon länger in den Patenten unterwegs ist (z.B. die Funktionseinheiten-Cluster).

Speziell U.S. Patent Application 20080209173 dürfte manchen interessieren.
Das ist ein hochinteressantes Design.

AMD könnte gut 1/2 bis 2/3 der eh vorhandenen Hardwares eines Cores recyclen und die Performance wäre bei Integer praktisch gleichwertig zu Dual-Core.
Bei FPU zwar lahmer, aber vieler CPUs nutzen die FPU ja selten.

Auch im Mainstream wäre je per Integration der 'APU' die FPU nur noch eine Wahl für die Optimierung von Berechnungen.

Obiges Design würde sich auch als low power Pseudo-Single-Core gut machen.
Auch als Integer-Quad = 2* physikalisch den Core integriert.
Wenn man die Roadmap http://www.tomshardware.com/de/fotostrecken/AMD-Client-Proz-Roadmap-200,0101-168095-0----jpg-.html für 2011 mal wohlwollend so betrachtet könnte der 'Liano' ein Quad-Interger / FPU-Dual / GPU / APU Design mit 2* 512k L2 und 3M-L3 werden.
 
hallo matthias,

willkommen retour. wieder mal ein lichtblick in diesem forum, hoffe du bleibst uns länger erhalten
 
Jo die load/store Einheiten wären dann wohl auch doppelt. Interessant wäre dann, welchen Cluster die FPU nutzt, oder ob die vielleicht sogar beide gleichzeitig nutzen könnte *suspect*
Tja, eine shared FPU geisterte hier ja schon herum.

Jo höchstwahrscheinlich. AMD geht es wohl nachwievor um single-thread Leistung / IPC. Verwundert mich dann doch einwenig, den SMT bringt ja v.a. in (Web)servern die Mehrleistung, und bisher war ja immer die Server/Opteronleistung Designkriterium No.1. Aber gut, vielleicht bringt es bei OOO CPUs vielleicht dann auch nicht mehr soviel wie bei Suns/IBMs InOrdern Ansätzen :)
Sofern aber die Integer-Einheiten wie z.B. in Patent 7315935 (über ein vereinfachtes Registerfile mit Port Arbitration) nur noch 2 ALUs + 2 AGUs enthalten, wäre für einen Thread pro Cluster zumindest von einer niedrigeren Single Thread Performance der CPU auszugehen. Dass beide Cluster für einen Thread genutzt werden, sehe ich gar nicht. Mit vielen dieser kleinen Integer Cores können einige typische Server-Apps erschlagen werden.

BTW, das vereinfachte Registerfile u. der Cluster böten einige Vorteile (für viel Spaß mit Trade Offs):
niedrigerer Energieverbrauch pro Instruction und höhere Taktbarkeit.

Wie war das nochmal.. es gab auch schon im Web die Meldung einer shared FPU mit halbem Takt... *suspect*

Mal was Andres .. so ein Design mit nem einzelnen Kern, wäre doch auch ein guter Mobilprozessor, oder ? Bobcat geistert ja auch noch im Hintergrund herum.
Klar, das wäre möglich oder gleich der Verzicht auf Mobile Low Power Quadcore mit Favorisierung von Dual Cores mit dem hybriden CMT/SMT für 4 mögliche Threads.
 
Sofern aber die Integer-Einheiten wie z.B. in Patent 7315935 (über ein vereinfachtes Registerfile mit Port Arbitration) nur noch 2 ALUs + 2 AGUs enthalten, wäre für einen Thread pro Cluster zumindest von einer niedrigeren Single Thread Performance der CPU auszugehen.
Ah stimmt ja, die aktuellen K10 haben ja je 3 .. jo dann bin ich noch ein größerer Fan von der Idee .. macht Sinn :)
Das ist dann quasi 2x 2fach superskalar vs. 1x3fach superskalar. Nachdem das Optimum schon immer bei 2 lag, sicher eine gute Wahl. Einzig der shared Decoder steht noch im Weg, der müßte dann eigentlich auch noch auf 4fach aufgebohrt werden, oder ? Oder halt 2x2, aber dann wäre er nicht shared *noahnung*
Naja eigentlich egal, Hauptsache es kommen pro Takt 4 mOps raus.
Dass beide Cluster für einen Thread genutzt werden, sehe ich gar nicht.
Ich auch nicht, da hab ich mich wohl irgendwo mißverständlich ausgedrückt :)
Mit vielen dieser kleinen Integer Cores können einige typische Server-Apps erschlagen werden.
Ja, da stimme ich auch zu, der Nachteil, dass keine 3 INT Instruktionen auf einmal durchkommen, sollten 2x2 sicherlich aufwiegen.

Wie war das nochmal.. es gab auch schon im Web die Meldung einer shared FPU mit halbem Takt... *suspect*
Hmm, hab ich leider nicht gesehen, hast Du zufällig nen Link zur Hand ? Kann mich bei dem Thema nur an die frühen Cyrix / VIA CPUs erinnern :)
Klar, das wäre möglich oder gleich der Verzicht auf Mobile Low Power Quadcore mit Favorisierung von Dual Cores mit dem hybriden CMT/SMT für 4 mögliche Threads.
Stimmt, der Ontario(=Bobcat+GPU) steht ja sowieso als dual core in der Liste.

ciao

Alex
 
Zuletzt bearbeitet:
@Dresdenboy

Schön wieder von dir hier zu lesen, zumal deine Spekulationen immer auf interessanten Hintergründen basieren.
Das von dir aufgezeigte Design wäre durchaus möglich und schaut für multithreaded Anwendungen sehr interessant aus. Für Singlethreaded würde es wohl weniger bringen. Da AMD sich ja in letzter Zeit eher auf den Servermarkt konzentriert wäre dies jedoch gut möglich.
Richtig interessant wäre es jedoch, wenn die beiden Integercluster auch von einem thread als 4x1 genutzt werden könnten. Bliebe nur die Frage wie das zu realisieren wäre.
Soetwas würde evtl. auch die Antihyperthreadinggerüchte von damals erklären können. *tief ausgrab*
 
Tja, eine shared FPU geisterte hier ja schon herum. ...
Nun ja ... Sun führte mit dem Niagara 1 ja einen Octacore ein, deren 8 Kerne sich gemeinsam eine FPU teilen.

nigara-1_funktionsbloecke_grob.jpg
Quelle

Der kommende Rock kennt ja auch gemeinsam genutzte FPUs.
sun_rock_rock-einzelcluster.jpg
Quelle Dort sind 4 Quadcore-Cluster (-> 16 Kerne + 8 FPUs) dann im Chip drin.

Die Idee von 2x 2fach superskalar vs. 1x3fach superskalar ist interessant. Suns Rock hingegen soll 4 fach scalar ausgelegt sein (wie schon der UltraSPARC III).

IBM kennt auch die gemeinsame Nutzung von mehreren Kernen mit Funktionseinheiten. Dort kennt der Power6 und z10 gemeinsam genutzte DFP-Einheiten.
... niedrigerer Energieverbrauch pro Instruction und höhere Taktbarkeit ...
äh ... auch hier erinnert mich das an den Power6. Dort verzichtete IBM auf eine gesteigerte IPC und setzte bauf ein "schlanken" Power6-Design. Der gesteigerte Takt sollte die geringere Rechenleistung dann wieder kompensieren (nanu ... das war doch auch schon Intels Hoffnung beim Pentium 4).

Um den Bogen zum potenziellen K10/K10,5 Nachfolger zu spannen -
Ich denke, dass AMD den neuen Instruktionsset vom Larrabee AVT nutzen wird. Ich frage mich aber auch, wie AMD dies alles unter einem Hut bringen will, wenn womöglich auch noch SMD-Einheiten von einer ATI-GPU integriert werden.
Deine Forschungsarbeit zeigt da interessante Ansätze bei AMD.

MFG Bobo(2009)

PS: Ach ja, schön wieder von dir zu hören Dresdenboy ;)
.
EDIT :
.

... Mich interessiert neben der Architektur der Logik auch, ob es Patente seitens AMD oder Intel gibt, die sich speziell auf das Beherrschen der Leakage beziehen, also auf das Ein- und Abschalten ganzer Logikbereiche. Intel hat verlautbaren lassen, dass der Nehalem quasi um solche Stromsparfeatures "herumdesignt" worden ist.

Wie die meisten hier vielleicht wissen, hat der Anteil statischer Leakage mit jedem Fertigungsnode weiter zugenommen.

Unter 32nm geht der Trend in gleicher Richtung weiter, insofern halte ich es für interessant, ob die notwendigen Designentscheidungen durch Patente abgesichert oder eben behindert sind. MfG
Ich kann das mit Bestimmtheit nicht sagen.

Betrachtet man AMDs Beteiligung an Transmeta und die Übereinkunft von beiden Prozessorschmieden und berücksichtigt noch Intels Agreement und beendete Patentschlacht zwischen beiden Firmen ... dann haben beide Firmen die gleichen Antworten auf Leckströme.

Long Run und Long Run 2 waren neben Codemorphing die Patent-Trumpfkarten von Transmeta ... bevor sie vor kurzem als CPU-Designhaus ins Nirwana verschwanden.

MFG Bobo(2009)
 
Zuletzt bearbeitet:
Was mir auf den bisher veröffentlichten "roadmap"-folien auffällt ist, dass offenbar zwischen dem 31.12.2010 und dem 01.01.2011 sowohl die Fertigung von 45nm auf 32nm umgestellt als auch auf eine neue Mikroarchitektur gewechselt werden soll. Bisher ging ich von der Annahme aus, dass so ein gleichzeitiger Wechsel ein absolutes NoNo darstellt, und wahrscheinlich sehen dies auch AMD-Ingenieure so. Was also kommt zuerst: der "Deneb" in 32nm oder der "Bulldozer - oder wie er auch immer heissen wird" in 45nm?
 
Das würde mich wundern. irgendwas muss AMD in 2009-2010 machen. da wird mindestens eine neue Fertigungstechnik eingeführt.

Wenn sie Architektur und Fertigungsprozess gleichzeitig wechseln, dann bekommen sie ein wiederholtes k10 Debakel.
 
Bisher ging ich von der Annahme aus, dass so ein gleichzeitiger Wechsel ein absolutes NoNo darstellt, und wahrscheinlich sehen dies auch AMD-Ingenieure so. Was also kommt zuerst: der "Deneb" in 32nm oder der "Bulldozer - oder wie er auch immer heissen wird" in 45nm?
Die werden das so wie beim K10 machen, Produktion zuerstmal im alten, vorhandenen Prozeß, d.h. 45nm.
Der Unterschied ist jetzt nur, dass sie die 45nm Bulldozer nicht verkaufen werden, da war das K10 Fiasko wohl eine harte Lehre.
Deneb in 32nm wäre eigentlich auch "nett", wieso nicht ... aber auf der Roadmap sieht man (bisher) halt nichts davon *noahnung* .

ciao

Alex
 
Sofern aber die Integer-Einheiten wie z.B. in Patent 7315935 (über ein vereinfachtes Registerfile mit Port Arbitration) nur noch 2 ALUs + 2 AGUs enthalten, wäre für einen Thread pro Cluster zumindest von einer niedrigeren Single Thread Performance der CPU auszugehen. Dass beide Cluster für einen Thread genutzt werden, sehe ich gar nicht.
Mit vielen dieser kleinen Integer Cores können einige typische Server-Apps erschlagen werden.
...

Klar, das wäre möglich oder gleich der Verzicht auf Mobile Low Power Quadcore mit Favorisierung von Dual Cores mit dem hybriden CMT/SMT für 4 mögliche Threads.
Sowohl für Server, Mobilbereich als auch typ. Desktop/ Office Quad-Nutzung wäre ein solches Design effektiver als nur 4* Cores zu bauen.

Im Vergleich zum Nehalem mit 256k-L2 und SMT wäre ein solcher Doppel-Core mit bleibenden 512k-L2 ausreichend üppig ausgestattet. Und der gemeinsame 3M-L3 (Spekulation = 2* 512k-L2 zzgl. 3M-L3 shared = 4M-Cache der Folien) würde in 32nm eher kompakter als der heutige 45nm Propus mit 4* K10.5 à 512k-L2 ausfallen.


Auch die sonstige Anbindung 'System Interface' wäre gut recyclbar:

Aktuell: 4 bzw.6 Cores angebunden zzgl. shared L3 und Memory/ HT
Möglich: 2 Doppelcore zzgl. 1* APU zzgl. 1* GPU zzgl. shared L3 und Memory/ HT
Oder: 3-6* Doppelcore zzgl. shared L3 und Memory/ HT
 
Das würde mich wundern. irgendwas muss AMD in 2009-2010 machen. da wird mindestens eine neue Fertigungstechnik eingeführt.

Wenn sie Architektur und Fertigungsprozess gleichzeitig wechseln, dann bekommen sie ein wiederholtes k10 Debakel.

2010 wird mit Sicherheit 32nm starten. Frage bleibt mit welcher Architektur.
Vermutlich wie Intel bei 45nm, also Architektur- und Fertigungsprozesswechsel.
 
2010 wird mit Sicherheit 32nm starten. Frage bleibt mit welcher Architektur.
Kann ich Dir sagen, mit ner R9xx in bulk 32nm ;D
file.php

Das sind zumindest die ersten 32nm Chips.
32nm SOI soll dann nach dem Bildchen spätestens Mitte 2010 fertig sein. Die einzigen Chips, die man vermuten könnte, wären Opterons. Das sind nämlich die einzigen CPUs, die auf der Roadmap, auf der 32nm *Chips* erst für 2011 angekündigt sind, nicht verzeichnet sind:
file.php


Wäre eventuell logisch, wenn man dran denkt, das AMD 2010 die zusammengepappten Opterons mit 8 und 12 Kernen bringen will.
Edit:
Blöderweise steht bei denen aber noch explizit "45nm" dabei:
http://www.planet3dnow.de/photoplog/file.php?n=2945&w=o
Fazit: *noahnung*

ciao

Alex
 
Zuletzt bearbeitet:
An 12-Kerner glaube ich ehrlichgesagt nicht. Das werden ganz normale 6-Kerner für Server sein. Einen so riesigen Sockel braucht man für kleine Systeme einfach nicht, das macht keinen Sinn. Und Opterons verkaufen sich oft eher in kleineren Systemen und 4-Sockel-Systeme sind im Gegensatz zur Intel-Architektur sehr günstig herstellen, wenn die CPU recht energieeffizient ist (was sie ja ist). Der G34 ist mMn ein reines Hirngespinst, vielleicht um die Analysten zu beeindrucken - das Teil macht markttechnisch überhaupt keinen Sinn. Man braucht einen recht kleinen, DDR3 tauglichen Sockel, vielleicht noch G3MX für die grösseren Modelle, das wars.
Das CMT-Konzept ist sehr interessant. Vielleicht war es wirklich für die 45nm-Generation vorgesehen, aber damit fährt man wahrscheinlich mit heutiger Desktop-Software eher schlechtere Ergebnisse ein. Im Serverbereich könnte er das Nehalem-Problem haben: Zuviel Hitzeentwicklung. Kein Wunder, dass man ihn auf 32nm verschoben hat. Vielleicht hatte man bis dahin einfach kein Desktop-Konzept und deshalb war die Roadmap noch leer. Ich denke mal, dass 2010 Sao-Paulo (als K10 Rev.D) ebenfalls für Deskop kommt und Shanghai/Deneb/Istanbul ablösen wird. Währenddessen wird schon fleißig an der 32nm-Bulldozer-Servereinführung für Q3 2010 gearbeitet und 2011 kommt dann die Desktop-Variante Orochi.
Orochi würde dann sinnigerweise aus 4 CMT-Kernen bestehen, das wäre für die Zeit der absolut perfekte High-End-Prozessor.
 
Zuletzt bearbeitet:
An 12-Kerner glaube ich ehrlichgesagt nicht. Das werden ganz normale 6-Kerner für Server sein.
Mag ja sein, aber solange die bei AMD auf der Liste stehen kann mans nicht wegdiskutieren.
Ich denke mal, dass 2010 Sao-Paulo (als K10 Rev.D) ebenfalls für Deskop kommt und Shanghai/Deneb/Istanbul ablösen wird. Währenddessen wird schon fleißig an der 32nm-Bulldozer-Servereinführung für Q3 2010 gearbeitet und 2011 kommt dann die Desktop-Variante Orochi.

Also Sao Paulo sehe ich nur als Istanbul im Socket G34, so wie jetzt Shanghai / Deneb.

ciao

Alex
 
Zurück
Oben Unten