Was kommt (nach den ersten Deneb (K10.5+)) fuer den Desktop bis zum Launch der BD(APUs)?
- Ersteller TNT
- Erstellt am
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
A. Stiller über Bulldozer:
Für 32nm hätt ich mir schon mehr erwartet ... naja mal schauen ... vielleicht gibts dafür umso mehr Register ^^
ciao
Alex
http://www.heise.de/ct/artikel/Prozessorgefluester-862083.html
Für 32nm hätt ich mir schon mehr erwartet ... naja mal schauen ... vielleicht gibts dafür umso mehr Register ^^
ciao
Alex
Dr@
Grand Admiral Special
zu viel BSN gelesen?
(alle K10 haben einen 128 bit FPU, keine Ahnung wovon der gute Mann da spricht)
Außerdem hatte JF ja von zusammen nutzbaren FPU Pipes gesprochen.
nur 8 kB L1 kann ich mir nicht vorstellen
Zuletzt bearbeitet:
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
und über "Hypervisor strauchelt und mit Clock Watchdog Timeout" ... das ist ja gar nicht gut für den Nehalem mit seinem APIC-Timer und seinen Interrupts ...
und wenn die Hypervisor vom Windows Server 2008 R2 damit strauchelt und virtualisierte Umgebungen einfrieren ... hat AMD womöglich ein unverhofftes "Camp for free" bei ServerVirtualsierungen bekommen - Jedenfalls bei Windows Server 2008 R2-Server. Da hat der Betreiber die Wahl zum Bugfixing zwischen Turbo Boost, oder Virtualisierung, ob das Intel so beabsichtigt hatte? Ob da wirklich die Zusammenarbeit zwischen Intel und Microsoft gut abgestimmt war?
Und meine Vermutung zum Patentabkommen beider x86-Player wurde auf den Punkt nochmals von Stiller bestätigt:
Schön schön
Zu den kleinen L1-Caches des Bulldozer kommt mir in den Sinn, dass da wohl rattenschnelle Level-1 Caches zu erwarten sind. Zusammen mit einer trace-cacheartigen Unterstützung, vielen Clustern und schnelleren vierfachen HyperTransport-Interconnects kommt das der Ursprungsidee eines schnellen Windhund-Multicores (Greyhound) sehr nahe.
Oder wie eine Hydra mit vielen (schnellen) Schlangenköpfen, die jederzeit auf der Jagt nach Threads ist und sofort zubeisst und nach dem nächsten (Thread)Opfer Ausschau hält ... PS: Warum kommt mir dabei nun auch noch der zurückgezogene Rock von Sun in den Sinn?
Nun ja, Alpha startete mit dem EV 7 ja von Anfang an mit 4 schnellen System-Interconnects und sollte mit einer rattenschnellen Vektorerweiterung im EV 8+ (Tarantula) ... und im vorher im EV 8 mit SMT-Betrieb weiter zulegen.
Dagegen wirkt der K10 wie schwerer zu lange gelagerter Rotwein ... nun ja, genugt geschwelgt.
MFG Bobo(2009)
Zuletzt bearbeitet:
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Jo, der letzte Punkt ist wohl das Verständnisproblem, was der gute Meister Stiller nicht weiss, dass die zwei 128bit Einheiten zusammen einen 256bit Befehl entgegennehmen können. Prinzipiell hat er ja recht, die 256bit werden zerlegt, aber der Unterschied zu früher ist halt, dass die Teile dann gleichzeitig bearbeitet werden und nicht nacheinander. Interessant wirds, wenn beide Threads 256bit Ops liefern .. was dann wohl passiert
Naja wohl ne Warteschlange, was auch sonst ...
[Barcelona ist aber natürlich falsch, das waren die K8, die das machten, da hast Du absolut recht
]Wohl eher nicht ^^
Jo, also da bin ich ja mal gespannt, wie lange es dauert bis intelUnd meine Vermutung zum Patentabkommen beider x86-Player wurde auf den Punkt nochmals von Stiller bestätigt: Schön schön
Hm ja die Idee hat was, eine andere Sache, die Glew im aktuellen google Thread schrieb, war die, dass die Cluster sich die L1 Caches schnell hin und herkopieren können ... das gind mit mickrigen 8kB sicherlich schnell.
Auf der anderen Seite könnte die Info aber auch von einer Fehlinterpretation herrühren und mit 8 kB könnte die Größe des L0/Trace Cache gemeint sein, da gabs ja schon früher die Gerüchte, dass Sandy Bridge ~16kB Trace Cache bekommt:
http://citavia.blog.de/2009/10/02/return-of-the-trace-cache-or-trace-cache-done-right-7084490/
Würde prima passen, SB hat 16 kB für 2 Threads, Bulldozer hätte 2x8 für 2 Threads
Wieder fällt das Problem vom Hyperthreading auf ... würde mich nicht wundern wenn sich die die µOps aus beidem Threads bei den aktullem Nehalems jeweils aus dem Cache kicken. Naja, mal schauen, wie das dann mit 16kB läuft
Oder wie eine Hydra mit vielen (schnellen) Schlangenköpfen, die jederzeit auf der Jagt nach Threads ist und sofort zubeisst und nach dem nächsten (Thread)Opfer Ausschau hält ... Hydra ist der aktuelle (interne) Codename des 6Kern Dies, aufpassen
Wenn Du noch mehr und größere Schlangenköpfe willst, brauchst Du Orochi. Da das dann Drachenköpfe sind spucken die vermutlich sogar Feuer
Jo K10 war halt der kolportierte K8+, nicht mehr, nicht weniger. Tarantula bekommen wir hoffentlich in ~5 Jahren in Form eines voll-fusionierten Bulldozer - GPU APUs.Nun ja, Alpha startete mit dem EV 7 ja von Anfang an mit 4 schnellen System-Interconnects und sollte mit einer rattenschnellen Vektorerweiterung im EV 8+ (Tarantula) ... und im vorher im EV 8 mit SMT-Betrieb weiter zulegen.
Dagegen wirkt der K10 wie schwerer zu lange gelagerter Rotwein ... nun ja, genugt geschwelgt.
Ich schrieb ja bereits mal früher, dass DECs Erfindungen nach ca. 10 Jahren "Lagerzeit" im x86 Markt auftauchen .. da wäre um 2015 ein guter Richtwert
Eventuell hat AMD wg. Fusion mit dem Compilerbauen angefangen, wenn sie voll-fusionieren, müssen sie die x86 Befehle um die ATi Instruktionen erweitern. Im Moment bleibt ja alles beim alten, und die GPU wird als PCIe Device angesprochen, aber das ist nur der erste Schritt:
http://arstechnica.com/hardware/new...tm_source=rss&utm_medium=rss&utm_campaign=rss
ciao
Alex
Zuletzt bearbeitet:
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Im Grunde genommen ist es mir Wurst, ob nun kleiner, oder grosser L1-Cache. Ich kann mir halt vorstellen dass ein (gemeinsamer) 0-Cache ungemein beschleunigend sein kann.
Einerseits das, aber ich wollte auch nicht Hydra sagen, sondern Medusa ... auch schön schrecklich schön
MFG Bobo(2009)
* = Der Titel ist geklaut. Es gab einen Film gleichen Namens mit Lino Ventura (Kommissar Brunel) und Richard Burton (John Morlar)
Na dann hoffe ich mal dass Medusa die Threads nicht versteinert!
gemeinsamer L0? - was hätte das für einen sinn? - dann hätten wir das selbe Problem wie bei nehalem dass sich die traces gegenseitig rauskegeln... wenn schon L1-caches geteilt sind, dann doch die trace-caches bitteschön auch.
gemeinsamer L0? - was hätte das für einen sinn? - dann hätten wir das selbe Problem wie bei nehalem dass sich die traces gegenseitig rauskegeln... wenn schon L1-caches geteilt sind, dann doch die trace-caches bitteschön auch.
Dresdenboy
Redaktion
☆☆☆☆☆☆
Jaa, ich hab das Paper gefunden, was die FMAC-Einheiten beschreibt. Später mehr.. Es werden nicht einfach FMAC-Einheiten sein, wie man sie kennt (also 1 FMA oder 1 MUL oder 1 ADD pro Takt und Unit).
BTW, 2 L1 I-Caches per BD-Modul laut Johan de Gelas.
BTW, 2 L1 I-Caches per BD-Modul laut Johan de Gelas.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Ist ja gemein ... Forumsbeitrag mit Cliffhanger
Hmmm weiss er was, oder spekuliert er nur ? Bisher waren die Patente ja recht zutreffend.
Aber gut, wenn AMD wirklich 4 INT Pipes pro Core hat hat, dann bräuchten sie den shared L1I Cache nicht ...
Sicherlich im Bereich des Möglichen..
ciao
Alex
Dr@
Grand Admiral Special
Das "AMD64 Programmer's Manual volume 6: 128-Bit and 256-Bit XOP and FMA4 Instructions" wurde aktualisiert!
MfG @
MfG @
Dresdenboy
Redaktion
☆☆☆☆☆☆
Ist ja gemein ... Forumsbeitrag mit Cliffhanger
Lang genug gezappelt - mein FMAC-Artikel ist draußen:
http://citavia.blog.de/
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
.. und das auch noch ohne Werbeblock und "Sponsored by" Meldung ^^
Thx
Sieht alles ganz gut aus. Kleinigkeit, die ich nicht kapiere ist Dein Satz hier:
Ist natürlich richtig, aber Fusion wäre trotzdem nett, denn dessen Hauptvorteil ist ja, dass man damit das Front-end entlastet. Anstatt 2 MacroOps gingen bei Fusion nur 1 MacroOp durch die ganzen Piplinestufen ... ist schon ganz nett - Frage ist nur nur, ob die aktuellen 08/15 Programmcodes den Aufwand rechtfertigen würden.
Ansonsten noch was zu Deinen angenommenen zwei 128bit FMAC "Pipelines":
AMD schreibt nirgends, dass das wirklich Piplines wären .. ich hab das von Anfang an als 128bit MacroOps gelesen
ciao
Alex
U
User002
Guest
Gibts mittlerweile auch paar neue Infos zum Thuban 6 Kerner? releasetermine, fertigungsverfahren, Taktungen, etc? Für Server gibts ja schon länger 6 Kerne, frag mich halt warum man beim Desktop so lange warten muss..
Grüße!
Grüße!
Dresdenboy
Redaktion
☆☆☆☆☆☆
Cool, wenn schon Leute von Dreamworks mein Blog lesen ^^ Aber ich diskutiere ja noch lieber über den Inhalt. Also los..
Bei den Bildchen könnte auch etwas Verschleierungstaktik dahinterstecken. Jedoch hat AMD ja schon die Interlagos-Balken gezeigt. Nur könnte es bei Intel nun auch ein wenig dämmern.
AMD hat schließlich ein 2-Thread-Bulldozer-Modul, welches in etwa einem Intel-Kern entsprechen wird. Darin versteckt sich mehr FP-Leistung, mehr Int-Leistung, hoffentlich auch mehr kombinierte L1-D$-Bandbreite usw. Die 8 kB L1 könnten ein Indikator dafür sein, dass die Caches in anderen Aspekten sehr gut sind (Latenz, Durchsatz, Hit-Under-Miss) - oder alles einfach höher taktbar ist....
Kurze Rückrechnung:
Wenn Interlagos mit 16 Kernen/8 Modulen in der gleichen ACP/TDP wie Magny Cours oder Istanbul angesiedelt ist (mehr will man ja nicht tun), dann wird es für den Desktop noch interessant. Schließlich schafft Interlagos grob 100% der Int-Kern-Leistung vom Magny Cours u. etwa 125% der FP-Leistung pro Kern. Das mit 16 Kernen verglichen zu 12. Für den Desktop wird das erstens schon wegen weniger Kernen/Modulen deutlich anders aussehen und zweitens könnten die neuen Powermanagement-Features (noch ist ja nix offiziell) ganz ordentliche Game- oder typ. Desktop-App-Performance liefern.
Edit: Johan@Anandtech hat noch ein paar allgemeinere Dinge zum BD zusammengefasst: http://it.anandtech.com/IT/showdoc.aspx?i=3681
Die Frage ist, ob 4-issue auch gesagt werden würde, wenn das auch 2 MacroOps entspricht. MacroOp war bisher ja immer ExOp+MemOp (Abkürzungen frei gewählt). Aber oft gibt es auch voneinander abhängige FMULs u. FADDs, die man nicht fusionieren könnte, weil z.B. jeweils ein MemOperand dabei ist. Auch kann es Fälle geben, wo das FMUL-Ergebnis noch von einer weiteren Operation konsumiert wird. Klar wäre das Handling einer FMAC-MacroOp einfacher, aber die Opportunities könnten seltener sein. Der Scheduler wäre dann ja immer darauf angewiesen, für einen Takt FMUL+FADD frei zu haben.
FMACroOp?Ansonsten noch was zu Deinen angenommenen zwei 128bit FMAC "Pipelines":
AMD schreibt nirgends, dass das wirklich Piplines wären .. ich hab das von Anfang an als 128bit MacroOps gelesen
Bei den Bildchen könnte auch etwas Verschleierungstaktik dahinterstecken. Jedoch hat AMD ja schon die Interlagos-Balken gezeigt. Nur könnte es bei Intel nun auch ein wenig dämmern.AMD hat schließlich ein 2-Thread-Bulldozer-Modul, welches in etwa einem Intel-Kern entsprechen wird. Darin versteckt sich mehr FP-Leistung, mehr Int-Leistung, hoffentlich auch mehr kombinierte L1-D$-Bandbreite usw. Die 8 kB L1 könnten ein Indikator dafür sein, dass die Caches in anderen Aspekten sehr gut sind (Latenz, Durchsatz, Hit-Under-Miss) - oder alles einfach höher taktbar ist....
Kurze Rückrechnung:
Wenn Interlagos mit 16 Kernen/8 Modulen in der gleichen ACP/TDP wie Magny Cours oder Istanbul angesiedelt ist (mehr will man ja nicht tun), dann wird es für den Desktop noch interessant. Schließlich schafft Interlagos grob 100% der Int-Kern-Leistung vom Magny Cours u. etwa 125% der FP-Leistung pro Kern. Das mit 16 Kernen verglichen zu 12. Für den Desktop wird das erstens schon wegen weniger Kernen/Modulen deutlich anders aussehen und zweitens könnten die neuen Powermanagement-Features (noch ist ja nix offiziell) ganz ordentliche Game- oder typ. Desktop-App-Performance liefern.
Edit: Johan@Anandtech hat noch ein paar allgemeinere Dinge zum BD zusammengefasst: http://it.anandtech.com/IT/showdoc.aspx?i=3681
Zuletzt bearbeitet:
1. Eine entscheidende Frage für den Desktop ist die Singel Core Leistung. Es gibt immern noch viele Anwendungen, die auf einen (oder zwei) Kern laufen und da ist die wichtige Frage:
Werden die 2 INT- Kerne an einem Thread arbeiten können? Ich denke nicht und so weit ich das beurteilen kann ist somit die SingelCore Leistung (deutlich) niedriger als beim K10.
2. Wie wird das BS unterscheiden können ob beide "virtuellen" Kerne ausgeastet sind?
Also eine schlechtere Auslasung, wie z.B. bei Intel wenn 2 Prozesse die auf einem Kern mit HT statt auf 2 Kernen arbeiten. Schließlich sind ja nicht alle Einheiten doppelt vorhanden.
Seit Windows 7 soll ja angeblich zwischen echten und Virtuellen unterscheiden werden können. Fakten/Benches habe ich bisher zu dem Thema noch nicht gesehen.
Wieso das denn? Jeder einzelne INT-Core hat nun 4 statt 3 ALUs und damit theoretisch eine höhere Leistung. Die gemeinsam genutzten Teile sind nicht unbedingt performance-kritisch. Der gemeinsame L2-Cache ist für reine single-threaded Anwendungen von Nachteil, für Tasks mit 2 Threads dagegen sollte er besser sein, denn es entfällt der Umweg über den langsameren L3-Cache.
Das sich 2 Threads in die Haare bekommen ist eher unwahrscheinlich, denn AMD hat im Vergleich zu Intels HT sehr viel mehr repliziert. Das einzige kritischen Punkte sind eigentlich der L2-Cache und die FPU. Wobei die FPU sich im Falle von 128Bit Ops problemlos teilen lässt. Für den L2-Cache hingegen ist es vorteilhaft, wenn 2 Threads des gleichen Tasks zusammen auf einem Modul gescheduled werden um die Vorteile des gemeinsamen L2-Caches auszunutzen. Ich weiß nicht wie es bei Windows ist, aber als ich letztes Jahr für meine Studienarbeit den Linux-Scheduler erweitert habe war die Unterstützung von verschiedenen CPU Topologien (echte/virtuelle Kerne, UMA/NUMA, ...) enthalten.
![[MTB]JackTheRipper](/data/avatars/m/1/1018.jpg?1596828194){kind=avatar}
[MTB]JackTheRipper
Grand Admiral Special
Wie wird dann eigentlich die Zuteilung der Threads auf die "CPUs" ablaufen. Bisher regelt das ja das Betriebssystem. Entweder muss es dann für BD "Patches" geben, die das ganze für BD effektiver regeln, oder aber das wird von BD intern gemacht.
Ist dazu schon was bekannt, oder lieg ich jetzt komplett auf dem Holzweg?
Ist dazu schon was bekannt, oder lieg ich jetzt komplett auf dem Holzweg?
1. Wir reden über das jahr 2011. Wenn da noch ein Performancekritisches Programm singlethreaded geschrieben ist, ist es ganz einfach schund.
2. Wo ist eigentlich das Problem mit der aktuellen Singlethread-Leistung? - Wo außer in Benches merkt man überhaupt was davon? - Also welches rein auf einem einzigen Thread basierende Programm, bei dem es auf millisekunden in der Ausführung ankommt, soll das bitte sein?
Es glaubt doch nicht ernsthaft igendwer dass im normalen Büroalltag ein moderner 3Ghz Quadcore zum Flaschenhals wird!?
3. Ist BD primär auf den Serverbereich ausgelegt (sieht man daran dass er zuerst dort eingeführt wird) und dort sind Single-Threaded workloads alles andere als die REgel.
4. AMD weiß sehr wohl was sie tun. Sie haben alles dupliziert was wirklich kritisch in der Performance sien könnte und nicht übermäßig transistoren kostet. Und wir wissen noch nicht welche weiteren "tricks" wie Trace-Cache oder "eager execution" uns evtl. erwarten.
5. Das BS sieht ein BD-Modul ganz einfach als Dualcore-Prozessor. Dass die zwei kerne sich Ressourcen teilen kann dem OS erstmal wurscht sein. MS wird auch bestimmt per Servicepack o.ä. den Scheduler der Server-Windows erweitern wenn sich das lohnt.
6. Man weiß noch nichts über taktraten und Stromverbrauch. Wenn das Ding am ende derart gut optmiert ist dass man 50% mehr davon auf ein DIE kriegt ohne mehr strom zu verbrauchen freut das auch die Desktop-User. Von Aspekten wie Kosten etc. mal garnicht zu reden.
Niemand darf einen "wunderchip" erwarten. AMD plant einfach knallhart und sucht den besten (effizientesten) Kompromiss in Sachen Performance, Kosten und Energie.
Wen nich das richtig verstanden habe, wird ein einzelnes BD-Modul 180% der Leistung eines K8-Kerns bringen (gegenüber theoretischen 200% bei Dualcore-K8, also zwei vollen kernen) und dabei nur 105% des platzes auf dem DIE verbrauchen. D.h. für 5% mehr Fläche ggn .einem Singlecore kriegen wir fast die doppelte Performance... optmierter gehts gar nicht mehr.
Mag zwar alles schrecklich übertrieben sein, aber wir leben nicht mehr 1998...
Im jahre 2011 wird man mit Fug und Recht behaupten können dass abseits der Low-Power schiene (und dafür ist Bobcat da) ein Singlecore keinen Sinn mehr macht. Also kann man getrost den Dualcore durchoptmieren um kosten & strom zu sparen und trotzdem in 80% der fälle gut zu performen.
Nichts anderes ist BD.
Grüßchen
ich
.
EDIT :
.
Threadaufteilung ist eine Frage der Programmierung. und die Threads auf Kerne zu verteilen ist Aufgabe des Schedulers im OS.
Wie soll das denn "intern" gemacht werden? für die CPU ist alles nur maschinencode, woher soll die CPU denn wissen an welchem Thread sie grade arbeitet?
Abgesehen davon versteh ich die Frage nicht... wie läuft das denn mit aktuellen Dualcores?
2. Wo ist eigentlich das Problem mit der aktuellen Singlethread-Leistung? - Wo außer in Benches merkt man überhaupt was davon? - Also welches rein auf einem einzigen Thread basierende Programm, bei dem es auf millisekunden in der Ausführung ankommt, soll das bitte sein?
Es glaubt doch nicht ernsthaft igendwer dass im normalen Büroalltag ein moderner 3Ghz Quadcore zum Flaschenhals wird!?
3. Ist BD primär auf den Serverbereich ausgelegt (sieht man daran dass er zuerst dort eingeführt wird) und dort sind Single-Threaded workloads alles andere als die REgel.
4. AMD weiß sehr wohl was sie tun. Sie haben alles dupliziert was wirklich kritisch in der Performance sien könnte und nicht übermäßig transistoren kostet. Und wir wissen noch nicht welche weiteren "tricks" wie Trace-Cache oder "eager execution" uns evtl. erwarten.
5. Das BS sieht ein BD-Modul ganz einfach als Dualcore-Prozessor. Dass die zwei kerne sich Ressourcen teilen kann dem OS erstmal wurscht sein. MS wird auch bestimmt per Servicepack o.ä. den Scheduler der Server-Windows erweitern wenn sich das lohnt.
6. Man weiß noch nichts über taktraten und Stromverbrauch. Wenn das Ding am ende derart gut optmiert ist dass man 50% mehr davon auf ein DIE kriegt ohne mehr strom zu verbrauchen freut das auch die Desktop-User. Von Aspekten wie Kosten etc. mal garnicht zu reden.
Niemand darf einen "wunderchip" erwarten. AMD plant einfach knallhart und sucht den besten (effizientesten) Kompromiss in Sachen Performance, Kosten und Energie.
Wen nich das richtig verstanden habe, wird ein einzelnes BD-Modul 180% der Leistung eines K8-Kerns bringen (gegenüber theoretischen 200% bei Dualcore-K8, also zwei vollen kernen) und dabei nur 105% des platzes auf dem DIE verbrauchen. D.h. für 5% mehr Fläche ggn .einem Singlecore kriegen wir fast die doppelte Performance... optmierter gehts gar nicht mehr.
Mag zwar alles schrecklich übertrieben sein, aber wir leben nicht mehr 1998...
Im jahre 2011 wird man mit Fug und Recht behaupten können dass abseits der Low-Power schiene (und dafür ist Bobcat da) ein Singlecore keinen Sinn mehr macht. Also kann man getrost den Dualcore durchoptmieren um kosten & strom zu sparen und trotzdem in 80% der fälle gut zu performen.
Nichts anderes ist BD.
Grüßchen
ich
.
EDIT :
.
[MTB]JackTheRipper;4084191 schrieb:
Threadaufteilung ist eine Frage der Programmierung. und die Threads auf Kerne zu verteilen ist Aufgabe des Schedulers im OS.
Wie soll das denn "intern" gemacht werden? für die CPU ist alles nur maschinencode, woher soll die CPU denn wissen an welchem Thread sie grade arbeitet?
Abgesehen davon versteh ich die Frage nicht... wie läuft das denn mit aktuellen Dualcores?
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Bei 2 L1I Caches nicht. Limit64 hat aber recht, die einzelnen Kerne werden nicht gerade langsamer. Möglich dass AMD das Design im Vergleich zu den Patenten vereinfach hat. Anstatt 2x2 INT Pipes die per scout Threads und Eager Execution zusammenarbeiten, einfach 2x4 ... nach dem Motto Viel hilft viel und ist einfacher.
Ist am Anfang erst mal egal. Prinzipiell ist alles doppelt, nur mit 2 256bit AVX Befehlen könnte es eng werden. Verglichen mit Hyperthreading eine Kleinigkeit.
Da gibts schon ein paar Spielenbenches in den Foren, bringt was.
@[MTB]JackTheRipper
Das geht so wie bei Hyperthreading, das OS sieht 2 Kerne=Threads pro Modul und kümmert sich nicht groß weiter darum ..
ciao
Alex
Ich glaube viele hier machen den Denkfehler BDs Struktur mit den 2 Int-Cores als AMDs Antwort auf Hyperthreading zu sehen...
Spätestens mit den getrennten L1-I-Caches passt diese Betrachtung aber nicht mehr.
Ein BD-Modul ist ein zusammgengedampfter Dualcore bei dem einfach ausgedrückt alles "überflüssig"-Doppelte weggelassen wurde. Das erfordert einige Kompromisse, ist aber Platz- und Kosteneffizient.
2x256Bit AVX-Befehle dürften auch im Jahr 2011 noch eher die Ausnahme als die Regel sein. INT-Code dominiert zu über 80% in realer Software, also ist es nur logisch diesen Teil am stärksten aufzubohren bzw. hier nur das nötigste zu "sharen" und so viel direkte Rechenpower wie möglich pro Thread zu haben. bei den paar % FP-Code geschweige denn 256-Bit FP-Code, wird die FPU sich die meiste Zeit zu Tode langweilen.
Also, weg vom "HT-Gedanken", hin zu "Schneller Dualcore auf so wenig Die-Space wie möglich".
Übrigens vergessen wir hier eines:
BD ist kein Kern, sodnern eien Mikroarchitektur. D.h. AMD wird wohl an dem Design weiterentwickeln. Orochi bzw. Zambezi wird nur die erste Generation dieser Prozzis werden. Niemand hindert AMD daran 2012 oder 2013 die FPU zu verbreitern, wenn sie Sinn darin sehen bzw. die Software das entsprechend nutzt. Man kann von der allerersten Inkarnation eines neuen Ansatzes in einer Mikroarchitektur wohl kaum Perfektion erwarten...
Spätestens mit den getrennten L1-I-Caches passt diese Betrachtung aber nicht mehr.
Ein BD-Modul ist ein zusammgengedampfter Dualcore bei dem einfach ausgedrückt alles "überflüssig"-Doppelte weggelassen wurde. Das erfordert einige Kompromisse, ist aber Platz- und Kosteneffizient.
2x256Bit AVX-Befehle dürften auch im Jahr 2011 noch eher die Ausnahme als die Regel sein. INT-Code dominiert zu über 80% in realer Software, also ist es nur logisch diesen Teil am stärksten aufzubohren bzw. hier nur das nötigste zu "sharen" und so viel direkte Rechenpower wie möglich pro Thread zu haben. bei den paar % FP-Code geschweige denn 256-Bit FP-Code, wird die FPU sich die meiste Zeit zu Tode langweilen.
Also, weg vom "HT-Gedanken", hin zu "Schneller Dualcore auf so wenig Die-Space wie möglich".
Übrigens vergessen wir hier eines:
BD ist kein Kern, sodnern eien Mikroarchitektur. D.h. AMD wird wohl an dem Design weiterentwickeln. Orochi bzw. Zambezi wird nur die erste Generation dieser Prozzis werden. Niemand hindert AMD daran 2012 oder 2013 die FPU zu verbreitern, wenn sie Sinn darin sehen bzw. die Software das entsprechend nutzt. Man kann von der allerersten Inkarnation eines neuen Ansatzes in einer Mikroarchitektur wohl kaum Perfektion erwarten...
Zuletzt bearbeitet:
[MTB]JackTheRipper
Grand Admiral Special
Mir geht's eben um die neue Architektur von BD. Da kann es eventuell sinnvoller sein Thread1 von Programm1 in einem anderen BD-Modul laufen zu lassen als Thread2 davon, wenn beide volle FP Performanz benötigen. Die restlichen zwei "CPUs" der beiden BD-Module könnten dann mit SP Threads gefüllt werden.
Bleibt halt die Frage was performanter ist, wenn zwischen diesen Threads die Daten über den Cache synchonisiert werden müssen.
Insofern wäre ein intelligenter Scheduler, der dieses Verhalten analysiert und dann dementsprechend die Threads verteilt angebracht.
Das war die Idee hinter meinem Post.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Also die gleiche Idee wie bbott, da gilt dann die gleiche Antwort:[MTB]JackTheRipper;4084236 schrieb:
AVX256 Befehle werden die ersten 1-2 Jahre superselten sein, in der Zeit wird MS dann schon nen Scheduler Patch rausbringen. Im besten Fall funktioniert vielleicht sogar der Win7 Scheduler der eigentlich für Intels HTh gedacht war.
Aber wie besagt, verglichen mit Hyperthreading sind die Nachteile sehr sehr begrenzt, eben auf den Fall von 2x 256bit AVX.
Jo, ums genauer zu sagen der x86 Dekoder ... das Ding ist mittlerweile ziemlich platzfressend. Am besten ist der Vergleich bei Intels Atom vs. ARM Kerne. Atoms x86 Dekoder braucht da soviel Platz wie ein kompletter ARM Kern
ciao
Alex
Zuletzt bearbeitet:
Sagte ich das nicht schon ganz zu Anfang meiner Aktivitäten hier?
Das ist ein Grund warum RISC-Designs platztechnisch effizineter wären. Man hat eingach wesentlich mehr raum für Ausführungseinheiten zur Verfügung wenn man sich die komplizierten Decoder spart...
Aber wir haben nunmal historisch bedingt x86 und das werden wir auch so schnell nicht los.
Sogesehen ist AMDs Ansatz nur zu begrüßen, diese "Platzverschwendung" wenigstens nur einmal für 2 Cores zu betreiben.
Übrigens ist der Vergleich mit ARM dahingehend lustich, dass ARM ja auch nicht grade das !aufgeräumteste" Instruction-Set hat, wenn man Erweiterungen wie THUMB etc. dazurechnet...
aber egal. ist OT hier im Thread
Wenn ich mir das so überlege, nach dem es nun doch getrennte Instruction-Caches gibt, scheint das einzige was sich beide "kerne" definitiv teilen die Dekoderstufe zu sein. FPU brauchen sie ja nicht immer....
Zudem zu den 256Bit AVX...
doof ist es halt, dass ein einziger 265Bit-AVX-Befehl die FPU komplett zunagelt, sodass Thread2 dann gar keine FPU-Operationen mehr ausführen kann für ein paar Takte.
Aber naja, irgendwoher muss die Ersparnis ja kommen.
Bei bisherigem 64 und 128Bit FPU-Code dürften sich beide Threads jedenfalls kaum in die Quere kommen... also ne ziemlich effiziente Sache.
Wenn sichs dann 2013 lohnt kann AMD immernoch die FPU auf 2x256Bit erweitern... aber vielleicht wird bis dahin FPU-Arbeit auch auf die GPU ausgelagert
grüßchen
ich
Das ist ein Grund warum RISC-Designs platztechnisch effizineter wären. Man hat eingach wesentlich mehr raum für Ausführungseinheiten zur Verfügung wenn man sich die komplizierten Decoder spart...
Aber wir haben nunmal historisch bedingt x86 und das werden wir auch so schnell nicht los.
Sogesehen ist AMDs Ansatz nur zu begrüßen, diese "Platzverschwendung" wenigstens nur einmal für 2 Cores zu betreiben.
Übrigens ist der Vergleich mit ARM dahingehend lustich, dass ARM ja auch nicht grade das !aufgeräumteste" Instruction-Set hat, wenn man Erweiterungen wie THUMB etc. dazurechnet...
aber egal. ist OT hier im Thread
Wenn ich mir das so überlege, nach dem es nun doch getrennte Instruction-Caches gibt, scheint das einzige was sich beide "kerne" definitiv teilen die Dekoderstufe zu sein. FPU brauchen sie ja nicht immer....
Zudem zu den 256Bit AVX...
doof ist es halt, dass ein einziger 265Bit-AVX-Befehl die FPU komplett zunagelt, sodass Thread2 dann gar keine FPU-Operationen mehr ausführen kann für ein paar Takte.
Aber naja, irgendwoher muss die Ersparnis ja kommen.
Bei bisherigem 64 und 128Bit FPU-Code dürften sich beide Threads jedenfalls kaum in die Quere kommen... also ne ziemlich effiziente Sache.
Wenn sichs dann 2013 lohnt kann AMD immernoch die FPU auf 2x256Bit erweitern... aber vielleicht wird bis dahin FPU-Arbeit auch auf die GPU ausgelagert
grüßchen
ich
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Wahrscheinlich ist selbst dass nicht so wild, gibt ja den Scheduler vor den Piplines, das ist ne Warteschlange, in der sich die OPs sowieso einordnen. 1-2 Takte Wartezeit sind da nichts, selbst ein L1 Transfer dauert ja 3 Takte ...
Noch zum L1I cache, hier wird der Grund genannt:
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137076&start=50#p172070
Bei dem Thema fällt mir ein .. wird die Sprungvorhersageeinheit dann auch von beiden Threads gemeinsam genützt ? Oder gibts 2 ? Die ist ja mittlerweile auch recht komplex.
ciao
Alex
.
EDIT :
.
Ja was haben wir denn da:
http://www.isscc.org/isscc/2010/ISSCCAP2010.pdf
[STRIKE]Nachdem Bobcat in 40nm kommt, muss das fast Bulldozer sein. Wobei dann wieder mal die Frage aufkommen muss, was "Core" da sein soll ... wahrscheinlich meinen die Ingenieure da das, was das Marketing "Modul" nennt
Wobei ~10mm2 wären dann etwas wenig, oder ?[/STRIKE]
Edit: Ist ein K10 Kern, die werden ja im Llano eingebaut werden. Mehr siehe unten.
eetimes hat noch ein bisschen mehr Info:
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=221900830
Stromsparen hört sich dann eigentlich doch eher nach Bobcat an ... naja mal abwarten. Wenn die 8 kB L1 stimmen würden, wäre 8T Zellen, da wohl auch kein (Platz)Problem.
ciao
Alex
Zuletzt bearbeitet:
Ähnliche Themen
