Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD - AMDs Bulldozer - neue CPU-Architektur für Q2 2011
DarkFox
2010-08-28, 22:41:46
Der User w0mbat hat schon lauffähige Bulldozer Systeme gesehen
[...]
bezog sich noch auf den 45nm Protoypen mit SSE5...
Ich würde sowas ja sehr gerne glauben, aber der liebe w0mbat hat schon sehr oft die tollsten Daten vor Produktstarts verbreitet, die nachher sagen wir mal zweifelhaft waren.
Abwarten was wirklich dabei rauskommt. Wenn sie wider Erwarten nicht doch noch bei der IPC aufholen, wird BD im Gamer-Bereich imo ne ziemliche Krücke werden.
Bulldozer kann keine krücke werden, 50% schneller als Thuban wird er garantiert, am ende können es durch hohe Taktraten auch 100% sein.
dargo
2010-08-28, 22:51:49
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 einen x4 965 antraten und haushoch (also mehr als 7x so schnell) gewannen."
Ach was, er war 15x schneller. ;D
Sorkalm
2010-08-28, 22:57:55
Ach was, er war 15x schneller. ;D
Null Problem, einfach eine Befehlserweiterung nutzen die Deneb nicht kann.
dargo
2010-08-28, 23:13:40
Null Problem, einfach eine Befehlserweiterung nutzen die Deneb nicht kann.
Hab ich mir schon gedacht. Das wird hier aber kaum jemanden interessieren. Für den Großteil wird eh die IPC bei Spielen relevant sein.
wasn hier los?
Die CPUs von Intel & AMD sind fast gleichwertig, AMD taktet die Modelle einfach höher und verkauft Sie günstiger als Intel.
X4 965 oder i5-750, ganz klar den X4 965 weil günstiger und gleiche Leistung
Intel verdient 10x so viel Geld wie AMD, ist aber bei den top Modellen nur 20-30% schneller im Gesamt Rating laut CB, eine Firma die 1/10 von Intels Gewinn macht ist fast immer gleichauf mit Intel, das ist für Intel peinlich, wartet erstmal bis Intels Architektur an ihre grenzen kommt, eine neue Architektur dauert 5 Jahre ohne optimierung, AMD hat hier einen vorteil ein Design für die nächsten 10 Jahre zu nutzen, Intel wird in 2-3 Jahren die P6 Basis verlassen müssen.
Das, was w0mbat angeblich erlebt hat, hat er hier doch EXAKT so schonmal geschrieben (war es vielleicht sogar der selbe Text?). Dass ihm mal irgendwer angeblich ein noch nicht erschienenes System vorgeführt hätte und dass es megaschnell war, dass man dadrauf nicht nach belieben Programme ausführen konnte etc. Nur dass es jetzt auf einmal "Module" statt "Kerne" sind, das hat sich geändert.
Warum sollte AMD irgendeiner fremden Person 2 Jahre vor Release (er spricht im Text von Silvester) ein Prototyp-System vorführen? Das ist völlig abwegig. Sowas unterliegt einer enormen Geheimhaltungsstufe. Nicht mal jeder Werksangehörige hat einfach so Zugriff auf derlei Informationen, vor allem nicht ohne vorher irgendwelche Nichtveröffentlichungsklauseln zu unterzeichnen.
Ronny145
2010-08-29, 05:28:36
Natürlich ist das hanebüchen. Keine Ahnung wie man das nur im entferntesten ernst nehmen kann.
Singlethread performance ist seit Conroe klar Intel Domäne. Daran wird auch Bulldozer nichts ändern wenn ich tippen müsste. Hervorgehoben wurde zuletzt besonders die multi threading Fähigkeiten, kann man als Indiz werten. Kann mir vorstellen, dass Bulldozer multithreaded gut abgeht, speziell im Server Bereich. Wunder erwarte ich erstmal nicht. Vor K10 und K10.5 wurden die Erwartungen auch viel zu hoch angesetzt bei AMD Anhängern. Die neue Architektur ist da auch erstmal keine Garantie für.
robbitop
2010-08-29, 09:20:37
Immerhin gibt es nun seit 1999 erstmals wieder eine neue Architektur. ;)
K10 war ja nur ein leicht aufgebohrter K8 - war doch klar, dass da nicht viel mehr IPC bei rum kommt.
Leonidas
2010-08-29, 09:59:52
Das ist teilweise etwas schwierig, daß so gegeneinanderzustellen, da man gewisse Besonderheiten noch dazuschreiben müßte.
Thx für die Korrekturen.
BlackBirdSR
2010-08-29, 13:00:57
Thx für die Korrekturen.
Liste doch bitte nochmal komplett auf, oder sind die News schon fertig?
Leonidas
2010-08-29, 14:08:48
Jetzt isses in den News, siehe da.
Der kleine L1 Cache bei BD deutet auf hohe Taktraten hin, bei P3DNow hat Dresdenboy ein komment verlinkt der zeigt das BD 30% höhere Taktraten bei gleicher spannung & TDP als den K8L @45nm Phenom2 takten kann, damit will ich sagen das Zambezi ende 2011 mit 4,0-4,5 Ghz takten kann.
http://www.amdzone.com/phpbb3/viewtopic.php?p=187937#p187937
|" The existing execution units of a high-performance processor are augmented by tile addition of a supplemental integer execution unit, termed the Add/Move Unit (AMU)(+), which performs select adds and moves in parallel and out-of-order with respect to the other execution units. At small incremental cost, AMU enables better use of the expensive limited resources of an existing (+)Address Preparation unit (AP), which handles linear and physical address generation for memory operand references, control transfers, and page crosses. AMU removes data dependencies and thereby increases the available instruction level parallelism. The increased instruction level parallelism is readily exploited by the processor's ability to perform out-of-order and speculative execution, and performance is enhanced as a result. " |
keine Nachteile gegenüber K10 Design
nochmal bestätigte JF-AMD das die IPC höher als aktuell sein wird
http://www.semiaccurate.com/forums/showthread.php?p=63029#post63029
Klar, aber um wieviel? 1%? ;D
Leonidas
2010-08-29, 15:53:30
Der kleine L1 Cache bei BD deutet auf hohe Taktraten hin, bei P3DNow hat Dresdenboy ein komment verlinkt der zeigt das BD 30% höhere Taktraten bei gleicher spannung & TDP als den K8L @45nm Phenom2 takten kann, damit will ich sagen das Zambezi ende 2011 mit 4,0-4,5 Ghz takten kann.
Problematisch ist daran nur, daß Intel im QuadCore-Bereich auch problemlos 3.8 GHz bieten könnte, wenn man nur wollte - und das unter 45nm. Ich sage nicht, daß Sandy Bridge unter 32nm mit diesen Taktraten geplant ist - aber Intel könnte auch locker 4 GHz und mehr mit Sandy Bridge bringen, wenn man will oder wenn man gezwungen wird.
Hvoralek
2010-08-29, 15:56:23
Na, um so besser. Vielleicht nicht für AMD, aber für die Kunden.
Intel kann keine 3,8Ghz bei vollen Kernen anbieten, Sandy Bridge kann nur einzelne Cores bis 3,8 Ghz takten, aber nicht auf allen Cores, genau hier hat Intel ein großes Problem, Intel nutzt seit 45nm HighK um höherere Taktraten zu nutzen, bei AMD kommt HighK erst ab 32nm zum einsatz, hier ist AMD ganz klar im vorteil, dann kommt noch lowK das schon bei thuban zum einsatz kommt, 50% mehr Cores bei gleicher TDP, Intel kann im 32nm Prozess keine vorteile mehr mitbringen, ist alles schon ausgenutzt.
Konami
2010-08-29, 16:26:03
Intel kann keine 3,8Ghz bei vollen Kernen anbieten, Sandy Bridge kann nur einzelne Cores bis 3,8 Ghz takten, aber nicht auf allen Cores, [...]
Natürlich. Intel schleppt schon seit dem C2D ein riesiges Taktpotenzial mit sich rum, das nur deshalb nicht ausgeschöpft wird, weil AMD z.Z. aus dem letzten Loch pfeift.
Sieht man doch ganz klar an den "serienmäßig" sehr guten Übertaktungsoptionen (auch ohne ausgefallene Kühlung).
DeadMeat
2010-08-29, 16:57:35
Natürlich. Intel schleppt schon seit dem C2D ein riesiges Taktpotenzial mit sich rum, das nur deshalb nicht ausgeschöpft wird, weil AMD z.Z. aus dem letzten Loch pfeift.
Sieht man doch ganz klar an den "serienmäßig" sehr guten Übertaktungsoptionen (auch ohne ausgefallene Kühlung).
Ich würd aber auch gern mal sehen auf welche TDP die ganzen 3,8-4ghz Nehalems und Core2s kommen.
Niemand will 140w CPUs. Wobei ich da auch nicht ganz auf dem laufenden bin was die Vcore erhöhungen im schnitt angeht.
Konami
2010-08-29, 17:23:30
Ich würd aber auch gern mal sehen auf welche TDP die ganzen 3,8-4ghz Nehalems und Core2s kommen.
Niemand will 140w CPUs. Wobei ich da auch nicht ganz auf dem laufenden bin was die Vcore erhöhungen im schnitt angeht.
Die bis ans Maximum aufgepumpten Nehalems haben natürlich eine hohe Verlustleistung, aber ~25% mehr Takt sind eigentlich immer ohne Spannungserhöhung drin. Seit Jahren. Leonidas hat schon Recht, wenn er sagt, dass Intel locker mit >4-GHz-SNBs kontern könnte, sollte Bulldozer sie in Bedrängnis bringen.
Und die aktuellen Top-Phenoms haben auch eine TDP von 125W. Werden trotzdem gekauft.
Deswegen wage ich nur eine Prognose: Es wird spannend. ;)
(Wer war eigentlich der Scherzkeks-Gast? X-D)
Ronny145
2010-08-29, 17:36:49
Mit Turbo sind es ja schon 3,8 Ghz. 3,4 Ghz sind dennoch ordentlich, ist ja auch nur die Mainstream Plattform. Aber auch bei dieser dürfte Intel früher oder später noch taktmäßig nachlegen. Bis Bulldozer muss Intel aber eigentlich nicht handeln. Wenn man den anandtech Test als Maßstab nimmt, kommt Sandy Bridge dort mit 10% mehr IPC daher, mit Turbo Modus berücksichtigt vielleicht 15%. Mit der erhöhten Frequenz sind wir bei mindestens 20% oder gar 25% zu Lynnfield.
DeadMeat
2010-08-29, 18:00:18
Mit Turbo sind es ja schon 3,8 Ghz. 3,4 Ghz sind dennoch ordentlich, ist ja auch nur die Mainstream Plattform. Aber auch bei dieser dürfte Intel früher oder später noch taktmäßig nachlegen. Bis Bulldozer muss Intel aber eigentlich nicht handeln. Wenn man den anandtech Test als Maßstab nimmt, kommt Sandy Bridge dort mit 10% mehr IPC daher, mit Turbo Modus berücksichtigt vielleicht 15%. Mit der erhöhten Frequenz sind wir bei mindestens 20% oder gar 25% zu Lynnfield.
Stimmt beim Bulldozer geht es in erster Linie darum ob man zu Intel aufschliessen kann. Manche spekulieren schon nen bissl zu weit ;>
Bulldozer wird mit 8 Integer Cores sowieso schneller als ein Gulftown und wird weniger als die hälfte kosten.
BD muss aber nicht gegen Westmere antreten, sondern gegen Sandy Bridge.
mus er doch
Sandy Bridge kommt erstmal nur mit 4 Cores, ein gulftown ist schneller als ein Quad Core Sandy Bridge und ein Bulldozer wird schneller als eine Quad Core Sandy Bridge sein.
Ronny145
2010-08-29, 18:44:24
mus er doch
Sandy Bridge kommt erstmal nur mit 4 Cores, ein gulftown ist schneller als ein Quad Core Sandy Bridge und ein Bulldozer wird schneller als eine Quad Core Sandy Bridge sein.
Sandy Bridge kommt auch mit 6 und 8 Kernen. Intel kann problemlos nachlegen wenn sie müssen. Aber erstmal muss überhaupt Bulldozer mal auf den Markt kommen. Ein konkreteres Datum außer 2011 gibt es nicht.
Klar, aber um wieviel? 1%? ;D
Naja, wahrscheinlich mindestens 5-10%
Wäre ja peinlich wenn ein Llano bei Single-Threaded Apps plötzlich schneller wäre als ein BD, oder? ;)
Psychopat
2010-08-29, 18:50:12
Was der Gast meinte: Bulldozer kommt vor den 6 + 8 Kern Sandys auf den Markt (die kommen erst 2H 2011). Zum Launch von Bulldozer ist das Beste was Intel zu bieten hat noch der 6 Kern Gulftown.
Edit: Ich geh jetzt einfach mal davon aus das nichts schief geht und Bulldozer in 1H 2011 launcht.
Ronny145
2010-08-29, 18:56:45
Was der Gast meinte: Bulldozer kommt vor den 6 + 8 Kern Sandys auf den Markt (die kommen erst 2H 2011). Zum Launch von Bulldozer ist das Beste was Intel zu bieten hat noch der 6 Kern Gulftown.
Edit: Ich geh jetzt einfach mal davon aus das nichts schief geht und Bulldozer in 1H 2011 launcht.
Laut Volker ab Sommer. Vorher erwarte ich Bulldozer im Desktop auch nicht.
am AMD Analyst Day 2010 im November gibt es die nächsten Infos von AMD über Bulldozer, genau dann wird AMD verraten im welchen Quartal BD für den Desktop kommt.
eins steht schon fest, die Bulldozer Opterons für Server kommen als erstes
Psychopat
2010-08-29, 19:04:15
Ich meinte eigentlich mit Bulldozer Launch die Serverprodukte.
Bulldozer (Server) & Bulldozer (Desktop) darf man nicht direkt vergleichen, die Desktop Versionen werden 1,-1,5 Ghz höher takten weil 4 Module sehr klein auf einem DIE sind, es wird auch 6 Module geben, das wird noch bekannt gegeben.
Fetza
2010-08-29, 20:15:42
Sandy Bridge kommt auch mit 6 und 8 Kernen. Intel kann problemlos nachlegen wenn sie müssen. Aber erstmal muss überhaupt Bulldozer mal auf den Markt kommen. Ein konkreteres Datum außer 2011 gibt es nicht.
Nur kostet der günstigste gulftown 800 euro, das amd gegenstück 250. Klar, der amd ist langsamer, aber preis/leistung ist bei intel ein witz. Für 30%? mehrleistung bei gleichem takt bezahlt man gut 3 mal so viel.
Die P/L-Diskussion hat hier NICHTS verloren.
dargo
2010-08-29, 20:37:11
Nur kostet der günstigste gulftown 800 euro, das amd gegenstück 250. Klar, der amd ist langsamer, aber preis/leistung ist bei intel ein witz. Für 30%? mehrleistung bei gleichem takt bezahlt man gut 3 mal so viel.
Und was ist daran so schwer zu verstehen? Intel lässt sich die Leistungskrone entsprechend bezahlen. Gegen einen i7-970 hat AMD momentan nichts entgegenzusetzen. Ein X6 1090T kommt da lange nicht heran. Sollte der Bulldozer im Schnitt der Anwendungen aufholen, glaubst du Intel wird dann weiterhin 800€ für einen i7-970 (oder vergleichbare Nachfolger-CPU) verlangen? :rolleyes:
Nur kostet der günstigste gulftown 800 euro, das amd gegenstück 250. Klar, der amd ist langsamer, aber preis/leistung ist bei intel ein witz. Für 30%? mehrleistung bei gleichem takt bezahlt man gut 3 mal so viel.
Es sind es 50% Mehrleistung (MultiThreaded Anwendungen, nicht nur GPULimitierte Games betrachten)! Als AMD damals vor laaanger Zeit vorne war, haben sie sich ihre FX Chips auch vergolden lassen! Also ruhig Blut kleiner.
die Pentium4 waren damals langsammer und teurer als die AthlonFX
AMD ist immer günstiger
ohne AMD würde Intel noch bei Pentium6 sein und sich richtig ausruhen.
Psychopat
2010-08-29, 20:50:43
Bulldozer (Server) & Bulldozer (Desktop) darf man nicht direkt vergleichen, die Desktop Versionen werden 1,-1,5 Ghz höher takten weil 4 Module sehr klein auf einem DIE sind, es wird auch 6 Module geben, das wird noch bekannt gegeben.
Das wichtige an den Serverprodukten ist, ab dem Zeitpunkt weiß man ob der Desktop BD was taugen wird oder nicht.
Tiamat
2010-08-29, 21:18:09
Pflücken wir doch mal die Aussage von AMD auseinander.
AMD sagt
1) 16 Core BD entspricht 12 Core K10 ( Magny Core ) + 50 % = 150%
Dann lässt sich berechnen, dass ein 12 Core BD einem 12 Core K10 + 12 % entspricht und das ist max ( weil AMD angibt bis zu ).
Das schwankt natürlich in der Realität, wo die Ergebnisse von Bench zu Bench varriieren, aber diese relative Zahl kann man der Aussage abgewinnen.
Wenn man jetzt noch hergeht und sagt 2) CMT bringt 80% pro Modul und schlussfolgert 2) führt implizit zu 1) und zieht die 80% pro Modul vom Result ab, schätze ich spontan, dass da sogar ne geringere Single-Core Performance rauskommt, aber hier weiß man nicht, was AMD bei 1) gebencht hat.
8 CMT Cores vs. 12 echte Cores
1 CMT Modul ist nur so groß wie ein Sandy Bridge Core inkl. SMT
also 4 CMT Module ca. 4 SB Cores.
nochmal BD hat einen sehr kleinen L1 Cache
einen kleinen Cache hat man nur wenn man hohe Taktraten dem Design ermöglicht, Bulldozer wird mit großer wahrscheinlichkeit ein hochtaktdesign sein, 8 schmale Cores im Desktop über 4 Ghz sind garnicht mal so schlecht.
Der_Korken
2010-08-29, 23:06:39
Pflücken wir doch mal die Aussage von AMD auseinander.
AMD sagt
1) 16 Core BD entspricht 12 Core K10 ( Magny Core ) + 50 % = 150%
Dann lässt sich berechnen, dass ein 12 Core BD einem 12 Core K10 + 12 % entspricht und das ist max ( weil AMD angibt bis zu ).
Das schwankt natürlich in der Realität, wo die Ergebnisse von Bench zu Bench varriieren, aber diese relative Zahl kann man der Aussage abgewinnen.
Wenn man jetzt noch hergeht und sagt 2) CMT bringt 80% pro Modul und schlussfolgert 2) führt implizit zu 1) und zieht die 80% pro Modul vom Result ab, schätze ich spontan, dass da sogar ne geringere Single-Core Performance rauskommt, aber hier weiß man nicht, was AMD bei 1) gebencht hat.
Wenn dann bitte richtig.
8 BD Module = 12 P2 Kerne +50%
8 BD Module = 18 P2 Kerne
1 BD Modul = 2,25 P2 Kerne
in Multithread-Peformance.
Teilt man das Modul noch durch 1,8 um auf die Single Thread-Leistung zu kommen, käme man auf 1,25 P2 Kerne. Nach der Milchmädchenrechnung wäre ein BD Modul in Singlethread-Anwendungen 25% schneller als ein P2-Kern. Da keine Taktraten genannt wurden, es nur "bis zu 50%" sind und auch sonst keine Informationen über den Bench bekannt sind, nützt einem das nichts. Man höchstens mutmaßen, dass die IPC vermutlich nicht gesunken ist.
wie hoch würde die Leistung bei 4,5 Ghz @4 Modulen gegenüber andere CPUs skallieren?
Tiamat
2010-08-30, 00:40:48
Wenn dann bitte richtig.
8 BD Module = 12 P2 Kerne +50%
8 BD Module = 18 P2 Kerne
1 BD Modul = 2,25 P2 Kerne
in Multithread-Peformance.
Teilt man das Modul noch durch 1,8 um auf die Single Thread-Leistung zu kommen, käme man auf 1,25 P2 Kerne. Nach der Milchmädchenrechnung wäre ein BD Modul in Singlethread-Anwendungen 25% schneller als ein P2-Kern. Da keine Taktraten genannt wurden, es nur "bis zu 50%" sind und auch sonst keine Informationen über den Bench bekannt sind, nützt einem das nichts. Man höchstens mutmaßen, dass die IPC vermutlich nicht gesunken ist.
Ja hast recht, du vergleichst 1 Modul gegen einen P2-Core. Ich habe bei meiner Rechnugen ein BD Modul mit einem Dual-Core P2 in Relation gesetzt, weil mich interessiert hat, ob er es mit ihm aufnehmen kann.
Zur Milchmädchenrechnung, ja ohne sonstige Testkonditionen kann man da nichts rein interpretieren.
Vielleicht hat AMD ja zur IDF wieder n Hotelzimmer gebucht und man erfährt da mehr :-)
aylano
2010-08-30, 02:55:38
Nein, du behauptest das eine nicht genutzt 3. ALU "sehr viel" Strom verbraucht, wenn du schreibst das man ohne 3. ALU (welche nach deinen 5% Angaben nicht genutzt wird) viel Strom sparen würde! ergo müssen die ALUs des K10.5 auch unter Idle sehr viel Strom verballern. Und das glaube ich nicht!
Wenn du nicht verstehst, was Stromspartechniken bei idle machen, vorallem nachdem ich dir es schon erklärte, dann kann ich dir nicht helfen.
Und wennst das eh besser weißt, dann brauchst mich nicht mehr fragen.
die Pentium4 waren damals langsammer und teurer als die AthlonFX
AMD ist immer günstiger
ohne AMD würde Intel noch bei Pentium6 sein und sich richtig ausruhen.
Sacht mal Leute, meint ihr diesen Stuss wirklich ernst?
Denkt ihr wirklich, dass das Desktopsegment die einzige und signifikanteste Technikspirale ist?
Serveranwendungen sind natürlich Leistungsmäßig total gesättigt, wenn die ollen Farmen mehr Leistung brauchen, sollen die gefälligst ein paar Schränke mehr clustern....
=Floi=
2010-08-30, 10:54:23
hört mit den 4-4,5ghz auf. Das werden wir nicht so schnell erleben. 3-3,5ghz sind reaistischer und auch schon viel. Ich will hier noch einmal an den ollen phenom 1 erinnern, welcher nicht nur eine krücke war, sondern auch noch viel zu wenig takt hatte. Den haben die roten hier ja schon wieder vergessen... ;)
beachtenswert bei 6 den core modellen ist die serienmäßig hohe taktrate:http://www.computerbase.de/artikel/prozessoren/2010/test-intel-core-i7-980x-extreme-edition/36/#abschnitt_overclocking
mit OS sicherlich eine sehr hohe marke. AMD hat das problem, dass sie für die hohen taktraten viel volt brauchen und dies muß man aber mit den kleineren strukturen senken!
gruffi
jetzt mach alle fertig
Exxtreme
2010-08-30, 11:02:41
Sacht mal Leute, meint ihr diesen Stuss wirklich ernst?
Denkt ihr wirklich, dass das Desktopsegment die einzige und signifikanteste Technikspirale ist?
Serveranwendungen sind natürlich Leistungsmäßig total gesättigt, wenn die ollen Farmen mehr Leistung brauchen, sollen die gefälligst ein paar Schränke mehr clustern....
Für Server hatte Intel schon immer seine Epic-CPUs. Und ich denke, so war das auch geplant. Nur dann machte AMD da einen Strich durch die Rechnung.
Für Server hatte Intel schon immer seine Epic-CPUs. Und ich denke, so war das auch geplant. Nur dann machte AMD da einen Strich durch die Rechnung.
Und brachte mit der einhergehenden Konkurrenz andere Faktoren für Wirtschaftlichkeit in die Realisierungsebene.
Das wollte ich auch mit meinem Post sagen, dass eben nicht nur das Dekstpsegment von Belangen für die Entwicklung von CPU Technologie ist uuuuuuund oft nicht einfach Clustererweiterung eine Option darstellen.
Wenn du nicht verstehst, was Stromspartechniken bei idle machen, vorallem nachdem ich dir es schon erklärte, dann kann ich dir nicht helfen.
Und wennst das eh besser weißt, dann brauchst mich nicht mehr fragen.
Nein das Problem ist das du dir selbst widersprichst und es nicht mal selber merkst!
Serveranwendungen sind natürlich Leistungsmäßig total gesättigt, wenn die ollen Farmen mehr Leistung brauchen, sollen die gefälligst ein paar Schränke mehr clustern....
Das ist kompletter Unsinn.
Stromkosten bilden inzwischen beim Hosting einen sehr großen Anteil an den Betriebskosten, da stellt man nicht einfach mal paar Schränke dazu.
Der_Korken
2010-08-30, 15:33:45
Das ist kompletter Unsinn.
Stromkosten bilden inzwischen beim Hosting einen sehr großen Anteil an den Betriebskosten, da stellt man nicht einfach mal paar Schränke dazu.
Ich glaube der Satz war einfach nur ironisch gemeint und bezog sich nur auf die Behauptung, dass Intel die CPU-Entwicklung nicht vorangetrieben hätte, wenn AMD ihnen keine Konkurrenz gemacht hätte.
Originally Posted by JF-AMD:
IPC will be higher than previous generation
Single threaded performance will be higher than previous generation
hope this helps
Fakt ist das Design von Bulldozer steht fest, AMD wird innerhalb 1 Jahr Probleme beseitigen & Taktraten zzgl. TDP optimieren müssen.
ich erwarte bei Single Thread Anwendungen 5Ghz und bei Multithread 4Ghz Takt, das lässt sich schonmal vom kleinen L1 & L0-1/2 Cache ableiten.
Gipsel
2010-08-30, 20:51:28
ich erwarte bei Single Thread Anwendungen 5Ghz und bei Multithread 4Ghz Takt, das lässt sich schonmal vom kleinen L1 & L0-1/2 Cache ableiten.
Na das ist doch mal ein Tipp :D
Allerdings denke ich auch, daß deutlich weniger auch zu wenig sein könnte.
Ich erwarte von AMD, dass sie mal endlich zu Core2 in IPC und Perf/watt aufschließen.
Das werden sie, da habe ich wenig Sorge.
hoffentlich gibt es auch 6 Module für den Desktop
Intel bietet in 45nm 6 Cores mit Turbo @3,4 Ghz an
http://www.heise.de/ct/artikel/Prozessorgefluester-1064662.html
Das Frontend wirkt etwas schwach dimensioniert, bietet etwa nur vier x86-Decoder (Fast Path) für das gesamte Modul – so viele hat Nehalem für einen Kern alleine, wenn auch hier die Decoder gleich zwei logische Kerne zu füttern haben. Der aktuelle AMD K10 weist pro Kern immerhin drei schnelle Decoder auf. Mit seinen 8 Modulen – also je nach Sichtweise 8 bis16 Kernen – soll der Bulldozer-Serverchip Interlagos rund 70 Prozent mehr Integer-Performance (SPECint) als der 12-Kerner Magny-Cours erzielen, das sieht demnach nicht wirklich nach einem „verhungernden“ Frontend aus. Neben dem dicken Interlagos mit bis zu 8 MByte L3-Cache für alle Module auf dem Chip will AMD halb so große Chips für Server (Valencia) und High-End-Desktop-PCs (Zambezi) herausbringen.
und:
im Vergleich zu Magny-Cours zwar ein Drittel weniger Rechenkerne zu bieten, dennoch soll bei ihm dank AVX und FMA und besserer Speicheranbindung die SPECfp-Rechenleistung um ein Drittel höher liegen. Dabei sind die FPUs noch nicht einmal an dem kleinen L1-Cache angeschlossen. Einen L1-Bypass für die FPUs, den hatte Intels wenig erfolgreicher Itanium auch – hoffentlich ist das kein schlechtes Omen …
heise schreibt nur schrott, K8-1 im Llano ist gelogen weil die keine Ahnung haben, klar ein alter K8 mit 30% mehr IPC + ATI IGP ist ohne weitere eingriffe im Design nicht möglich, Llano ist K10.5, alles andere hat keinen sinn.
Das Frontend wirkt etwas schwach dimensioniert, bietet etwa nur vier x86-Decoder (Fast Path) für das gesamte Modul – so viele hat Nehalem für einen Kern alleine, wenn auch hier die Decoder gleich zwei logische Kerne zu füttern haben.
Die Decoder arbeiten anscheinend unter gewissen Umständen anscheinend wie acht. Wartet mal ab bei solchen Details.
http://www.heise.de/ct/artikel/Prozessorgefluester-1064662.html
– soll der Bulldozer-Serverchip Interlagos rund 70 Prozent mehr Integer-Performance (SPECint) als der 12-Kerner Magny-Cours erzielen, …
Woher er wohl die 70% hat. AMD selbst spricht nur von 50%. Aber vielleicht haben die einfach 1/2 x (70% + 33%) genommen. Macht dann ~50%.
Auf jeden Fall wären die 70% bei gleicher TDP (laut einer anderen Quelle beziehen sich die 50% von AMD auf CPUs mit gleicher TDP) schon gut.
Wenn jetzt die IPC des BD nicht besser wäre als bei Magny Cours müsste ein 8 Modul/16Core BD mit ca. 3,25 GHz laufen damit die SpecInt-Rate passen würde. ( etwas komplexe Rechnung: 2,3 x 1,7 / (16/12) x (2/1,8) ).
Wenn damit aber die normalen SpecInt für single threaded Apps gemeint sind wären sogar 3,9 GHz notwendig.
heise schreibt nur schrott, K8-1 im Llano ist gelogen weil die keine Ahnung haben, klar ein alter K8 mit 30% mehr IPC + ATI IGP ist ohne weitere eingriffe im Design nicht möglich, Llano ist K10.5, alles andere hat keinen sinn.
Nein, kein K10.5 sondern ein K10.5++ oder K10.7
Schließlich hat der Llano selbst gegenüber dem K10.5 weitere Verbesserungen verpasst bekommen. Leider fehlt der L3-Cache. Deshalb ist wahrscheinlich die Performance meistens trotzdem schlechter als bei einem PII
;)
Llano ist klar, aber wie der auf 70% kommt ist mir auch schleierhaft:-)
Bulldozer soll ja bei 33% mehr Kerne 50% schneller als dem K10 sein
also wären 4 Module so schnell wie ein Intel Gulftown mit 6 großen Cores
http://www.abload.de/img/sb36mp.jpg (http://www.abload.de/image.php?img=sb36mp.jpg)
wenn es AMD noch schafft Zambezi 20% höher zu takten, dann können 4 Module mit einem 6 Core Sandy Bridge mithalten
Woher er wohl die 70% hat. AMD selbst spricht nur von 50%. Aber vielleicht haben die einfach 1/2 x (70% + 33%) genommen. Macht dann ~50%.
Auf jeden Fall wären die 70% bei gleicher TDP (laut einer anderen Quelle beziehen sich die 50% von AMD auf CPUs mit gleicher TDP) schon gut.
Wenn jetzt die IPC des BD nicht besser wäre als bei Magny Cours müsste ein 8 Modul/16Core BD mit ca. 3,25 GHz laufen damit die SpecInt-Rate passen würde. ( etwas komplexe Rechnung: 2,3 x 1,7 / (16/12) x (2/1,8) ).
Wenn damit aber die normalen SpecInt für single threaded Apps gemeint sind wären sogar 3,9 GHz notwendig.
Ach ja vergessen:
wenn die crude Rechnung oben stimmt, dann sollte ein normaler 4 Modul BD auf 4,5 - 4,66 GHz kommen. Warum? Ein Thuban erreicht ja 3,2 GHz während ein Magny Cours max. 2,3 GHz erreicht. Ein Tuban taktet also fast 40% schneller! 3,25GHz x 1,4 = 4,55GHz.
Thuban 1090T - 18526 x 1.5 = 27789
also sind 4 Module mindestens so schnell wie ein Gulftown
hoffentlich kann AMD nach 1 Jahr die Taktraten mehr als erhofft takten, dann kann er wirklich mit 6 SB Cores mithalten
BlackBirdSR
2010-08-30, 21:59:36
Was mich eigentlich seit x-Seiten stört?!?
Hier werden Performancevorhersagen anhand von AMD SPEC-Werten gemacht.
SPEC!!!! Das ist mit Abstand das schlechteste, um Realworldperformance für Desktop-CPUs abzuleiten. Das Beginnt beim Compiler und endet bei Vorlieben für Caches und Streaming...
anhand dieser SPEC-Werten weis man jetzt schon das 4 Module die Leistung eines Gulftown 6 Core haben, ist doch nicht schlecht, in 1 Jahr kann das mit hohen Taktraten anders aussehen :D
anhand dieser SPEC-Werten weis man jetzt schon das 4 Module die Leistung eines Gulftown 6 Core haben, ist doch nicht schlecht, in 1 Jahr kann das mit hohen Taktraten anders aussehen :D
so siehts aus, wenn 4 Module z.b. 300 € kosten und so schnell wie ein 6 Core Sandy Bridge für 600 € sind, dann hat AMD das beste Produkt!
BlackBirdSR
2010-08-30, 22:07:20
anhand dieser SPEC-Werten weis man jetzt schon das 4 Module die Leistung eines Gulftown 6 Core haben, ist doch nicht schlecht, in 1 Jahr kann das mit hohen Taktraten anders aussehen :D
nix kapiert oder absichtlich ignoriert?
nix kapiert oder absichtlich ignoriert?
du meinst das die SPEC-Werte nix für einen vergleich zwischen K10 & BD taugen?
wie wurde damals Barcelona K8L mit dem Vorgänger K8 verglichen?
BlackBirdSR
2010-08-30, 22:12:47
du meinst das die SPEC-Werte nix für einen vergleich zwischen K10 & BD taugen?
wie wurde damals Barcelona K8L mit dem Vorgänger K8 verglichen?
ne ich meine, dass Spec-Werte nix für den Vergleich mit Desktop-Performance taugen. Da nutzt AMD einen anderen Compiler und setzt ein paar Flags, SPEC-Test Nr. 5 (fiktive BSPs) reagiert extrem auf Vektorisierung und Nr. 9 auf Streaming und schon haben Änderungen am BD große Auswirkungen, die ihm bei Spielen keinen Meter vor den K10 katapultieren können. Aber 70% ey!
Ich wäre etwas vorsichtig...
Tiamat
2010-08-30, 23:08:08
Naja AMD hat zur Desktop-performance ja auch nix gesagt, die 50% bezogen sich ja auf das Server-Modell.
Naja AMD hat zur Desktop-performance ja auch nix gesagt, die 50% bezogen sich ja auf das Server-Modell.
Jo und das ohne AVX/XOP/FMA Compilerspielchen. Inklusive könnten das dann schon 70% sein, v.a. bei SPEC ;-)
warum hat AMD den Phenom II nicht mehr weiterentwickelt? oder ist da kein Potential mehr vorhanden? könnte man die Cores vom K8 nicht vergrößern, neue FPU und 50% mehr IPC gegenüber K8L @45nm ?
Intel hat ha z.b. den P3 erfolgreich zu Core2 & Nehalem weiterentwickelt, warum hat AMD beim K8 nicht weiter gemacht, die haben doch große erfahrung mit dem Design gemacht, echte Cores sind besser als diese 2 kleine integer. eines Moduls.
AMDs Phenom II braucht einfach 50% mehr IPC, neue FPU, doppel SMT, AVX & die anderen Befehlserweiterungen, ist das in 3 Jahren nicht möglich gewesen zu realisieren? wäre bestimmt günstiger als BD.
echte Cores sind besser als diese 2 kleine integer. eines Moduls.Ja, aber diese 2 kleinen Teile sind besser als Hyperthreading auf einem großen Kern.
Ausserdem kann man durch den unkomplexeren Kernaufbau die kleinen Teile schön takten. Solange einem der Fertigungsprozess keinen Strich durch die Rechnung macht, wie damals beim P4, ist das ein sehr vielversprechender Ansatz.
Wem interessiert Hubraum (IPC), wenn man insgesamt mehr PS (Takt) unter der Haube hat ...
Wichtig ist was hinten rauskommt, und das sehen wir erst in ca. einem Jahr, bis dahin wäre ich vorsichtig ;-)
Der_Korken
2010-08-30, 23:37:32
warum hat AMD den Phenom II nicht mehr weiterentwickelt? oder ist da kein Potential mehr vorhanden? könnte man die Cores vom K8 nicht vergrößern, neue FPU und 50% mehr IPC gegenüber K8L @45nm ?
Jo klar, mal eben 50% mehr IPC ... das ist nicht einfach sowas wie, ich klatsch mal eben so 50% mehr Recheneinheiten dran. Das wäre so, als würdest von ATI/Nvidia erwarten, dass sie einen 50% schnelleren CHip entwickeln sollen, der genauso viele Shader etc. hat und genauso schnell taktet.
und was macht dann AMD bei der nächsten BD Generation?
mehr IPC pro Modul oder mehr integer Cores pro Modul?
können 2 Threads als einen Core arbeiten mit IPC Faktor2 ?
mehr IPC pro Modul oder mehr integer Cores pro Modul?
Beides, aber vermutlich erstmal Option 1, les mal unter speculative MT bei Dresdenboys Artikel auf P3D nach ;-)
das Design ist ja frisch neu und hat bestimmt wie der K7 damals viel Potential zum optimieren :)
Bulldozer2 sollte bestimmt im selben Fertigungsprozess kommen, 22nm dauert ja noch ne ganze weile...vielleicht gibts dann bei BD2 viel IPC so das dann 8 integer Cores ein Monster werden
BlackBirdSR
2010-08-31, 00:04:44
warum hat AMD den Phenom II nicht mehr weiterentwickelt? oder ist da kein Potential mehr vorhanden? könnte man die Cores vom K8 nicht vergrößern, neue FPU und 50% mehr IPC gegenüber K8L @45nm ?
Bulldozer ist Phenom II weiterentwickelt!
Auch wenn das Kleid jetzt rosa und anders geschnitten ist, dahinter arbeiten viele Kernkomponenten noch immer nach den gleichen Prinzipien und Implementationen wie zum K7, K8 und K10. Das ganze Design entwickelt sich, so wie es Intel beim PPro bis i7 auch getan hat.
AMD ging in einigen Bereichen eben einen Schritt weiter und hat ein paar Sachen radikal geändert. Stell dir vor, Du hättest Raketenwerfer statt Arme bekommen, aber das Herz pumpt noch immer das gleiche But durch die gleichen Gefäße und die Raketenwerfer sitzen auch an den Schultern ;)
Es wurde aber wirklich sehr viel umgekrempelt. Vor allem dass der Integer-Scheduler komplett neu ist hat mich doch überrascht.
Bulldozer ist Phenom II weiterentwickelt! ;)Achso ? Welche Kernkomponenten außer dem I$ bleiben denn noch gleich ?
Um ehrlich zu sein überrascht mich die Ansicht jetzt - genausogut könntest DU sagen, dass ein Trace Cache nur ein aufgebohrter LSD ist *duck und weg*
Das wird sich erst zeigen, wenn es richtige Blockdiagramme von Bulldozer gibt.
Das wird sich erst zeigen, wenn es richtige Blockdiagramme von Bulldozer gibt.
Naja, selbst die Art der Registerzugriffe beim Renaming wurden geändert, das ist mMn schon ein recht tiefer Einschnitt.
Dazu dann noch:
FPU: Geändert wegen FMAC -> sicher
INT: Geändert wg. Takt -> ziemlich sicher
Dekoder: Aufgebohrt auf vermutlich 4x2 Blöcke
Scheduler: wurde schon erwähnt
Dispatch: vermutlich Wegfall der Pack Stage
Da ist zwar noch viel Spekulation dabei, aber nachdem die Patente bisher alle zutrafen, sehe ich da nicht viel Chancen dass da noch irgendein Stein auf dem anderen bleibt ... die gröberen Änderungen wie der Trace/RRC Cache oder die Modul/CMT Struktur sind da auch noch gar nicht berücksichtigt.
Naja vielleicht noch die AGUs ;)
Leonidas
2010-08-31, 06:19:02
Mein primäres Problem an BD ist nach wie vor, daß das ganze so aussieht, als wolle man wirklich im Server-Bereich mit 4 BD-Modulen gegen 4 große Kerne von Intel antreten (und 8 Module gegen 8 große Kerne etc), weil man sich das bezüglich des Siliziumaufwandes leisten kann.
Nur: Das alles nützt im Desktop-Bereich nichts. Wollen wir uns da wirklich einen 4-Modul-BD mit 8 Kernen in den Rechner hängen, wenn die Desktop-Software derzeit nur ca. drei Kerne vernünftig ausnutzen kann? Im Desktop-Bereich ist die höchstmögliche für einen breiten Teil des Marktes geltende Formel: 4 Kerne vs. 4 Kerne - und ob AMD diese 4 Kerne nun mittels zwei Modulen erreicht, ist egal. Und für diese Ansetzung braucht AMD einfach eine hohe Leistung pro Kern, egal ob per IPC oder per Takt.
Derzeit sieht es für mich so aus, als wäre BD ein genialer Schachzug für den Server-Bereich, welcher aber im Desktop-Bereich nicht die (teilweise extrem hochgesteckten) Erwartungen erfüllen kann.
BlackBirdSR
2010-08-31, 08:14:31
Achso ? Welche Kernkomponenten außer dem I$ bleiben denn noch gleich ?
Um ehrlich zu sein überrascht mich die Ansicht jetzt - genausogut könntest DU sagen, dass ein Trace Cache nur ein aufgebohrter LSD ist *duck und weg*
Tja da gibts eben viel mehr feine Details, die man unterscheiden muss ;)
Vielleicht hast Du auch recht, dass sich die beiden Ansichten etwas beißen.. aber würde ich nie zugeben ;)
Naja vielleicht noch die AGUs ;)
vielleicht ja auch nicht:
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137878&sid=eaae52920a4e1dcb0a46ed527520e59b&start=200#p187937
So "AGen" might be an AGU ( AMD calls it Address Preparation Unit in the patent) + AMU...
sh...t
noch was vergessen:
AMD's Bulldozer Microarchitecture; von David Kanter (http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=1)
Triskaine
2010-08-31, 11:33:24
sh...t
noch was vergessen:
AMD's Bulldozer Microarchitecture; von David Kanter (http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=1)
Sehr empfehlenswerte Lektüre, mit einer Vielzahl an gänzlich neuen architekturellen Details.
BlackBirdSR
2010-08-31, 12:37:32
ja immer schön zu sehen.
128 Bit breite FPUs, unsicher ob die Register für AVX 256Bit breit sind und ein inklusiver L1D-L2-Cache.
sh...t
noch was vergessen:
AMD's Bulldozer Microarchitecture; von David Kanter (http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=1)
Ja, sehr spannend danke. Interessant auch das er immer wieder Optimierungen auf hohe Frequenzen zu erkennen glaubt. Könnte durchaus sein das sie AMD ein Vorbild beim Power7 genommen hat, der ja auch schon die 5Ghz knackt und damit deutlich höher taktet als Intel.
Gerade erst gesehen:
Derzeit sieht es für mich so aus, als wäre BD ein genialer Schachzug für den Server-Bereich, welcher aber im Desktop-Bereich nicht die (teilweise extrem hochgesteckten) Erwartungen erfüllen kann.
Da halte ich es mit dem Typen hier:
Bulldozer will be faster than K10, the question is how much, and how it does against Core2 on single thread code. On Hypethreaded code Intel will get Bulldozered, except that Intel will demand reviewers use twice the die size for Intel to match the AMD core count, and then Intel will win, at twice the cost. http://groups.google.com/group/comp.arch/msg/a1264bf05b57b376
Langsamer als K10 wird BD sicher nicht. Wenn man jetzt davon ausgeht, dass Core2 & K10 pi*Daumen ungefähr auf dem gleichen Leistungsniveau sind, dann ist man bei "schneller als Core2", ergo das geht dann in Richtung Nehalem. Das muss dann an IPC für den Desktop User reichen, v.a. kommt dann ja noch der +20-30% Taktaufschlag durch die längere Pipeline und dann noch der +xy% Taktaufschlag durch den 32nm hK Prozess dazu.
Wenn der Prozess nicht allzu grottig wird, hat AMD auf alle Fälle einen höheren Frequenzspielraum als Intel - fragt sich nur, ob Intel Ende 2011 nicht schon wieder mit 22nm ankommt :freak:
Noch zum Kanterartikel:
Da hatten wir letzten doch die Diskussion über das bessere Speichersubsystem bei Intel. Wäre das bei BD jetzt mit den besseren Prefetchern und der memory disambiguation Erkennung jetzt einigermaßen auf gleichem Stand ? Oder fehlt noch was ?
ciao
Alex
Wenn man jetzt davon ausgeht, dass Core2 & K10 pi*Daumen ungefähr auf dem gleichen Leistungsniveau sind
Sind sie bei weitem nicht.
Sind sie bei weitem nicht.
Sind sie laut zahlreichen Tests sehr wohl.
Aber sicher nicht in der Single-Threaded-Leistung. Und darum geht's nunmal im Endeffekt.
DeadMeat
2010-08-31, 14:29:37
Aufjedenfall dürfte klar werden das die sache mit den Modulen und Cores noch einige Probleme bei den Reviews bringen wird wenn man schon sowas ließt wie s940 zitiert. Zwar vorrangig bei Servern aber wer weiß.
Zwar nicht ganz On T. aber gibt es schon details zu den Plattformen für AM3+?
Sind sie bei weitem nicht.
Hmm, war nicht ein 3 GHz Phenom auf Q9550 Niveau ?
Gut, knappe 200MHz Unterschied, aber doch eher Peanuts, oder hast Du richtig krasse Fälle ?
Dann verlink die doch bitte gleich mit.
Ja ist Zusatzarbeit, aber bringt dafür auch viel mehr (und unterdrückt diverse Nein-Ja-Doch Gastposting Stafetten im Keim) :)
@DeadMeat:
Am3+: Nicht das ich wüßte ... irgendwas "elektrisches", was auch immer.
merci
Alex
Hmm, war nicht ein 3 GHz Phenom auf Q9550 Niveau ?
Das Problem ist, dass der Phenom bei Multithreading deutliche Vorteile zieht, weil es eine monolithische CPU ist. Die Core 2 Quads bestehen nunmal aus zwei Dies und müssen über den FSB zum Datenaustausch.
Rein von der Kern-IPC ist ein Penryn einem K10 aber klar überlegen.
Rein von der Kern-IPC ist ein Penryn einem K10 aber klar überlegen.
Wieviel ist den das nun wirklich? Taktbereinigt meine ich. Ist da ein Core2 10% oder 20% oder wieviel schneller als ein PhII-Kern?
Äh das stimmt so nicht. Haben die Speicherzugriffe linearen Charakter, spielt der K10 in einer anderen Liga, nämlich in der des Nehalem.
Das Problem ist, dass der Phenom bei Multithreading deutliche Vorteile zieht, weil es eine monolithische CPU ist. Die Core 2 Quads bestehen nunmal aus zwei Dies und müssen über den FSB zum Datenaustausch.
Rein von der Kern-IPC ist ein Penryn einem K10 aber klar überlegen.
Achso Du meinst wirklich echte single Threads, hmm also z.B: sowas wie SuperPi ?
Ok, da stimme ich dann dazu, aber ich halte es mittlerweile für nebensächlich. Selbst die schlechtesten Spiele nutzen mittlerweile 2 Threads (Starcraft ahoi :biggrin: ).
Was gibts den sonst noch an Wichtigem, das nur 1 Thread nutzt ?
Webbrowser ? Da nützt google Chrome auch schon mehr Threads. Ansonsten fällt mir da spontan jetzt nichts ein.
Höchstens alte Legacy Programme, aber die sollten auf ner 3 GHz+ Maschine so oder so schnell genug laufen.
Hmm ..vielleicht noch als Sonderfall Emulatoren ?
Oder übersehe ich jetzt was wichtiges ?
ciao
Alex
Was ich damit sagen will ist, dass AMD um Nehalem-Leistung erzielen zu können erstmal die von Penryn erreichen muss pro Kern.
Von K10 vor allem auf Sandy-Bridge-Niveau ist ein sehr langer Weg.
Undertaker
2010-08-31, 14:51:48
Was gibts den sonst noch an Wichtigem, das nur 1 Thread nutzt ?
Webbrowser ? Da nützt google Chrome auch schon mehr Threads. Ansonsten fällt mir da spontan jetzt nichts ein.
Für mehrere Tabs, ja. Bei einem einzigen Tab allerdings nicht:
http://www.abload.de/thumb/unbenanntjpgj.png (http://www.abload.de/image.php?img=unbenanntjpgj.png)
Solche Fälle gibt es immer mal wieder, da hilft dann nur Single-Core Performance - notfalls zumindest über einen starken Turbo.
Bulldozer ist besser als Nehalem P6
Fakt ist, das mein P4M 750 selbst fuer das alltaegliche "Surfen" zu langsam ist. Scrollen -> 100% cpu load...das war anno 2005 noch anders, mehrere Tabs waren moeglich, heute "No way".
Für mehrere Tabs, ja. Bei einem einzigen Tab allerdings nicht:
[/URL][URL]http://www.abload.de/thumb/unbenanntjpgj.png (http://www.abload.de/image.php?img=unbenanntjpgj.png)
Huch, Hilfe ein Undertaker Post ohne Vorwarnung :freak:
Hast Du Dich jetzt selbst von meiner Ignorierliste genommen, oder geht das automatisch ?
Gestern gings noch, obwohl Du da schon Mod warst.
Wie auch immer zum Thema, jetzt isses ja auch schon egal:
Wie realistisch sind solche Seiten, ist das nicht nur schlecht programmiert ? ;-)
Was ich damit sagen will ist, dass AMD um Nehalem-Leistung erzielen zu können erstmal die von Penryn erreichen muss pro Kern.
Von K10 vor allem auf Sandy-Bridge-Niveau ist ein sehr langer Weg.
HMm, das mit Conroe Performance ist so ne Sache, da half oft auch der dicke L2, den Nehalem nicht mehr hatte. Dafür hatte der dann IMC plus (nochmals bessere) Prefetcher.
Sandy Bridge IPC Niveau erwarte ich bei single-thread eh nicht, irgendwo so zw. Core2 und Nehalem hoffe ich. Der L2 Cache ist schön groß, die Prefetcher und IMC verbessert, dazu dann noch ein höherer Takt, das müßte reichen. Aber warten wirs ab.
ciao
Alex
Man kann Mods wohl nicht ignorieren.
Undertaker
2010-08-31, 15:14:38
Ich hab nix gemacht. ;)
Öhm, die Seite auf dem Screenshot ist sicherlich ein Ausnahmefall (der im übrigen Chrome in der aktuellen Version auch ganz und gar nicht schmeckt), dass diente nur zur Verdeutlichung der fehlenden Parallelisierung innerhalb eines Tabs.
Aber ich denke das führt das Thema jetzt etwas zu weit. Singlethread wäre sicherlich ein riesiger Schritt notwendig, um mit Bulldozer vom aktuellen Stand nicht nur auf Core 2, sondern auch bis Nehalem oder gar Sandy Bridge zu kommen. Ein Weg, der sicherlich nur über IPC und Taktsteigerungen genommen werden kann.
Rein von der Kern-IPC ist ein Penryn einem K10 aber klar überlegen.
Ich glaube du überschätzt das deutlich. Der Unterschied ist bei weitem nicht so klar wie du ihn hier darstellst. Alleine der große L3-Cache hat dem Phenom II viel gebracht bei Single-Thread. Schau dir Benchs an, auf keinen Fall mehr als 10% IPC-Vorteil für den Penryn im Schnitt, oft genug liegt der Phenom gleichauf oder leicht drüber.
Man kann Mods wohl nicht ignorieren.
Gestern gings noch .. wobei ne halt, da hatte Undertaker nichts geschrieben, sondern nur mein Post editiert.
Da hab ich mich also getäuscht.
Undertaker
2010-08-31, 15:17:42
Das Triple-Posting zusammengeführt. ;) Und jetzt bitte wieder zum Thema. :)
Alleine der große L3-Cache hat dem Phenom II viel gebracht bei Single-Thread.
Den hat Core 2 aber nicht.
Den hat Core 2 aber nicht.
Na komm, jetzt sei mal nicht so spitzfindig, und veräpple den armen Gast nicht so :freak:
@Undertaker:
ZU Befehl ;-)
Den hat Core 2 aber nicht.
Dafür hat er einen 6MB großen L2-Cache mit deutlich niedrigeren Latenzen pro zwei Kernen. Da ist der Phenom eher noch immer im Nachteil. Cachenormalisiert wirst du ohnehin keine Benchs bekommen, dafür ist das Design viel zu unterschiedlich, alleine schon wegen inkl. vs. exklusiver Cache.
Guest
2010-08-31, 16:16:35
News von Intel
Intel Medfield-Ex will offer higher Performance per Watt as Bulldozer :
http://www.anandtech.com/4011/Intel-Medfield-Ex
News von Intel
http://www.anandtech.com/4011/Intel-Medfield-Ex
Link geht nicht. Und auf andandtech finde ich auf die Schnelle auch nichts
War wohl ne Falschmeldung :freak:
Edit:
Ach, Medfield ist irgendein Atom .. dann war das Posting eh nur ein Scherz ...
Virenscanner sind bisher single-threaded und genau da hätte ich gerne mehr CPU-Power. So als Beispiel...
Und: Selbst wenn ein Programm mit 2 Kernen skaliert, sind 2 schnelle Kerne immer noch im Vorteil ggü. 8 langsameren... Kann aktueller Programmcode (nichts was encodet, rendert, cruncht etc. sondern z.B. OS-Teile, Treiber, Updater, Anwendungsprogramme) überhaupt mehr als 2 geschweige 4 Threads in einer Art und Weise nutzen, die höhere Leistung per Core überflüssig macht?
Das einzige was mich von meinem jetzigen System zum umsteigen bringen kann, ist höhere Leistung per Core. Wenn das weder mit Bulldozer noch mit Sandy Bridge in deutlichem Maße ermöglicht wird, hält mein i7 noch laaaange ;)
Virenscanner sind bisher single-threaded und genau da hätte ich gerne mehr CPU-Power. So als Beispiel...Nein. McAfee bei der Arbeit lastet zwei Kerne einigermassen aus, AVG zu Hause benutzt ebenfalls mehrere. Allerdings kommt dies, ausser bei grossen Archiven, kaum zum Tragen, weil I/O viel stärker limitert (habe keine SSD).
[edit]Und das ist sowas von OT, sorry :ugly:
=Floi=
2010-09-01, 00:23:27
Gerade erst gesehen:
Da halte ich es mit dem Typen hier:
http://groups.google.com/group/comp.arch/msg/a1264bf05b57b376
Langsamer als K10 wird BD sicher nicht. Wenn man jetzt davon ausgeht, dass Core2 & K10 pi*Daumen ungefähr auf dem gleichen Leistungsniveau sind, dann ist man bei "schneller als Core2", ergo das geht dann in Richtung Nehalem. Das muss dann an IPC für den Desktop User reichen, v.a. kommt dann ja noch der +20-30% Taktaufschlag durch die längere Pipeline und dann noch der +xy% Taktaufschlag durch den 32nm hK Prozess dazu.
Alex
imho werden die ibm teile doch per wasser gekühlt und eine solche server cpu ist auch etwas anderes wie eine consumer cpu. Alleine schon der extrem höhere preis erlaubt eine teurere fertigung.
erklär mir aber mal, wie man mit einer längeren pipeline eine höhere IPC erreichen kann?
Bisher spricht alles gegen eine viel höhere IPC und auch bei den taktraten zweifle ich stark an den 4ghz+
Der größte trumpf bei Intel war bisher die kürzere pipeline und die gleichzeitige taktbarkeit!
erklär mir aber mal, wie man mit einer längeren pipeline eine höhere IPC erreichen kann?
Indem man an anderen Stellen optimiert. Stalls durch Speicherzugriffe sind inzwischen eh viel eher das Problem als branch misspredicts.
Und AMD hat offenbar endlich ordentliche Prefetcher eingebaut. Das war ja meiner Meinung nach der Performanceschub für den Core 2.
imho werden die ibm teile doch per wasser gekühlt und eine solche server cpu ist auch etwas anderes wie eine consumer cpu. Alleine schon der extrem höhere preis erlaubt eine teurere fertigung.Wasserkühlung ? Hmm gibts sicherlich, aber dass das jetzt Standard wäre, wäre neu für mich. Sowas gabs meines Wissens nur bei nem Sparc64 Chip. Und selbst wenn ... die Power7 sind 567 mm2 Monster Dies in 45nm und davon werden dann noch 4 in ein Modul gepackt. Gut möglich, dass man das dann mit Wasser kühlen sollten. Wie auch immer - dabei erreicht man immer noch beachtliche 4,25 GHz. Aus dem Sichtwinkel betrachtet wären 5 Ghz für ein kleineres BD DIE in 32nm eigentlich nichtmal viel :freak:
erklär mir aber mal, wie man mit einer längeren pipeline eine höhere IPC erreichen kann?
LSD/Trace Cache plus µOp Fusion plus dickeres Front & Back-End (4 MacroOps anstatt 3) plus bessere Prefetcher plus bessere Cache Anbindung (2 128 bit Load + 1 128b Store pro Takt) plus ... les einfach die letzten Seiten ^^
Kurz:
Du hast Angst vor einer zu geringen Durchflussmenge und beschwerst Dich darüber, dass das Rohr zu lang wäre, obwohl Rohrdurchmesser und Wasserdruck (Takt) zulegen und somit die Durchflußkapazität zunimmt ;-)
Der P4 war nicht wegen seiner langen Pipe so miserabel, sondern eher aufgrund der ganzen Kompromisse, die man schließen musste. Ganz vorne dabei die kleinen 8kB Caches und die miserable x87 FPU. Sehr blöd - wenn alle Software x87 nützt ... zusätzlich war dann auch noch Intels damaliger Prozess schlecht, sodass sie die Taktziele nicht einhalten konnten -> typischer Fall von loose/loose Situation. :(
Der größte trumpf bei Intel war bisher die kürzere pipeline und die gleichzeitige taktbarkeit!Tja, was der wert ist, wird sich dann 2011 rausstellen. Erwarte da mal nicht zuviel von der Taktbarkeit. Natürlich wird die ganz sicher nicht schlechter werden, aber bisher konnte Intel da exklusiv den highK Vorteil ausspielen, aber da schließt GF jetzt auf und ausserdem nutzen sie schon ULK. Das spart zusammen Strom, den man dann wieder in Mehrtakt reinvestieren kann, genauso wie die PRFs.
Logisches Fazit: BD muss besser als SB takten können, alles andere wäre peinlich.
Einzige Bedingung ist, dass sich GF mit Gate First wirklich nicht verhoben haben sollte oder ähnliche Leckprobleme wie damals beim P4 auftreten :freak:
Aber naja wird schon klappen *auf Holz klopf*
Edit:
Zu spät ^^
ciao
Alex
Der P4 war vor allem wegen Replay so beschissen.
Welcher Vorteil würde sich denn durch einen funktionierenden Gate First Prozess ergeben?
Aber schon faszinierend, wie gut Intel das hinbekommen hat. Nehalem hat doch eine um 2 Stufen längere Pipeline, einen um über 87,5% reduzierten L2-Cache pro Core ( ggü Wolfdale sogar 92% ), der zudem 2ns langsamer war.
Die L1 + L2 Cache Inhalte werden sogar noch als Kopie im L3 Cache gespeichert, wodurch ja im Endeffekt auch nur ein Teil des L3 für L3-exclusive Daten zur Verfügung steht.
Bei SB ist dieser noch ein 1ns langsamer und der is noch schneller.
Das ist ja schon ne Verhöhnung alter x86 Architekturen xD
=Floi=
2010-09-01, 08:23:32
nehalem ist schon gleichwertig/besser bei den cache durchsatzraten wie seine vorgänger:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=280732&page=9&highlight=everest+cache
du lässt dafür den l3 cache außer acht und im best case kann der nehalem durch seine asynchronen controller auch die zugriffszeit auf 1/3 senken im vergleich mit einem synchronen controller. (wegen der 3 getrennten controller)
wie ist eigentlich bulldozer aufgebaut?
Gipsel
2010-09-01, 09:58:20
Bisher spricht alles gegen eine viel höhere IPC und auch bei den taktraten zweifle ich stark an den 4ghz+
Um mal die Geschichte zu bemühen, das letzte Mal, daß AMD bei einer neuen CPU explizit von einem neu ausgelegten Pipeline zur Erhöhung der Taktrate gesprochen hat, war beim seligen K7. Und wenn ich mich richtig erinnere, gab das doch einen recht ordentlichen Sprung zum K6 und hat Intel damals mit ihrem P3 ganz ordentlich unter Druck gesetzt. Wenn sie jetzt über BD in einer offiziellen Presentation schreiben "designed for low gates/clock", dann erwarte ich mehr als nur 10% oder 20% höhere Taktraten als beim K10, auch wegen des gleichzeitigen Wechsels auf 32nm HKMG, sprich wirklich 4GHz+ für die Version mit 4 Modulen.
Der größte trumpf bei Intel war bisher die kürzere pipeline und die gleichzeitige taktbarkeit!
Intel und kurze Pipeline? Kurz im Vergleich wozu? Im Vergleich zu den eigenen P4/Prescotts vielleicht (von Northwood ist ein Nehalem gar nicht soo weit weg, wenn man die double pumped ALUs wegläßt), aber im Vergleich zu den AMDs haben sie eine etwas längere Pipeline.
Gab es nicht mal so ein altes IBM-Paper, was eine optimale Pipeline-Länge von ungefähr 20 Stufen vorhergesagt hat? Optimal für den Durchsatz, versteht sich. Zum Vergleich, ein K7 hatte 10 Stufen, ein K8/K10 hat 12 Stufen, Bobcat hat 13 Stufen (für ein low-power-Design ist eine kürzere Pipeline optimal, trotzdem ist es mehr geworden als beim K10!), Core2 steht bei 14 und Nehalem bei 16, wenn ich da jetzt nichts durcheinanderbringe. Willamette und Northwood waren übrigens 20 Stufen-Designs (ohne Decoder, ab Tracecache gezählt), Prescott stand dann irgendwo bei 30. Also mich sieht das so aus, als wenn die damals mit den ~20 Stufen nicht so schlecht gelegen haben, da anscheinend alle darauf zustreben (und Prescott offensichtlich über das Ziel hinausgeschossen ist).
Ach übrigens, ein Power6 hat mit einer 14stufigen Pipeline auch schon satte 5GHz in 65nm hinbekommen. Da ist zwar das Instruction-Decoding nicht ganz so aufwendig, es zeigt aber, was man mit einer gut balancierten Pipeline auch ohne exzessive Erhöhung der Anzahl der Stufen im Prinzip hinbekommen kann (okay, da hat IBM auch ein paar Kompromisse gemacht, Power4 und Power5 hatten übrigens auch 14 Stufen).
Der P4 war vor allem wegen Replay so beschissen.
Ach Du Mist, das hatte ich übersehen, hab mir jetzt den seligen Artikel auf xbits durchgelesen:
http://www.xbitlabs.com/articles/cpu/display/replay_2.html#sect0
Nenene ... was für ein Käse.
Da stellt sich jetzt die Frage, wie das BD macht, denn der Absatz sollte auch für BD gelten:
Theoretically, the easiest way to schedule the commands with the unknown execution time implies that we take the worst latency expectation. However, when we have data loading from the memory, this number can reach hundreds of clock cycles (if we have to address the system RAM). As a possible solution, we can simply make the scheduler hold the ADD instruction depending on the result of the LD command until the data has already arrived. However, in a processor with a long pipeline this method will not be that efficient, because in this case the execution time for the L1 data loading command will be calculated as L1 cache latency + the distance to the scheduler in processor clock cycles (in the example above this will be the distance from the Scheduler to the ALU_Oper).
Oder passt das noch, wenn man unter 20 bleibt ?
@Gipsel:
Jo, da gibts irgendwo einen Peak aus Frequenz / IPC im Verbindung mit Pipelinelänge.
Aber wenn man halt Kröten wie das obige Replay hat und/oder die Exec. Units limitiert sind (x87 Unit beim P4), dann hilft das alles nichts. Das ist dann wie ein Porsche ohne Räder :freak:
Wieviel Stufen hat eigentlich die p7 Pipe ? Die wäre maßgeblich, P6 war ja in-order, das zählt nicht ;-) Hier im Forum hab ich dazu nur ne unbeantwortete Frage von Coda gefunden ^^
Das beste über google war Power6 Länge, oder mehr :freak:
Und Bulldozer? 17 Stufen....
Und Bulldozer? 17 Stufen....
eher nicht, oder? BD ist 17FO4 ; K10 anscheinend 22FO4.
Was das jetzt mit der Anzahl der Stufen zu Tun hat?????
Ach Du Mist, das hatte ich übersehen, hab mir jetzt den seligen Artikel auf xbits durchgelesen:
http://www.xbitlabs.com/articles/cpu/display/replay_2.html#sect0
Nenene ... was für ein Käse.
Da stellt sich jetzt die Frage, wie das BD macht, denn der Absatz sollte auch für BD gelten:
Oder passt das noch, wenn man unter 20 bleibt ?
...
Aber wenn man halt Kröten wie das obige Replay hat und/oder die Exec. Units limitiert sind (x87 Unit beim P4), dann hilft das alles nichts. Das ist dann wie ein Porsche ohne Räder :freak:
So etwas wie Replay braucht man nur, wenn zwischen scheduler und der Stufe, in der das Ergebnis der Operation bekannt wird, mehrere stages liegen.
Also wenn man 20 Stufen vor dem scheduler hat, ist das noch nicht das Problem mit dem der P4 zu kämpfen hatte. Interessant wird es erst, wenn bedingte Operationen im scheduler bereit liegen, die vorherige op aber noch 4 Takte braucht um ihr Ergebnis zu offenbaren ;)
Nenene ... was für ein Käse.
Ja, das ist echt super. Der P4 loopt die auf die Daten wartende Instruction möglicherweise mehrere tausend Takte immer wieder durch die ALUs bis das Resultat aus dem RAM nachgeladen ist.
Super für die Energieeffizienz :freak:
Gestrandet
2010-09-01, 16:00:26
Gute Instruktionen kann man doch gar nicht oft genug ausführen ;-)
32nm Orochi Die:
http://www.pcper.com/comments.php?nid=9207
Tja aber offenbar wars bitter nötig... Lieber 20% Looping statt 80% Stillstand ;)
SavageX
2010-09-01, 20:14:17
Warum zum Henker sind die beiden oberen Module größer als die unteren?
Hier mal von mir schlampig entzerrt:
http://a.imageshack.us/img829/8818/orochidie.jpg (http://img829.imageshack.us/i/orochidie.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Das ist eine wirklich sehr gute Frage. Auch scheint oben dafür der Cache kleiner zu sein. WTF?
Vielleicht haben sie das Bild manipuliert um Intel im Unklaren zu lassen?
SavageX
2010-09-01, 20:22:29
JF-AMD hat irgendwo geäußert, dass Die-Shots grundsätzlich immer durch Photoshop gehen, um die Hosen nicht grundlos runterzulassen. Aber das wäre in diesem Falle ja ein ganz ganz lautes "f*ck you", so augenscheinlich widersprüchlich ist das zu den bisherigen Informationen.
edit: Ich glaube (besser: rate) die unteren Module sind näher an der Wirklichkeit dran als die oberen. Die sind halbwegs symmetrisch, hier könnte man zwei Kerne, jeweils gespiegelt zueinander, erkennen, mitsamt zweimal Daten-Cache. Den Instruktions-Cache würde ich im unteren rechten Modul mal links oben verorten. Fließkomma am rechten Rand des Moduls. Unterhalb des I-Cache vermute ich mal das Frontend mit Decodern, da sieht was ROM-ig aus. Alles wild geraten.
Bei den oberen Modulen sehe ich ziemlich mittig jeweils einen duplizierten Streifen, der nicht spiegelverkehrt ist - und dann noch einen dritten ähnlichen Bereich. Hmmm...
Der L2-Cache ist 2 MB groß, der L3 vermutlich 8 MB, womit jeder der vier L3-Streifen 2 MB haben sollte. Die Größe der 2 MB L3-Streifen passt ungefähr zu den 2MB L2 der unteren Kerne.
Also ich geh schwer davon aus, dass es so ist. Alles andere ergibt ja keinen Sinn ;)
Warum zum Henker sind die beiden oberen Module größer als die unteren?
Hier mal von mir schlampig entzerrt:
http://a.imageshack.us/img829/8818/orochidie.jpg (http://img829.imageshack.us/i/orochidie.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Alleine schon die riesigen Leerräume zwischen den Funktionblöcken zeigen das es sich hier bestenfalls um einen Prototypen handeln kann. Einen solchen Luxus kann sich schon lange niemand mehr leisten.
jetzt fehlen uns nur noch Benches eines 4 Modul BD @5Ghz :D
jetzt fehlen uns nur noch Benches eines 4 Modul BD @5Ghz :D
lol mit LN2 schafft ein Phenom2 7 Ghz+
für BD erwarte ich mit LN2 den 10 Ghz Record
Gasti
2010-09-01, 20:44:32
lol mit LN2 schafft ein Phenom2 7 Ghz+
für BD erwarte ich mit LN2 den 10 Ghz Record
Und was hat Das für eine Relevanz?
=Floi=
2010-09-01, 20:46:57
http://www.pcper.com/images/reviews/991/orochidie.jpg
das ist imho eine optische täuschung.
SavageX
2010-09-01, 20:53:51
http://www.pcper.com/images/reviews/991/orochidie.jpg
das ist imho eine optische täuschung und das entzerrte bild lügt hier. die fluchtlinien passen und auch beide cores scheinen gleich groß zu sein. imho resultieren die unterschiede zwischen oben und unten aus irgendeinem chipteil, welchen man nicht spiegeln kann.
wenn man die cache-pakete zählt, dann sind die gleich.
Wenn man beispielsweise die Anzahl der "hellen Pakete" an den jeweils äußeren Modulrändern mal oben und mal unten zählst, dann kommt man auf unterschiedliche Zahlen.
Wäre auch eine seltsame Verzerrung, die dafürt sorgt, dass die am Die-Rand befindlichen Modulgrenzen oben und unten passen, aber die "inneren" Modulgrenzen nicht.
edit: Oh, und oben und unten sind die L3-Stücke gleich groß und man sieht, dass die Module unten/oben ihren inneren Rand an unterschiedlichen "L3 Positionen" haben.
Undertaker
2010-09-01, 21:02:12
Ganz egal ob man von den oberen oder unteren Modulen ausgeht: Die Kerne scheinen doch recht kräftig gewachsen zu sein (fertigungsbereinigt). Während beim K10.5 die Kerne noch etwas größer als 2x512kB L2 Cache sind (http://extreme.pcgameshardware.de/members/kbasti-albums-k10-deneb-amd-phenom-ii-1007-picture12203-k10-deneb-45nm-architektur.jpg), wären sie (inkl. CMT, also bessergesagt ein Modul) obigem Bild nach bei Bulldozers spekulierten 2MB L2/Modul etwa auf das Doppelte gewachsen (ganz ganz grob abgeschätzt). Das kann man sich in 32nm natürlich locker leisten, aber wirklich klein dürfte so ein 4-Modul Modell nicht werden.
Laut Charlie ist Orochi die zweite Fusion Generation.
4 Module sind doch kleiner als ein thuban oder?
http://a.imageshack.us/img210/148/orochidieshot1.jpg
http://a.imageshack.us/img294/8818/orochidie.jpg
von hier: http://forum.beyond3d.com/showthread.php?t=54018&page=13
SavageX
2010-09-01, 21:19:11
Sehr schön. Scheint, jemand mag auch hier die unteren Modulen etwas lieber ;)
gibt es vorteile oder nachteile?
http://a.imageshack.us/img210/148/orochidieshot1.jpg
Wenn der L2-Cache 2MB hat dann sollte er ca. 12mm² groß sein (beim Llano sind 1MB ca. 6mm² groß) Das untere rechte Modul wäre dann ohne L2 Cache ca. 20mm² groß, incl. L2 also 32 -33 mm²
Das gesamte Die wäre ca. 337 mm² groß! Ziemlicher Brummer!
Also daran die Die-Größe richtig einzuschätzen wäre schon eine heroische Leistung wenn es nachher stimmt.
ich erwarte gar nicht, das die Die-Größe wirklich stimmt. Aber die Richtung >300m² ist aus meiner Sicht zu viel des guten. Kleiner wäre besser für AMD.
Es gibt aber Stimmen im Netz die sagen, das es sich um eine Art early Prototypen handelt. Deshalb sollen auch die oberen Module größer sein als die unteren. Andere wiederum schieben es auf eine integrierte GPU (glaube ich aber nicht).
Hier noch ein wenig Porx:
http://i55.tinypic.com/2nvcpcj.jpg
Vom aces-hardware forum; zusammen mit dem Link für die Präsentation:
http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9NjExNDN8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1
Eine intergrierte GPU würde definitiv anders aussehen.
Meine wilde Spekulation:
oben (echte) 256bit AVX FPUs mit schnellen 6T L2 Zellen, unten 128bit AVX (eventuell das alte SSE5 Orginaldesign) mit stromsparenden 8T L2 Zellen.
Grund: Links und rechts schauts bei allen Modulen recht gleich aus, das sollten also die INT Custer sein, nur mittig ist was kopiert, müßte dann die FPU sein.
Andere Erklärung: Nur die oberen Teile haben eine alten x87 Legacy FPU eingebaut ?
(aber dazu ist das zu gleichmäßig sind eigentlich die gleichen Strukturen).
für den richtigen Bulldozer braucht AMD noch ne menge Zeit, nicht das BD ein Flop wie Barcelona wird, damals hatte AMD auch zuwenig Zeit ;)
Undertaker
2010-09-01, 22:35:56
Also die L2 Caches sehen selbst oben links und rechts unterschiedlich aus - insofern kann da auch alles nur etwas schlampig "gephotoshopped" sein und in Wirklichkeit sind alle Module identisch gewesen...
einige behaupten auch das ein BD Modul ein K8 mit 2 integer einheiten ist, der rest soll aber auch nicht komplett neu sein, AMD soll nach 2007 mit BD große Probleme wegen AVX gehabt haben, der ursprüngliche BD war nur ein doppel K9 mit 8 integers, für AMD damals zu langsamm gewesen, es scheint alles nur ein schnell geworfenes Design mit vielen schwachstellen zu sein.
*Gastignorier*
Mhh, aber ob AMD in nem PDF ein Orochi Die zeigt welches später anders aussieht will ich nicht glauben...
Andere Erklärung: Nur die oberen Teile haben eine alten x87 Legacy FPU eingebaut?
Es gibt keine "legacy FPU". Das sind die selben Einheiten und Registerfiles.
einige behaupten auch das ein BD Modul ein K8 mit 2 integer einheiten ist
Kompletter Unsinn.
Es gibt keine "legacy FPU". Das sind die selben Einheiten und Registerfiles.
Stimmt auch wieder, nach den Decoder ist ja alles nur ne intere MacroOp.
Also wenn dann nur 128/256, oder hast Du noch ne Idee ?
@Undertaker:
Dachte ich zuerst auch, aber in der Mitte eines Moduls ist bei den 2 obigen Teilen definitiv "mehr". Kann natürlich jetzt auch per Photoshop kopiert sein, aber wieso sollte man das tun, und dann noch den L2 Cache skalieren ?
Um die Konkurrenz zu verwirren. Wäre schon ne Option.
Um die Konkurrenz zu verwirren. Wäre schon ne Option.
was für eine Option? Bulldozer kommt irgendwann im Q3 oder Q4 2011, bis dahin hat Intels schon 8 Core SB CPUs im Handel, bei Intel wird es keine Bugs oder Probleme geben!!! Bulldozer muss erstmal auf Nehalem höhe aufschließen und das wird nichtmal reichen, AMD kann nur Intel mit einem erfolgreichen hochtakt Design und fetten Module überraschen!
Gestrandet
2010-09-01, 23:04:46
einige behaupten auch das ein BD Modul ein K8 mit 2 integer einheiten ist, der rest soll aber auch nicht komplett neu sein, AMD soll nach 2007 mit BD große Probleme wegen AVX gehabt haben, der ursprüngliche BD war nur ein doppel K9 mit 8 integers, für AMD damals zu langsamm gewesen, es scheint alles nur ein schnell geworfenes Design mit vielen schwachstellen zu sein.
Wie geil ... ;D
Bester Gast-Beitrag seit langem! (y)
was für eine Option? Bulldozer kommt irgendwann im Q3 oder Q4 2011, bis dahin hat Intels schon 8 Core SB CPUs im Handel, bei Intel wird es keine Bugs oder Probleme geben!!! Bulldozer muss erstmal auf Nehalem höhe aufschließen und das wird nichtmal reichen, AMD kann nur Intel mit einem erfolgreichen hochtakt Design und fetten Module überraschen!
eben selbst AVX/XOP/FMA sind für AMD nutzlos, P4 hatte SMT hat aber nichts gebracht, bei Nehalem bringt SMT gleich 25%, bei Clarkdale noch effizienter
dazu kommt noch das Intel die aktuellen 65/45nm Anlagen auf 22nm umbaut, das wird AMD erst gegen 2012 schaffen!
Das interessante ist doch, was AMD in der Zwischenzeit noch in Petto hat.
Gibt es denn überhaupt ein Zwischenprodukt bis Bulldozer ?
Thuban bleibt laut amdzone bis April das high end von AMD.
Thuban bleibt laut amdzone bis April das high end von AMD.
na dann gute nacht
das waren noch Zeiten http://www.computerbase.de/news/hardware/prozessoren/amd/2008/november/erste-amd-shanghai-benchmarks-ueberzeugen/
Um die Konkurrenz zu verwirren. Wäre schon ne Option.
Naja .. dann wärs aber ja kein Orochi Die mehr - oder Orochi ist nur ein Fantasie/Prototypengebilde, und Zambezi/Valencia basieren auf was anderem.
Komisch auf alle Fälle, mal schauen was Hans de Vries schreibt.
Edit: Verdammt viel Spam hier ... :(
Der_Korken
2010-09-01, 23:28:25
eben selbst AVX/XOP/FMA sind für AMD nutzlos, P4 hatte SMT hat aber nichts gebracht, bei Nehalem bringt SMT gleich 25%, bei Clarkdale noch effizienter
Das stimmt nicht. In einigen Anwendungen hat SMT (damals noch HT) dem P4 sehr wohl einen Leistungsschub gebracht. Auch in Spielen (http://www.3dcenter.org/artikel/hyperthreading-vs-dualcore-spielen), wobei diese erst zwei Threads richtig genutzt haben, als der Core2 schon längst draußen war (und Dualcore P4 erst recht). Man braucht nur genug Threads, du sagst ja selbst dass es bei Clarkdale (2 Cores) mehr bringt, als bei Nehalem (4 Cores). 4 Threads sind leichter zu beschaffen, als 8.
http://a.imageshack.us/img266/6173/01192453925l1.jpg
Also das passt schon irgendwie:-)
jfruehe/
That is an 8-core Orochi.
And some blurring.
And some photoshopping.
Actual die shots are released at launch, not before. Don't start doing math on this, if you think the "single threaded client performance from a server benchmark" numbers were way off, anything done off of this die shot will be even more incorrect.
=Floi=
2010-09-02, 02:34:45
muhahaha ;D Das bild ist ja der brüller.
eben selbst AVX/XOP/FMA sind für AMD nutzlos, P4 hatte SMT hat aber nichts gebracht, bei Nehalem bringt SMT gleich 25%, bei Clarkdale noch effizienter
Sollte M$ den Kram, vor allem FMA, in deren Compiler integrieren, ist das alles andere als nutzlos. Alle Compilerhersteller bis auf Intels ICC werden von FMA profitieren.
SMT ist mit solchen Erweiterung i.Ü. garnicht vergleichbar.
@Mods: bitte mal aufräumen hier, ist ja furchtbar.
@Mods: bitte mal aufräumen hier, ist ja furchtbar.Wäre ich auch dafür, Qualcomm & Handys haben nichts im Bulldozer Thread zu suchen (Vom Gäste SPAM ganz zu schweigen) :)
Ich hab mich mal an nem Layout versucht, ist sicher falsch, Verbesserungsvorschläge erwünscht:
http://www.abload.de/img/test2a885.jpg
Gründe:
a) Layout wie in den Patenten, FPU zw. 2 INT Cores
b) INT Cores sollten relativ klein sein (man könnte wohl die LD/Str Teile noch mit dazu nehmen)
c) Decode ist traditionell bei x86 ein großer Batzen, und das wird jetzt mehr.
Das wars dann auch schon .. ;-)
Überhaupt nicht sicher bin ich mir beim Dispatch, das wär ein relativ großer Teil, stört mich etwas, vielleicht gehört das schon zur FPU. Aber da liegen außen reihum kleine Blöcke, dass könnten die Puffer zu den INT/FP ExUnits sein ...
ciao
Alex
Ailuros
2010-09-02, 13:01:03
Ontario relevante Posts in den relevanten Thread verschoben.
SavageX
2010-09-02, 13:06:24
Ich hab mich mal an nem Layout versucht, ist sicher falsch,
Das sieht mir schon ganz gut aus, aus dem Gematsche wird man nicht viel weiser werden können.
Gründe:
a) Layout wie in den Patenten, FPU zw. 2 INT Cores
Und welchen Grund gibt es dafür, die beiden INT-Cores wirklich zu teilen und links und rechts von der FPU zu platzieren? Dresdenboy hat mal angemerkt, das es wahrscheinlich anders aussehen wird: Die beiden INT-Cores sind vielleicht nebeneinander platziert und die FPU auf die Seite "geschoben".
IMHO sind folgende Gründe möglich:
- bessere Ausnutzung der INT-Cores (vielleicht kann man sie in einer zukünftigen Version des BD doch zusammenschalten).
- die FPU wird laut Bericht von David Kanter ja als Coprozessor angebunden => wird vielleicht in Zukunft durch die GPU-Cores ersetzt oder ergänzt.
Und welchen Grund gibt es dafür, die beiden INT-Cores wirklich zu teilen und links und rechts von der FPU zu platzieren?
Signallaufzeiten.
Das mit dem Coprozessor halte ich übrigens für Blödsinn. Nur weil die FPU einen eigenen Scheduler hat ist sie das noch lange nicht.
Auch das die GPU-ALUs direkt in die CPU integriert werden ist hanebüchener Blödsinn. Das zeugt nicht gerade von Verständnis des Autors an diesem Punkt.
SavageX
2010-09-02, 15:56:15
Da die FPU (beispielsweise) ihre Resultate über die Integer-Kerne schreibt, würde ich ein symmetrisches Setup, so die Signalpfade zu beiden Kernen gleich lang sind, als natürlicher empfinden - also FPU in der Mitte, Integer links und rechts spiegelverkehrt zueinander.
Und welchen Grund gibt es dafür, die beiden INT-Cores wirklich zu teilen und links und rechts von der FPU zu platzieren? Dresdenboy hat mal angemerkt, das es wahrscheinlich anders aussehen wird: Die beiden INT-Cores sind vielleicht nebeneinander platziert und die FPU auf die Seite "geschoben".
IMHO sind folgende Gründe möglich:
- bessere Ausnutzung der INT-Cores (vielleicht kann man sie in einer zukünftigen Version des BD doch zusammenschalten).
Lol, den Floh hab ich ihm damals ins Ohr gesetzt, aus dem gleichen Grund den Du genannt hast.
Aber in dem Foto ist das eindeutig, schau Dir die Symmetrie an, da sind jeweils am linken Eck vom Core 0 und am rechten vom 1er die Caches / Register. Da gibts nichts mehr zu rütteln.
Codas Argument ist auch stimmig, die FPU wird ja geteilt ... da ist es am besten, wenn sie dazwischen ist :)
Ist ausserdem eventuell auch von der Abwärme her besser. Die FPU sollte kühler sein, da sie nicht so oft benutzt wird, vielleicht laufen die INT Teile auch noch @doppelten Takt, wer weiss ..
ciao
Alex
Aber in dem Foto ist das eindeutig, schau Dir die Symmetrie an, da sind jeweils am linken Eck vom Core 0 und am rechten vom 1er die Caches / Register. Da gibts nichts mehr zu rütteln.
Foto, welches Foto? eher wohl gephotoshoptes Bildchen ;)
Die AMD Mitarbeiter können jetzt nicht wissen wie BD in 1 Jahr takten wird, das ganze ist noch in arbeit, erst im 1. Halbjahr 2011 können Angaben zu Taktraten in Netzt geraten.
Magny Cours wurde unterschätzt, als er vermarktet wurde war er viel schneller als AMD selber gedacht hat, das gleiche wird auch mit Bulldozer so sein, er wird schneller schneller schneller, diese Screens von einem angeblichen Orochi die sind laut AMD mitarbeiter gefälscht, AMD kann aber nicht Intel täuschen, die wissen schon über BD bescheid.
Gestrandet
2010-09-03, 01:29:56
Die AMD Mitarbeiter können jetzt nicht wissen wie BD in 1 Jahr takten wird, das ganze ist noch in arbeit, erst im 1. Halbjahr 2011 können Angaben zu Taktraten in Netzt geraten.
Magny Cours wurde unterschätzt, als er vermarktet wurde war er viel schneller als AMD selber gedacht hat, das gleiche wird auch mit Bulldozer so sein, er wird schneller schneller schneller, diese Screens von einem angeblichen Orochi die sind laut AMD mitarbeiter gefälscht, AMD kann aber nicht Intel täuschen, die wissen schon über BD bescheid.
Hmmm ... dann hätten die AMD vlt. mal bei Intel nachfragen sollen, dann wär BD sicher schneller fertig geworden :biggrin:
Update: We asked AMD about this picture and its possible meaning, and we got a cryptic but possibly helpful answer. It was pointed out to us that PC Perspective did not publish a picture of the Orochi die, but a snapshot of an image shown at the event. We understand parts of that image were "obscured" for "competitive reasons," whatever that means.
Also doch so, wie ich gedacht hatte ;)
AMD kann aber nicht Intel täuschen, die wissen schon über BD bescheid.
Also ich erinnere mich an eine Story über angeblich sehr hektisch telefonierende Intel-Mitarbeiter bei der K8-Vorstellung. Sei dir da mal nicht so sicher.
BlackBirdSR
2010-09-03, 07:51:46
Also doch so, wie ich gedacht hatte ;)
Also ich erinnere mich an eine Story über angeblich sehr hektisch telefonierende Intel-Mitarbeiter bei der K8-Vorstellung. Sei dir da mal nicht so sicher.
Du erinnerst dich zu spät.
Das war zum Release der K7-Infos ;)
Signallaufzeiten.
Das mit dem Coprozessor halte ich übrigens für Blödsinn. Nur weil die FPU einen eigenen Scheduler hat ist sie das noch lange nicht.
Auch das die GPU-ALUs direkt in die CPU integriert werden ist hanebüchener Blödsinn. Das zeugt nicht gerade von Verständnis des Autors an diesem Punkt.
Das seh ich aber anders. Ein echter Fusion muss die GPU-ALUs irgendwo integrieren - die einzig logische Stelle ist die FPU. Man würde dann eine Art Hybrideinheiten basteln müssen, um die FPU-Standards einzuhalten.
robbitop
2010-09-03, 10:44:39
Die GPU-ALUs sind dort wo sie hingehören - in der GPU (bzw. im Bereich des Dies auf dem die GPU liegt). Auch hier gilt: Signallaufzeiten!
Die GPU ALUs sind eh kein Ersatz für die FPU der CPU. Die können nur eines: viele parallele Dinge ausführen. Aber seriell - eher schlecht. Und bei dem was sie gut können (ersteres) ist es auch nicht weiter tragisch, wenn sie im GPU-Teil sind, da es bei diesen Anwendungen m.M.n. kaum auf die Latenz zw. CPU und GPU ankommt (und diese dank Vorhandensein auf dem gleichen Die vermutlich immer noch locker gering genug sind).
BlackBirdSR
2010-09-03, 12:12:04
Das seh ich aber anders. Ein echter Fusion muss die GPU-ALUs irgendwo integrieren - die einzig logische Stelle ist die FPU. Man würde dann eine Art Hybrideinheiten basteln müssen, um die FPU-Standards einzuhalten.
Ein solcher Fusion (GPU-Einheiten direkt im Backend der CPU) wird wohl noch sehr lange dauern.
Dann muss plötzlich alles mit durchs Frontend, stell ich mir grausam vor...
Das seh ich aber anders. Ein echter Fusion muss die GPU-ALUs irgendwo integrieren - die einzig logische Stelle ist die FPU.
Nein, das ist ganz und gar nicht logisch. Auf GPUs laufen tausende von Threads und noch dazu völlig anderer Code mit völlig anderen Latenzen und Anforderungen an das Scheduling.
Was soll das bitte an einem Port des x86-Schedulers zu suchen haben?
Ein solcher Fusion (GPU-Einheiten direkt im Backend der CPU) wird wohl noch sehr lange dauern.
Won't happen. Die Integration wird sich auf einen shared L3 beschränken.
robbitop
2010-09-03, 13:38:15
Bringt der Shared L3 (zw. GPU und CPU) eigentlich der GPU hinsichtlich ganz normaler D3D-Grafikberechnung etwas? (siehe Sandybridge)
y33H@
2010-09-03, 13:53:51
Die GPU kann den L3 iirc mit nutzen, also Daten reinpacken.
Bringt der Shared L3 (zw. GPU und CPU) eigentlich der GPU hinsichtlich ganz normaler D3D-Grafikberechnung etwas? (siehe Sandybridge)
Cypress hat 512KiB L2 und GF100 768KiB. Cache scheint also auch bei GPUs was zu bringen.
robbitop
2010-09-03, 14:29:19
Cypress hat 512KiB L2 und GF100 768KiB. Cache scheint also auch bei GPUs was zu bringen.
Dass GPUs über Caches verfügen, ist mir klar. Aber ist der L3 Cache dafür denn überhaupt geeignet (Durchsatz/Latenz)? Ich ging davon aus, dass man den L3 Cache evtl. als Tilecache nutzen könnte oder als anderen inkonventionellen Puffer, der die Framebufferbandbreite entlastet. Genau deshalb frage ich. ;)
Won't happen. Die Integration wird sich auf einen shared L3 beschränken.
Das sieht AMD aber anders. Schon beim ATi Erwerb gab AMD bekannt das am Ende die vollkommen Verschmelzung steht.
Das sieht AMD aber anders. Schon beim ATi Erwerb gab AMD bekannt das am Ende die vollkommen Verschmelzung steht.
Ich glaube nicht das AMD das gemeint hast was du damit meinst ;)
Ich ging davon aus, dass man den L3 Cache evtl. als Tilecache nutzen könnte oder als anderen inkonventionellen Puffer, der die Framebufferbandbreite entlastet. Genau deshalb frage ich. ;)
AMD hat keine TBR-Architektur.
Das sieht AMD aber anders. Schon beim ATi Erwerb gab AMD bekannt das am Ende die vollkommen Verschmelzung steht.
Vollkommener kann man aber nichts verschmelzen. Die GPU-Logik hat in der CPU nichts zu suchen. Das sind völlig andere Ansätze.
robbitop
2010-09-03, 15:06:57
Also ist der Anteil am L3-Cache weder bei Sandybridge noch bei Fusion nutzbar, um Bandbreite zum VRAM zu sparen?
Bist du dir sicher, dass der L3-Cache der CPU sinnvoll für die L2 Caches der GPUs sind?
@ Gast #953
Nein das hast du falsch verstanden, es war seitens AMD schon immer so gemeint, dass der Grafikchip ein eigener Kern bleibt, der natürlich gewisse Dinge mit dem x86-Kern teil (MC und L3).
Am Ende des Weges wird man vermutlich Instruktionen für GP-Cumputing standardisieren damit man mit Compilern nativen Code für die GPU (mit)generieren kann, für alles andere (2D, 3D etc) wirds dann immer noch Treiber brauchen. Der letzte Teil wird aber noch ein paar Jahre dauern und dann haben wir eben Prozesorren mit verschiedenen Kernen, zumindest hoff ich das, weil auf Ansätze wie Polaris kann ich aus Desktopsicht verzichten ;)
@ robbitop
Klar kann man die Caches nutzen, dafür muss es kein TBR sein.
AMD hat keine TBR-Architektur.
AMD behauptet was anderes:
http://developer.amd.com/gpu_assets/gdc2008_ribble_maurice_TileBasedGpus.pdf
Am Ende des Weges wird man vermutlich Instruktionen für GP-Cumputing standardisieren damit man mit Compilern nativen Code für die GPU (mit)generieren kann
Das gibt's jetzt schon. Nennt sich CAL.
AMD behauptet was anderes:
http://developer.amd.com/gpu_assets/gdc2008_ribble_maurice_TileBasedGpus.pdf
Och Leute.
Das ist eine embedded GPU für Smartphones. In Fusion kommt ein Radeon-Derivat.
Och Leute.lol, also wenn jemand anderes Unsinn behauptet du es besser weisst, kommt gleich "Blödsinn/Unsinn/usw." ... "Nein, dazu brauch ich nichts sagen, es ist Blödsinn, fertig".
jetzt aber behauptest du selbst AMD hat keine TBDR GPUs, trotz tatsachen:
Das ist eine embedded GPU für Smartphones. In Fusion kommt ein Radeon-Derivat.ROPs arbeiten auch mit Tiles und jede GPU hat einen tile-cache, schon alleine weil die Tiles weit mehr Pixel beinhalten als die granularität der Quads ist, die die Shadereinheiten abarbeiten.
Wenn es der CPU nicht schaded kann die GPU also durchaus nutzen vom L3 haben, gerade beim langsamen cpu-ram (in relation zu on-board gpu memory).
Na CAL ist nicht ganz was ich meine. Ich sprech schon auf ISA-Level, sonst muss ich für jede GPU extra kompilieren oder ich brauch einen Treiber. Kein Teil der ISA von Evergreen ist standardisiert und wird gesichert auch auf einer 2013er GPU laufen und da lass ich die ständig wechselnden Registeroffsets schon beiseite.
Warum sollte man sich auf eine rigide ISA festlegen mit allen ihren Nachteilen, wenn man das einfach in Software abstrahieren kann?
Won't happen.
jetzt aber behauptest du selbst AMD hat keine TBDR GPUs, trotz tatsachen
Ich kenn die embedded GPUs von AMD. Ich erwähnte sich bzgl. Fusion absichtlich nicht, weil es nichts zur Sache tut.
Die D3D10- und D3D11-GPUs von AMD sind keine TBRs und es sieht auch nicht danach aus, als würde sich das ändern.
ROPs arbeiten auch mit Tiles und jede GPU hat einen tile-cache, schon alleine weil die Tiles weit mehr Pixel beinhalten als die granularität der Quads ist, die die Shadereinheiten abarbeiten.
Ein Nicht-TBR schreibt beim Rastern unverhersehbar an beliebige Stellen im Framebuffer, da funktioniert ein Tile-Cache ala Larrabee nicht.
Die Tiles die du meinst beziehen sich auf die Blockkompression und den hierarchischen Z-Buffer.
Wenn es der CPU nicht schaded kann die GPU also durchaus nutzen vom L3 haben, gerade beim langsamen cpu-ram (in relation zu on-board gpu memory).
GPUs nützt Cache viel weniger, weil sie Latenzen viel besser verstecken können. NVIDIA hat eine vollständige Cache-Hierarchie überhaupt erst mit Fermi eingeführt.
Das gibt's jetzt schon. Nennt sich CAL.
Och Leute.
Das ist eine embedded GPU für Smartphones. In Fusion kommt ein Radeon-Derivat.
Och Mann, schon der R300 hatte 8x8 große Tiles.
Was du meinst ist ein TBDR, oder?
Och Mann, schon der R300 hatte 8x8 große Tiles.
Das betrifft den Rasterizer und am Ende das Hier-Z. Das ändert aber nichts daran, dass nicht ein Tile nach dem anderen abgearbeitet wird wie bei einem TBR.
Die Writes in den Framebuffer sind völlig beliebig bei einem IMR.
Was du meinst ist ein TBDR, oder?
Nein. Das deferred hat damit nur begrenzt was zu tun.
LRB und diese AMD-Embedded-GPU teilen zuerst die Geometrie in Tile-Bins auf und rendern dann alle Dreiecke eines Tiles in traditioneller Weise, können dabei aber den Framebuffer für dieses Tile komplett im Cache lassen.
Dann muss plötzlich alles mit durchs Frontend, stell ich mir grausam vor...
So wies nach den Patenten aussieht, nur durch den Fetchteil.
Was soll das bitte an einem Port des x86-Schedulers zu suchen haben?
Wer sagt denn, dass die GPU Oops an den x86 Scheduler kommen ?
Das wäre in der Tat grausam :eek:
Aber laut Patenten ist das nicht der Fall.
Gemeinsamer Fetch, und dann getrennt in Richtung x86 Decoder bzw. in Richtung GPU Dekoder (was auch immer das im VLIW Fall genau ist).
ciao
Alex
P.S: Das Topic ist eigentlich Bulldozer nicht Fusion ^^
Gemeinsamer Fetch, und dann getrennt in Richtung x86 Decoder bzw. in Richtung GPU Dekoder (was auch immer das im VLIW Fall genau ist).
Was willst du da gemeinsam "fetchen"?
Es ist ein völlig anderes Programm, dass die GPU ausführt und noch dazu laufen die GPU-Cluster auch völlig unabhängig, d.h. sie führen auf ihren ALUs unterschiedliche VLIW-Instructions zu einem Zeitpunkt aus.
Aber bitte zeig mir mal das gemeinte Patent. Ich interpretier das lieber selber.
BlackBirdSR
2010-09-03, 19:36:11
Was willst du da gemeinsam "fetchen"?
Es ist ein völlig anderes Programm, dass die GPU ausführt und noch dazu laufen die GPU-Cluster auch völlig unabhängig, d.h. sie führen auf ihren ALUs unterschiedliche VLIW-Instructions zu einem Zeitpunkt aus.
Aber bitte zeig mir mal das gemeinte Patent. Ich interpretier das lieber selber.
eben...
man kann es drehen und wenden wie man will. Mir will so gar nicht in den Sinn, wie große Teiler eine GPU in die CPU wandern sollen.
x87 erzeugt ja schon einiges an Aufwand und wenn man sieht, mit wie viel Aufwand AMD und Intel ihre Fetches und Load+Store Kapazitäten ausweiten, dann wirkt jeder Zugriff durch CPUs einfach nur störend.
Ich will mir gar nicht vorstellen, wie extrem der Einfluss einer GPU auf das Prefetching und Predecoding wäre...
@S940
Solange es ein interessantes Thema mit Diskussion ist, darf es auch mal nen Umweg nehmen . AUch in deinem Interesse oder? ;)
Hmm ok, vielleicht war auch der Fetch getrennt, ist ca. 1 Jahr her, dass ich das gelesen hatte.
Ich such mal ...
Edit:
Jupp, auch Fetch getrennt:
http://www.abload.de/img/fusion_patent6mp3.jpg
Begrifferklärung auf die Schnelle:
GEU ist die Grafik ExU
JBU ist ne JavaByte ExU
Rest sollte klar sein.
Viel Spass beim lesen, Patentlink:
http://www.freepatentsonline.com/20090160863.pdf
Da sind auch noch Schemata drin, bei der die GPUs und der andere Krams am Router/XBAR hängen, sowas dürften wohl die kommenden Fusions sein.
ciao
Alex
P.S: Ich bin immer gerne für Kompromisse zu haben, musste aber feststellen, dass das hier im 3DC eher die Ausnahme ist ... entweder man hat Regeln und jeder hält sich dran, oder man sieht alles für jeden etwas "entspannter". Die Realität ist, dass die Mods machen, was sie wollen ^^ Aber naja, die Bezahlung ist ja auch miserabel und ich zahle auch keinen Cent für irgendwas, von daher nehm ichs hin, geschenkter Gaul und so ;-)
Ich interpretiere das Patent bisher so, dass die GEU direkt Draw-Call-Anweisungen etc. vom CPU-Scheduler bekommen kann.
Das bedeutet nicht, dass die GPU-ALU in die CPU integriert wird. So ergibt es auch halbwegs Sinn, denn damit spart man sich die Latenz des PCI-Bu bei Drawcalls.
VLIW-Instructions durch den CPU-Scheduler zu schleußen ist nicht sinnvoll. Das würde die "GPU" zu einer sehr breiten Vektor-ALU der CPU machen, und würde sämtliche Vorteile der Streamprozessor-Architektur beseitigen.
Edit: Ich sehe da auch Probleme was das Windows-Treibermodell angeht. Das funktioniert bisher nur mit PCI-GPUs, wenn ich mich nicht täusche.
Warum sollte man sich auf eine rigide ISA festlegen mit allen ihren Nachteilen, wenn man das einfach in Software abstrahieren kann?
Won't happen.
Weils sonst keine heterogenen Mehrkernprozessoren geben wird, sondern nur x86 + IGP. Nicht in jedem Marktsegment ist "einfache Softwareabstraktion" gewünscht. Bei Großrechnern/Clustern kann ich auf noch einen zusätzlichen Softwarestack verzichten. Da nehm ich, sofern das Anwendungsgebiet passend ist, gleich dedizierte Karten und etwaige GPU/SIMD-Kerne können sich Intel und AMD sparen.
Weils sonst keine heterogenen Mehrkernprozessoren geben wird, sondern nur x86 + IGP
Definiere "heterogen" in diesem Zusammenhang. Der Streamprozessor wird wohl immer ein anderes Programm ausführen, von daher ist das kein Argument.
Bei Großrechnern/Clustern kann ich auf noch einen zusätzlichen Softwarestack verzichten.
Die Vorteile gäbe es zwar, allerdings wird das sehr durch die zusätzlichen Transistoren für die Abwärtskompatibilität aufgefressen. Ich glaube nicht dass es passiert.
Da nehm ich, sofern das Anwendungsgebiet passend ist, gleich dedizierte Karten und etwaige GPU/SIMD-Kerne können sich Intel und AMD sparen.
Der primäre Vorteil der Integration ist eine viel kürzere Latenz beim Austausch der Daten. Das schränkt derzeit massiv ein. Beispielsweise ist ein Readback innerhalb eines Frames bei 3D-Rendering ein absolute No-Go.
GPUs nützt Cache viel weniger, weil sie Latenzen viel besser verstecken können. NVIDIA hat eine vollständige Cache-Hierarchie überhaupt erst mit Fermi eingeführt.
Ist das so schwer zu verstehen?:usad:
hier geht es um bandbreite, nicht latenz, die auch noch mit der CPU geteilt wird. Da ist nichts mit verstecken, und cache hilft in diesem fall.
CrazyIvan
2010-09-07, 17:30:37
Öhm, dann aber nur bei kurzen Bursts. Bei Bandbreite gilt das schwächste Glied in der Kette - Cache hin oder her.
Ist das so schwer zu verstehen?:usad:
hier geht es um bandbreite, nicht latenz, die auch noch mit der CPU geteilt wird. Da ist nichts mit verstecken, und cache hilft in diesem fall.
Cache hilft, wenn innerhalb kurzer Zeit auf gleiche Daten zurückgegriffen wird. Das ist bei GPUs viel weniger der Fall als bei CPUs.
GPUs hilft Cache vor allem bei GPGPU, viel viel weniger bei 3D-Rendering.
Öhm, dann aber nur bei kurzen Bursts. Bei Bandbreite gilt das schwächste Glied in der Kette - Cache hin oder her.
Die interne Bandbreite des Caches ist ja höher. Das hilft schon in den Fällen in denen der Cache tatsächlich was bringt.
Gipsel
2010-09-07, 20:16:05
Cache hilft, wenn innerhalb kurzer Zeit auf gleiche Daten zurückgegriffen wird. Das ist bei GPUs viel weniger der Fall als bei CPUs.
GPUs hilft Cache vor allem bei GPGPU, viel viel weniger bei 3D-Rendering.
Gegenbeispiel mit überwältigender Bedeutung ist die Texturfilterung. Ohne Caches wären da GPUs deutlichst langsamer, die Datenlokalität ist sehr hoch, die Effizienz der Caches ebenfalls. Nicht umsonst verbauen AMD und nvidia da Caches mit aggregierten Bandbreiten von über 1 TeraByte pro Sekunde ;). Die benutzen sogar extra angepaßte Speicherlayouts der Texturen (raumfüllende Kurven (http://de.wikipedia.org/wiki/FASS-Kurve) [ATI traditionell eine Z- oder auch Lebesgue-Kurve, das kleinste Z entspricht genau einem Quad], auch die Rastereinheiten versuchen, die Pixel möglichst so in die Warps/Wavefronts zu packen), um die Nutzbarkeit der Caches zu erhöhen.
Schon klar. Für die Texturfilter reichen aber die lokalen Texture-Caches um das auszunutzen, dafür braucht man keinen riesigen L2.
Gipsel
2010-09-07, 20:32:19
Schon klar. Für die Texturfilter reichen aber die lokalen Texture-Caches um das auszunutzen, dafür braucht man keinen riesigen L2.
Ups, gar nicht gesehen, daß der Gast sogar von L3 schrieb.
Aber eine Anmerkung hätte ich da noch: Auch Immediate-Mode Renderer binnen heutzutage die Dreiecke schon vor dem eigentlichen Rastern in screenmapped Tiles (zumindest die mit mehr als einer Rastereinheit). Und auch ein ROPs sind nur für die ihm jeweils zugeordneten Screentiles zuständig (die Speicherzugriffe sind also nicht komplett zufällig, sondern nur innerhalb der jeweiligen Tiles). Außerdem gibt es Lokalität durch Dreiecke >1 Pixel und auch durch AA). Es ist also nicht so, daß ein ordentlicher Cache in/bei den ROPs gar nichts bringen würde. Aber daß das Kosten-Nutzen-Verhältnis der gemeinsamen Benutzung eines L3-Caches mit der CPU wohl eher sehr schlecht ausfallen dürfte, da hast Du natürlich Recht. Kleinere, spezialisiertere Caches stellen da momentan auf jeden Fall die deutlich bessere Lösung dar.
Bulldozer design team t-shirt: :D
http://img713.imageshack.us/img713/4127/ttdod4ik.png (http://img713.imageshack.us/my.php?image=ttdod4ik.png)
http://www.semiaccurate.com/2010/09/08/bulldozers-meet-t-shirts-california-sun/
y33H@
2010-09-08, 22:21:04
Was ich spannend finde: Wird Turbocore immer ein Modul hochtakten oder gar nur bestimme Integer-Cores? Letzteres wäre effizienter.
Was ich spannend finde: Wird Turbocore immer ein Modul hochtakten oder gar nur bestimme Integer-Cores? Letzteres wäre effizienter.
Irgendwo stand mal, dass es nur pro Modul ginge, aber ich hoffe mal, dass die elektrischen Änderungen bei AM3+ dafür da sind, dass es bei den Desktop Chips dann auch per Cluster ginge.
Alles andere wäre die Änderung/Inkompatibilität mMn nicht wert und AMD sprach ja von nem "Enthusiasten Feature".
ciao
Alex
Duplex
2010-09-08, 22:52:38
wenn 2 integer eines Modul zusammen als ein Core mit Turbo arbeiten könnten wäre das interessant, vielleicht gibt es sowas bei der nächsten Version, 2 integer verwandeln sich in ein großen Core :) dann hätte man in Single Thread riesen vorteile
y33H@
2010-09-08, 22:55:36
Zwei Integer in einen? Hä? :ugly:
Zwei Integer in einen? Hä? :ugly:
Er meint Speculative Multithreading (SpMT), 2 Cores arbeiten an einem Thread, kommt aber ganz sicher nicht in BD1. Hat zumindest JF verneint, und die Renamer sind pro Cluster, nicht pro Modul, das schließt das auch aus.
Duplex
2010-09-08, 23:01:26
genau das meine ich
auf der anderen Seite glaube ich das AMD mehr Cluster & mehr IPC bei BD2 auf den Modulen bezogen entwickelt, BD1 ist erstmal der Anfang, wenn BD in 1 Jahr ohne makken läuft und gute Leistung bietet reicht es erstmal für den Anfang, danach könnte es einen riesen großen Sprung geben, wichtig ist für AMD das BD ohne Nachteile vermarktet wird (man errinere sich an dem Barcelona debakel wo man wenig Zeit hatte und eben ein Design auf den Markt geklatscht hat welcher einen TLB Bug besaß und großen schaden für AMD war^^)
y33H@
2010-09-08, 23:18:10
@ S940
Ach so, das meinte er. Dachte selbst an was spezielleres :ugly: SpMT ist interessant - wo hat JF das verneint? =)
@ Duplex
Bis BD2 kommt, ist schon der 2te Nachfolger von Ivy da ;)
Duplex
2010-09-08, 23:29:27
@ y33H@
Ivy kommt doch erst mitte 2012, mit 22nm hat Intel noch keine erfahrung, die 2. Ivy Generation kommt bestimmt erst 2013, dann hat AMD schon gemeistert, woher willst du wissen ob Ivy Bridge überhaupt ein Renner wird? ist doch nur ein getunter Sandy der auch nur ein getunter Nehalem mit 10-15% IPC+ ist;) Intel wird mit sicherheit keine neue unabhängige Architektur mehr bauen die nicht mehr auf P6 Nehalem setzt, Sany Bridge & Ivy Bridge sind keine neuen Äste sondern Nehalem aufgusse
@ S940
Ach so, das meinte er. Dachte selbst an was spezielleres :ugly: SpMT ist interessant - wo hat JF das verneint? =)
Irgendwo auf amdzone, bin jetzt aber wirklich zu faul, um das rauszusuchen ^^ Ging darum, dass einer meinte, dass es ja toll wär, wenn 2 Cluster an einem Thread rechnen könnten. Das wurde dann von JF verneint.
Die Story mit dem Renamer hab ich noch offen, die ist hier:
http://groups.google.com/group/comp.arch/browse_thread/thread/1fc40fd72b695fe9#
Er meint Speculative Multithreading (SpMT), 2 Cores arbeiten an einem Thread, kommt aber ganz sicher nicht in BD1. Hat zumindest JF verneint, und die Renamer sind pro Cluster, nicht pro Modul, das schließt das auch aus.
Du meinst vielleicht diesen Thread (da hat JF-AMD aber nichts gepostet):
What happen with plans of AMD about "reverse hyperthreading" (http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137923&sid=ff3db1073721ee45aa6ae60777466a22)
Während der letzten Wochen habe ich mal ein wenig im Internet gesucht, was den alles möglich ist (SpMT; DMT; oder auch das hier: http://impact.crhc.illinois.edu/ece512/presentations05/mon02/kmalik.ppt)
Ergebnis (für mich):
Das ganze lohnt sich nicht. Meistens beträgt der Vorteil gerade mal 20-30%. Und das kann zB. Intel schon alleine mit ihrem Turbo-Mode erreichen. Klar so eine CPU würde bei gleicher Single-Thread-Leistung wahrscheinlich weniger verbrauchen aber da hat Intel ja ziemlich Luft.
Der_Korken
2010-09-09, 14:18:02
Das ganze lohnt sich nicht. Meistens beträgt der Vorteil gerade mal 20-30%. Und das kann zB. Intel schon alleine mit ihrem Turbo-Mode erreichen. Klar so eine CPU würde bei gleicher Single-Thread-Leistung wahrscheinlich weniger verbrauchen aber da hat Intel ja ziemlich Luft.
Der Turbo-Modus ist aber keine uneingeschränkte Alternative, denn was ist, wenn die CPU bereits so am Taktlimit läuft? Wenn ich eine 3Ghz-CPU habe, die um Turbo-Modus mal eben auf 3,6Ghz hochziehen soll, dann muss ich plötzlich nicht nur sicherstellen, dass jeder Kern 3 Ghz schafft, sondern dass er auch 3,6Ghz schafft. Vergleicht man zum Beispiel die i7 im Desktop und im Notebook, dann sieht man sehr deutlich, dass der Turbo-Modus (absolut) kleiner ausfällt, je höher der Grundtakt ist, weil die zu garantierende Taktrate sonst durch die Decke gehen würde.
Cache hilft, wenn innerhalb kurzer Zeit auf gleiche Daten zurückgegriffen wird. Das ist bei GPUs viel weniger der Fall als bei CPUs.
GPUs hilft Cache vor allem bei GPGPU, viel viel weniger bei 3D-Rendering.
Die meiste bandbreite zieht der Framebuffer. Texturen haben in relation dazu sehr wenig. mit PVRTC 2bit/texel mit DXT 4bit/texel, Framebuffer haben hingegen 32Bit Color+32 Bit Z und entsprechend verbrauchst du selbst wenn du bump+diffuse benutzt immer noch pro pixel 8mal mehr Framebuffer bandbreite als texturebandbreite.
Und Framebuffer haben sehr viele cachehits mit ordinaeren CPU caches, da dreiecke aufgrund der Vertexcache optimization sehr oft aneinander gezeichnet werden, dabei aber mehr abdecken als ein kleiner texturecache fassen kann. ein paar MB L3 kann da sehr viel bringen.
Das tolle ist zudem ein automatisches load balancing. wartet die CPU viel auf die GPU, wird die cpu den cache nicht nutzen beim spinnen. ist wiederrum die GPU viel idle, wird wohl die CPU die meisten cachelines beanspruchen.
xenos zeigt dass (ja mit expliziter verwaltung) ein dedizierter framebuffer-speicher viel bringt.
Du meinst vielleicht diesen Thread (da hat JF-AMD aber nichts gepostet):
What happen with plans of AMD about "reverse hyperthreading" (http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137923&sid=ff3db1073721ee45aa6ae60777466a22)
Nö, das war viel früher, der Thread ist ja schon relativ neu. Ausserdem wars 100% eine JF Äußerung ;-)
Das ganze lohnt sich nicht. Meistens beträgt der Vorteil gerade mal 20-30%. Und das kann zB. Intel schon alleine mit ihrem Turbo-Mode erreichen. Klar so eine CPU würde bei gleicher Single-Thread-Leistung wahrscheinlich weniger verbrauchen aber da hat Intel ja ziemlich Luft.Vielleicht hat sich AMD das ja auch gedacht ^^
@Der_Korken:
Naja, bei Turbo schalten ja ein paar Kerne ab, sodass der Rest mehr verbraten darf. Das klappt eigentlich immer, da bei den aktuellen CPUs nicht das Taktpotential der begrenzende Faktor ist, sondern der Stromverbrauch.
Auch Immediate-Mode Renderer binnen heutzutage die Dreiecke schon vor dem eigentlichen Rastern in screenmapped Tiles (zumindest die mit mehr als einer Rastereinheit).auch die mit einer rasterunit arbeiten auf "tiles", jedoch sind diese keine mit "binning" erstellten, sondern eher kacheln im cache. Die wahrscheinlichkeit dass, selbst von verschiedenen dreiecken, dieselben "tiles" wieder addressiert werden ist numal sehr gross und es waere nicht nur "dumm" die cachelines mittels "latenz hidding" zu laden, es gebe auch noch unmenge RAW hazards, da das rausschreiben abgewartet werden muesste vor dem reinladen und das bei einem rasterizierungs pattern (Wie in den von dir genannten kurven) die explizit diese lokalitaet ausnutzen wollen.
Es waere richtig kontraproduktiv.
Und auch ein ROPs sind nur für die ihm jeweils zugeordneten Screentiles zuständig (die Speicherzugriffe sind also nicht komplett zufällig, sondern nur innerhalb der jeweiligen Tiles).Nur Coda meint es anders :)
Außerdem gibt es Lokalität durch Dreiecke >1 Pixel und auch durch AA). Es ist also nicht so, daß ein ordentlicher Cache in/bei den ROPs gar nichts bringen würde.
sowas ist so selbstredent, dass die hersteller es garnicht erst sagen.
Alleine schon weil die Kompression wegen AA auch zeit kostet und nur "forfree" ist weil der cache genug tiles hat. Die kompressionen arbeiten ja nicht auf 2x2 pixeln oder sowas winzigem, sondern auf grossen tiles, damit man nicht unmengen von ram lokal halten muss nur um sich zu merken, ob ein framebuffer-tile komprimiert wurde oder nicht. (Und bei vielen MB an framebuffern die manche spiele ziehen und support von irren aufloesungen ala 2560x1200 kann selbst 1bit pro 2x2 tile der overkill sein wenn es "on die" ist.)
Aber daß das Kosten-Nutzen-Verhältnis der gemeinsamen Benutzung eines L3-Caches mit der CPU wohl eher sehr schlecht ausfallen dürfte, da hast Du natürlich Recht. Kleinere, spezialisiertere Caches stellen da momentan auf jeden Fall die deutlich bessere Lösung dar.
Wenn du die wahl hast, kein cache vs gemeinsammer cache, ich glaube dann gewinnt letzteres, oder?
Am ende ist es wie ein weiterer core, es kann sein dass sie sich den cache trashen und es langsammer wird, aber genau so kann es auch sein dass transistoren benutzt werden die sonst brach laegen.
zudem kann ich mir vorstellen dass ein treiber mittels der performance counter vom cache leicht die GPU zwischen caching und non-caching justieren kann. Gibt genug andere dinge die in treibern mittels PC justiert werden.
Aber eine Anmerkung hätte ich da noch: Auch Immediate-Mode Renderer binnen heutzutage die Dreiecke schon vor dem eigentlichen Rastern in screenmapped Tiles (zumindest die mit mehr als einer Rastereinheit).
Thank you Captain Obvious. Es werden bei einem IMR trotzdem Dreiecke so wie sie kommen gerendert und nicht zuerst nach Bins sortiert. Die Aufteilung ist doch nur zum Load-Balancing der Rasterizer da.
Das ist etwas völlig anderes als bei einem TBR.
Der_Korken
2010-09-09, 20:54:07
Naja, bei Turbo schalten ja ein paar Kerne ab, sodass der Rest mehr verbraten darf. Das klappt eigentlich immer, da bei den aktuellen CPUs nicht das Taktpotential der begrenzende Faktor ist, sondern der Stromverbrauch.
Aber was ist mit der Spannung? Die muss ab einer bestimmten Taktrate auch nach oben und ich behaupte mal ganz dreist, dass man die Standard-Spannung niedriger ansetzen könnte, wenn man den Turbo-Modus weglassen würde.
Dass der Verbrauch bei Teillast egal ist, leuchtet dagegen ein. Wenn ein Quadcore bei Auslastung aller Kerne eine TDP X hat, dann müsste der einzelne, übertaktete Kern so viel ziehen, wie alle im Standardtakt zusammen, um an X ranzukommen.
Aber was ist mit der Spannung? Die muss ab einer bestimmten Taktrate auch nach oben und ich behaupte mal ganz dreist, dass man die Standard-Spannung niedriger ansetzen könnte, wenn man den Turbo-Modus weglassen würde.
Die Spannung ist doch genauso variabel ?
Der_Korken
2010-09-09, 22:37:36
Die Spannung ist doch genauso variabel ?
Achso, OK, das war mir nicht klar, dass das so einfach geht. Ich dachte man müsste für beide Lastsituationen die gleiche Spannung wählen und dann wär das plötzlich ziemlich ineffizient.
Achso, OK, das war mir nicht klar, dass das so einfach geht. Ich dachte man müsste für beide Lastsituationen die gleiche Spannung wählen und dann wär das plötzlich ziemlich ineffizient.
Na hör mal, du bist hier Gold Member und lässt die absoluten Basics vermissen ... das geht nicht!
Spannungssenkung ist ein absolutes Must, weil die Spannung quadratisch in den Verbrauch eingeht.
y33H@
2010-09-10, 08:25:01
Quadratisch? Nö.
BlackBirdSR
2010-09-10, 09:09:49
Quadratisch? Nö.
Ich denke, da ist eine Erklärung angebracht
@ y33H@
Ivy kommt doch erst mitte 2012, mit 22nm hat Intel noch keine erfahrung, die 2. Ivy Generation kommt bestimmt erst 2013, dann hat AMD schon gemeistert, woher willst du wissen ob Ivy Bridge überhaupt ein Renner wird? ist doch nur ein getunter Sandy der auch nur ein getunter Nehalem mit 10-15% IPC+ ist;) Intel wird mit sicherheit keine neue unabhängige Architektur mehr bauen die nicht mehr auf P6 Nehalem setzt, Sany Bridge & Ivy Bridge sind keine neuen Äste sondern Nehalem aufgusse
Was für ein Schwachsinn! Intel hat schon für über einem Jahr einen SRAM Wafer in 22nm gezeigt!
http://www.golem.de/0909/69994.html
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.