AMDs Bulldozer - neue CPU-Architektur für Q2 2011

[AnarchX]

UPDATE 10.11.10:
http://img441.imageshack.us/img441/1452/bd18sn9.jpg
http://img716.imageshack.us/img716/2326/attachmentif.jpg


I think it is worth making the point that Bulldozer is a radical departure from the current AMD cores and even the Barcelona cores which are yet to hit the marketplace . Bulldozer will be the first “clean break” we have seen from AMD’s K8 core. Bulldozer is easily the most promising architecture we have seen from AMD since its Opteron launch in April of 2003.

Bulldozer is slated to be launched into the “Sandtiger” server and workstation arena in mid-to-late 2009 using DDR3 memories.
http://www.directupload.com/files/jbtqyzz4yonnmkidco5d.jpghttp://www.directupload.com/files/0ymzmayfxtdynzmwzjm2.jpg


http://enthusiast.hardocp.com/article.html?art=MTM2NywxLCxoZW50aHVzaWFzdA==

AMD will wohl zeigen, dass sie noch am Leben sind und weiter kämpfen werden. Mal sehen ob sie unter dem Druck durch Intel es noch soweit allein schaffen werden oder ob wenn diese Projekte vielversprechend sind, sie jemand an die Hand nimmt. ;)

Update:
http://img5.imagebanana.com/img/gv7ybz07/Capture.PNG
http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9MjAzMTl8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1

[=Floi=]

Hallo AnarchX
dafür muß AMD auch gegen den Nehalem antreten!
das wird noch schwer genug die nächsten jahre

[reunion]

Das gehört da wohl auch noch dazu:

http://www.iian.ibeam.com/events/thom001/22876/browser/slides/20070726084721294707/default_large/Slide132.JPG

[Gast]

Jemand eine Ahnung, was sich hinter "G3 Memory Extender" verbergen soll? Klingt für mich reichlichst ominös. Vielleicht über nen Backsidebus angebundener L3-Cache und die Rückkehr zum Slot? Fänd ich ja hammergeil und würde recht gut zu "Torrenza" passen...

[AnarchX]

Jemand eine Ahnung, was sich hinter "G3 Memory Extender" verbergen soll?
http://www.hartware.de/news_42634.html

[Mark]

man könnte bis zu 512gb ram haben...na das würde sich doch mal für eine ramdisk lohnen ;D

[Gast]

Die Rede war auch parallel zum Bulldozer vom Bobcat Kern (mit anderer Architektur) für den Marktberech 1W-10W

Was für bereiche sind denn das ? sind Mobile CPUs in diesem Bereich ?

[AnarchX]

UMPCs bzw. Thinclients, Bobcat ist wohl ein Konkurrent zu Intels Silverthorn bzw. dessem Nachfolger und somit AMDs Nachfolger von Geode.

[Winter[Raven]]

Ob es bis 2009 AMD in der Form wie wir es kennen noch gibt?

[Gast]

;5704137']Ob es bis 2009 AMD in der Form wie wir es kennen noch gibt?
Das denk ich schon. Bedenke AMD rechnet sich derzeit absichtlich schlecht (würd ich auch machen, der einzige Weg um den Preiskampf mit Intel halbwegs auszubremsen).

Da hat AMD ja einiges vor, sehr interessant.

[deekey777]

;5704137']Ob es bis 2009 AMD in der Form wie wir es kennen noch gibt?
Ist aber ein ganz anderes Thema, nicht wahr?

[robbitop]

Der Nachfolger von Fred Weber sagte 2006 in einem Interview auch etwas von 2 brandneuen Architekturen, eine fuer den Server und eine fuer den Mobile Bereich. Und es wird auch allerhoechste Eisenbahn, dass man vom zichmal aufgebohrten K7 mal wegkommt.
Vieleicht hat Transmeta zum Bobcat ja was dazu gesteuert.

[AnarchX]

Und es wird auch allerhoechste Eisenbahn, dass man vom zichmal aufgebohrten K7 mal wegkommt.


Birgt aber halt auch Risiken, die man aber wohl auch wagen muss.

Auch eine Frage ist wohl, wie die aktuelle finanzielle Situation sich auf solche Entwicklungen auswirkt.

[Fatality]

das schöne ist ja das man sich um diese marketing-präsentationen das maul zerreissen kann bis man umfällt. zu wirklich was kommen wird man nicht.
und genau das ist die absicht vom vertrieb, hauptsache die leute reden über einen und man wird nicht vergessen.
so wie amd zur zeit dreck frisst sollte man überhaupt nicht spekulieren was mit dem unternehmen in zukunft sein wird. man wird sehen.

[Oliver Onion]

Also, die Namensgebung ist ja mal Genial. Wie wird Intels Antwort darauf sein? Tank-Trap? Egal, Buddy haut sie alle weg...Bulldozer...*g*

[mrt@nocookie]

Birgt aber halt auch Risiken, die man aber wohl auch wagen muss.

Auch eine Frage ist wohl, wie die aktuelle finanzielle Situation sich auf solche Entwicklungen auswirkt.
Ja muss man um langfristig Innovationen zu bringen und das muss AMD als kleiner Mitbewerber machen.

Die bisherigen Informationen erwecken bei mir eher den Eindruck, als wäre die ganze Familie so konzzipiert worden, als dass die Entwicklungskosten minimiert werden. Was noch lange nicht heißt, dass ich dem Design eine mögliche Vorherrschaft in Punkto Performance abspreche.
So nebenbei finde ich Namensgebungen auch unteressant, AMD scheint sehr davon überzeugt zu sein, dass man mit Bulldozer etwas auflegt mit dem Intel nicht mithalten kann.

[Hvoralek]

So nebenbei finde ich Namensgebungen auch unteressant, AMD scheint sehr davon überzeugt zu sein, dass man mit Bulldozer etwas auflegt mit dem Intel nicht mithalten kann.Dick klingende Namen können auch dazu dienen, eine mangelnde Leistungsfähigkeit ggü. Otto Normaluser zu verschleiern. Oder meinst Du, Intel leidet an so einer verzerrten Wahrnehmung, dass sie ihre "Extreme Graphics"- Einheiten für etwas halten, was diesen Namen verdient hat?

[reunion]

Dick klingende Namen können auch dazu dienen, eine mangelnde Leistungsfähigkeit ggü. Otto Normaluser zu verschleiern. Oder meinst Du, Intel leidet an so einer verzerrten Wahrnehmung, dass sie ihre "Extreme Graphics"- Einheiten für etwas halten, was diesen Namen verdient hat?

Naja, der "Hammer" hat ja gehalten, was der Name versprochen hat. AMD hatte IMHO meistens die cooleren Codenamen, während Intel häufig auf irgendwelche exotischen Wörter setzt. Aber da die Codenamen ohnehin egal sein sollten, ist das kaum von Bedeutung.

[Gast]

Also, die Namensgebung ist ja mal Genial. Wie wird Intels Antwort darauf sein? Tank-Trap? Egal, Buddy haut sie alle weg...Bulldozer...*g*


Sledgehammer war ja auch schon in der richtung ;)

[sloth9]

Laut Stiller (c't) ist er ja erstmal Geschichte...

[Coda]

während Intel häufig auf irgendwelche exotischen Wörter setzt.
Intel verwendet fast ausschließlich Städtenamen der USA.

Laut Stiller (c't) ist er ja erstmal Geschichte...
Hmm?

[ShadowXX]

Hmm?
Der Bulldozer ist erstmal gecancelt und AMD setzt statdessen auf Multiple K10-Cores in einem Die bzw. Package.

Der Grund soll Intels AVX-Erweiterung sein, dessen gegenpart beim Bulldozer (SSE5) zu schwach geweseb wäre (256 Register vs. 128 Register).
http://www.heise.de/ct/08/14/025/


Dank des Patentaustauschabkommens zwischen den CPU-Kontrahenten – das übrigens mit einigen gestrichenen Passagen veröffentlicht wurde [1] – könnte AMD auch die von Intel auf dem letzten IDF angekündigte Vektorerweiterung AVX mit 256-bittigen Registern einbauen. Allerdings hat Intel einige Feinheiten davon gemeinerweise noch nicht dokumentiert. Manche Beobachter der Szene gehen davon aus, dass das Verschwinden von Bulldozer, der ursprünglich geplanten nächsten Prozessorarchitektur von AMD, damit zu tun hat, denn dessen geplantes Gegenstück SSE5 mit 128-bittigen Registern könne gegen AVX nichts ausrichten.


Ob eher mit Intel- oder AMD-CPUs, wollte er nicht verraten, ließ aber durchblicken, dass ihn die Intel-Roadmap mehr überzeugt. Zur jüngsten Änderung der AMD-Server-Roadmap – Integration mehrerer K10-Kerne auf einen Chip beziehungsweise Modul statt rascher Einführung der neuen „Bulldozer“-Architektur – merkte er an, dass es weiterhin auch auf die Performance eines einzelnen Kernes ankommt. Und da hat Intel mit Nehalem einen Vorteil.

[reunion]

Bulldozer wurde nur auf 2010 verschoben, nicht gecancelt. Erst kürzlich sagte Ruiz(?) das es noch in 2009 erste 45nm Bulldozer-Samples geben wird. Vorher kommt allerdings noch mit Istanbul ein nativer Hexa-Core, der dann auch als MCM in einer 12-Core Version kommen wird.

[ShadowXX]

Bulldozer wurde nur auf 2010 verschoben, nicht gecancelt. Erst kürzlich sagte Ruiz(?) das es noch in 2009 erste 45nm Bulldozer-Samples geben wird.
Man wird sehen.....zumindest hört sich das mehr nach gecancelt (zumindest in seiner geplanten Form) als nach verschoben an.

Manche Beobachter der Szene gehen davon aus, dass das Verschwinden von Bulldozer, der ursprünglich geplanten nächsten Prozessorarchitektur von AMD

[reunion]

Man wird sehen.....zumindest hört sich das mehr nach gecancelt (zumindest in seiner geplanten Form) als nach verschoben an.

Er ist auf der Roadmap verschwunden, da diese aktuell nur bis 2009 geht, mehr nicht.

[robbitop]

Also auf Fudzilla stand, dass Bulldozer Samples zum High-K 45 nm Prozess kommen werden und die Massenproduktion in 32 nm stattfinden wird.

[Sorkalm]

Er ist auf der Roadmap verschwunden, da diese aktuell nur bis 2009 geht, mehr nicht.

Die Server-Roadmap geht bis 2010 (da steht für 1H2010 nämlich Magny Cours - der 12-Kern MCM drauf), und da fehlt er völlig.

[HOT]

Ist doch ziemlich einfach: Der K7 hat 3 Fertigungsprozesse mitgemacht, der K8 auch und beim K10 wird das nicht anders sein. BD kommt dann als 2. 32nm Generation auf den Markt, so Anfang 2011 frühestens. Ob es der ursprüngliche BD ist, oder ob es überhaupt jemals ein BD-Konzept + Sandtiger wirklich gab und das nicht nur ein Marketinggespinst war, um die Tiefzeit zu überleben, werden wir wohl nie erfahren - es sinkt aber förmlich danach. Das war nur dazu da um die Aktionäre bei der Stange zu halten.
In Zukunft gibts K10 auf F+ (SockelF mit cHT3) und AM3, später dann G3 mit 4-6 Kernen + MCM-Option, in 32nm sicher auch mit 8 Kernen. Der Shanghai wird dabei der erste echte K10, so wie damals der Thunderbird auch der erste echte K7 war.

[ShadowXX]

Ist doch ziemlich einfach: Der K7 hat 3 Fertigungsprozesse mitgemacht, der K8 auch und beim K10 wird das nicht anders sein. BD kommt dann als 2. 32nm Generation auf den Markt, so Ende 2010, Anfang 2011.
Das hört sich realistisch an und deckt sich mit anderen Infos.

Nur wie ich schon erwähnte, wird das wohl nicht mehr der Bulldozer sein, der für 2009 geplant war, sondern ein entsprechend angepasster,

[reunion]

Es war Dirk Mayer, seines Zeichens AMD President und Chief Operating Officer:

At the most recent conference call with financial analysts AMD’s president and chief operating officer Dirk Meyer said that the next-generation micro-architecture and processors on its base code-named Bulldozer were in development with first samples due in 2009. What Mr. Meyer did not say is when the final central processing units (CPUs) were scheduled to arrive, a piece of information that both analysts and investors are curious to know.

“The Bulldozer core is in development in 45nm [process] technology and we will be sampling that in 2009,” Mr. Meyer told the audience.

http://www.xbitlabs.com/news/cpu/display/20080422104006_AMD_s_Next_Gen_Micro_Architecture_in_Development_Bulldozer_Sample s_Due_in_2009_AMD.html

[HOT]

Jo und überraschend verzögert sich der BD dann bis in den 32nm Prozess hinein. Der Fluch einer AG. Ich bleibe dabei: Es hat nie einen BD gegeben.

[ShadowXX]

Es war Dirk Mayer, seines Zeichens AMD President und Chief Operating Officer:
http://www.xbitlabs.com/news/cpu/display/20080422104006_AMD_s_Next_Gen_Micro_Architecture_in_Development_Bulldozer_Sample s_Due_in_2009_AMD.html
Der Artikel ist vom 22.04.
Es hat sich wohl inzwischen etwas geändert.......

[reunion]

Der Artikel ist vom 22.04.
Es hat sich wohl inzwischen etwas geändert.......

Bulldozer ist schon seit über einem halben Jahr auf keiner Roadmap mehr vorhanden. Deshalb die Äußerung von Meyer.

[w0mbat]

Bulldozer gibt es noch und er ist auch noch auf den Roadmaps, nur eben nicht auf den alten.

[ShadowXX]

Bulldozer ist schon seit über einem halben Jahr auf keiner Roadmap mehr vorhanden. Deshalb die Äußerung von Meyer.
Glaub es oder nicht....der Bulldozer wird nicht wie geplant anrollen.

[reunion]

Glaub es oder nicht....der Bulldozer wird nicht wie geplant anrollen.

Und das schließt du woraus? Glaskugel? c't-Geflüster? Das ich nicht lache. Möglich ist vieles, aber sich hier irgendetwas zusammenzureimen bringt gar nichts. Und erfahren werden wir es ohnehin nie.

[GeneralHanno]

naja, vll hat man sich bei AMD doch etwas zu weit aus dem fenster gelehnt mit dem SSE5-vorstoß und man hat sich entschlossen BD etwas nach hinten zu verschieben, aufzubohren, damit man mit intels neuer vektorarchitektur (+ befehlssätze) mithalten kann.

PS: nehalem stand auch schon lange auf intels roadmap, nur das design hat sich zwischendurch "etwas" geändert ^^ (stichwort 10 GHz ;))

[Coda]

Nehalem war damals ja auch noch ein Netburst-Ableger. Da gibt's ja gar keinen Zusammenhang mehr außer dem Codenamen.

[S940]

SSE5 kommt sowieso mit Shanghai, genauso wie SSE4.1 und SSSE3 ;D

Revision History

• 3.1 [Legacy Method] on page 23: Clarified.
• CPUID Fn0000_0001_ECX[SSE41]: Added.
• CPUID Fn0000_0001_ECX[SSSE3]: Added.
• CPUID Fn8000_0001_ECX[SSE5]: Added.
• CPUID Fn8000_0001_ECX[IBS]: Added.
• CPUID Fn8000_0008_EAX[GuestPhysAddrSize]: Adde
• CPUID Fn8000_0008_EAX[PhysAddrSize]: Updated.
• CPUID Fn8000_000A_EDX[Ssse3Sse5Dis]: Added.

Aus der offiziellen Doku von AMD:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf

Ungefähr zur selben Zeit letztes Jahr wurde das gleiche Dukument um SSE4A Infos ergänzt ...
Deswegen ist SSE5@Shanghai zur Zeit mein Lieblingsgerücht ;-)

und keiner sieht es kommen :biggrin:

ciao

Alex

[HOT]

SSE5 wird sicherlich schon in der K10 Generation (Rev.C oder D) kommen, das halte ich auch für sicher. SSE5 hat nichts mit dem BD zu tun, das ist nur ne neue SIMD-Befehlssatz-Version, die kein Mensch im Desktop-Bereich nutzt, genau wie SSE3, SSE4 oder SSE4a.

[Coda]

Mir wär's eh lieber wenn sie sich da auf was einigen könnten. SSE5 bringt keinem was solange es Intel nicht unterstützt.

[GeneralHanno]

SSE5 wird sicherlich schon in der K10 Generation (Rev.C oder D) kommen, das halte ich auch für sicher. SSE5 hat nichts mit dem BD zu tun, das ist nur ne neue SIMD-Befehlssatz-Version, die kein Mensch im Desktop-Bereich nutzt, genau wie SSE3, SSE4 oder SSE4a.
ich hatte es so verstanden, dass man für SSE5 ziemlich weitreichende veränderungen an der pipeline benötigte ...

[S940]

Mir wär's eh lieber wenn sie sich da auf was einigen könnten. SSE5 bringt keinem was solange es Intel nicht unterstützt.
Das sagen alle, nur Intel und AMD können sich nicht einigen ... Prinzipiell ist Intel der Schuldige, SSE5 war hinreichend lang bekannt, dann kam das "SSE5+" namens AVX .. toller Strumpf.
AMD könnte man vielleicht ankreiden, dass sie sich noch eher mit Intel hätten zusammensetzen sollen ... aber .. egal & zu spät.

@GeneralHanno:
Nö, dem internen Alpha Design sei Dank (vielleicht ist es auch nur Zufall ^^) :)
And, incidentally, it will be easier to implement the new 3-operand instructions for AMD than it is for Intel because the current Intel microarchitecture does not allow micro-operations with more than two inputs, while the AMD microarchitecture has no such limitation.
http://aceshardware.freeforums.org/intel-avx-kills-amd-sse5-t538.html
Der Author des Artikels ist Professor in Kopenhagen, kennt sich also aus ;-)

ciao

Alex

[Coda]

Intel ist an gar nichts schuld. AVX ist die eindeutig bessere Lösung.

[HOT]

ich hatte es so verstanden, dass man für SSE5 ziemlich weitreichende veränderungen an der pipeline benötigte ...
Man wird Änderungen benötigen, aber man hat die ja schon berücksichtigt, wie die Revision-History zeigt. Es wäre traurig wenn es nicht so wäre.
Meiner Meinung nach ist die Rev.C schon auf SSE5 vorbereitet, aber es wird sicherlich erst in der Rev.D freigeschaltet.
Evtl. hat man sich ja sogar schon geeinigt. Wenn AMD schon 4.1 Kompatibilität offiziell angibt, kann ja ein Tausch schon stattgefunden haben. Dann wäre SSE5 aber evtl. erfolgreicher als AVX :D.
AVX ist zwar toll, aber irgendwie auch Overkill. Wofür gibts ja GPGPUs. Bis dahin gibts ja sogar ne Lösung von Intel.

[S940]

Intel ist an gar nichts schuld. AVX ist die eindeutig bessere Lösung.
AVX ist besser, bestreitet keiner ... aber sie sind daran schuld, dass es 2 Standards gibt, AMD war eher dran, das interessierte Intel aber überhaupt nicht, die backen eigene Brötchen.

Dass die Brötchen größer sind und vielleicht besser schmecken werden, ist ne andre Geschichte.

Ich dachte, dass es Dir v.a. um einen gemeinsamen Standard geht, da Du was von "einigen" geschrieben hattest.

Edit:
@HOT:
Jo ein K10 plus einem RV670 in einem Fusiongehäuse .. das ist dann sowas wie ein x86 Cell, nur "etwas" schneller ;-)
Mal schauen, ob AVX dagegen ankommt ^^
Weiss jemand, wie lange die Vektoren im RV670 sein können ? Schafft das VLIW core auch 256bit ? Oder mehr / weniger ?

ciao

Alex

[Triskaine]

Intel ist an gar nichts schuld. AVX ist die eindeutig bessere Lösung.

Was sagst du dazu?:http://www.amdzone.com/phpbb/viewtopic.php?f=52&t=135218#p136807

[Bokill]

Was sagst du dazu?:http://www.amdzone.com/phpbb/viewtopic.php?f=52&t=135218#p136807 Was soll das für ein Link sein? Was ist die Grundaussage?

Bei mir funktioniert der Link nicht.

[Gast]

Was soll das für ein Link sein? Was ist die Grundaussage?

Bei mir funktioniert der Link nicht.

Argh vor zwei minuten ging der noch, aber egal ich kopier mal den Post des geschätzen Herren hier rüber: His post contains quite a few inaccuracies much in favor of AVX. In particular, SSE5 support 3-operand instruction only for new instructions, because SSE5's new instructions are complement to the old ones; OTOH, AVX is meant to displace the old instructions with a new format. This is hardly a good thing for backward compatibility.

Second, many SSE5 instructions support 4-operand instructions when the destination and source is the same register, but only selected few AVX instructions support 4-operand with non-destructive syntax. The 4th operand in AVX occupies part of the immediate byte, making the instructions longer and its applicability more limited. I have no clue where he got the idea that AVX intends to extend to 5-operand - 4-operand instructions are useful in a number of places (e.g., Multiply-Add), but sheer increase of number of operands is senseless, even though both SSE5 and AVX could be extended to support it.

Third, AVX makes the instruction "sometimes shorter" only if it break backward compatibility. In other words, an instruction written in AVX "short/new format" is invalid and will cause undefined behavior on any existing processor. The "backward-compatible" instruction format of AVX is an order of degree more complicated than SSE5; AVX had to flip the bits of register numbers and do some weird shuffling.

OTOH, SSE5 is not complicated at all. Unless he's brain damaged, I can't see how he thinks the following simple construction "complex":

* All SSE5 instructions use 2-byte prefix 0F24 and 0F25
* A single byte of Opcode3 encodes different SSE5 instructions
* A single byte of DREX, replacing original REX, encodes the additional argument.

That's it. It takes a mere 2 pages to describe in AMD's SSE5 spec. Now anyone care to find out how long is Intel's description of AVX construction rules? (Hint: it started from 4-75 all the way to 4-87. Do the count yourself).

The one thing that SSE5 truly falls behind of AVX is the support of 256-bit registers. Now the problem is, is it more beneficial to perform 8 32-bit operations in vectors in general purpose CPU, or is it better to send off such computation to specialized GPGPU core? I think the answer should be quite clear to most people with basic computer microarchitecture understanding.

Dies ist als Antwort auf des Professors AVX Aufsatz zu verstehen, der hier: http://aceshardware.freeforums.org/intel-avx-kills-amd-sse5-t538.html

[Coda]

Das Instruction-Encoding interessiert doch sowieso nur die Hardware und Assembler-Programmierer.

Das sehe ich kaum als Nachteil an.

[S940]

Was sagst du dazu?:http://www.amdzone.com/phpbb/viewtopic.php?f=52&t=135218#p136807
Der Link geht nicht.

Zum Thema "einigen", anscheinend plant AMD da ne Art Softwarelösung, per Emulationsschicht:
Aktuelle Lage:
http://www.bilder-space.de/upload/oxLCVfqbb2w3Xtt.JPG

Lösung:
http://www.bilder-space.de/upload/jmXJR5ZwpXNfLGt.JPG

Da sollten sich die AVX Befehle auch ganz schnell einlinken lassen. Falls es nen entsprechenden SSE5 Befehl gibt, würde dann auf nen AMD dann halt der ausgeführt werden.


Weitere Infos:
http://sseplus.sourceforge.net/index.html

Präsentation:
http://sseplus.sourceforge.net/SSEPlus.png
http://sseplus.sourceforge.net/SSEPlus.pdf

Interessant auch, dass die bereits schon ne "native Layer" für SSE5 haben ... Ob das jetzt schon Sinn machen würde, wenn ein Chip damit erst 2010 kommen würde ...

ciao

Alex

[Gast]

Link:

http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=135218

Der 3er hinter phpbb hat gefehlt (kann aber sein, das dieser Link auch wieder in ein paar Minuten nicht geht wenn die Zahl willkürlich angefügt wurde/wird)

[GeneralHanno]

Interessant auch, dass die bereits schon ne "native Layer" für SSE5 haben ... Ob das jetzt schon Sinn machen würde, wenn ein Chip damit erst 2010 kommen würde ...

wieso, die 45nm Rev C kommen doch schon 2008 und die Rev D 2009 ...

[S940]

wieso, die 45nm Rev C kommen doch schon 2008 und die Rev D 2009 ...
Ja klar, damit waren nur die Leute gemeint, die behaupten, SSE5 käme erst mit Bulldozer.

ciao

Alex

[Bokill]

... AMD könnte man vielleicht ankreiden, dass sie sich noch eher mit Intel hätten zusammensetzen sollen ... aber .. egal & zu spät ... So funktioniert der Markt aber nicht.

AMD und Intel haben zwar ein Patentaustauschabkommen (http://www.orthy.de/index.php?option=com_content&task=view&id=4778&Itemid=85) (das letzte war vom 1. Mai 2001) ... aber das bedeutet vermutlich auch, dass bestimmte Sachen des Konkurrenten -> zeitverzögert erst genutzt werden dürfen.

Für kompakte übersichtliche Märkte (Suns Solaris 10 Betriebssystem + MySQL, Oracle-Datenbanken) könnte AMD ihr SSE5 tatsächlich erfolgreich einbringen ... Immerhin dürfte AMD dort seine Partner gefragt zu haben, was denn eine sinnvolle ISA-Erweiterung sei.

Für breitere (Massen-)Märkte scheint hingegen Intels AVX wie Gift für AMDs SSE5 angelegt zu sein.

MFG Bobo(2008 )

[HOT]

Ja klar, damit waren nur die Leute gemeint, die behaupten, SSE5 käme erst mit Bulldozer.

ciao

Alex
Wenn das schon in den Rev. Guides drin ist, unterstützen die entsprechenden CPUs auch die entsprechenden Befehlssätze.
Man weiss halt nur nicht, was da jetzt politisch passiert. Wenn AMD SSE5 gegen SSE4 getauscht hat, kann Intel darauf bestanden haben, dass SSE5 in der Rev.C noch nicht nutzbar sein darf.

[...]

Für breitere (Massen-)Märkte scheint hingegen Intels AVX wie Gift für AMDs SSE5 angelegt zu sein.
Nur dass das für die breiten Massenmärkte solange eh völlig irrelevant ist.

[S940]

Das Instruction-Encoding interessiert doch sowieso nur die Hardware und Assembler-Programmierer. Jo das interessiert v.a. die CPU. x86 CPUs haben nen Predecoder der ne bestimmte Menge Instructionbits einliest und dann dekodiert. Sind die Befehle kurz, können mehr Instruktionen pro Takt dekodiert werden --> IPC steigt (so denn danach kein Flaschenhals mehr kommt^^)

Intel hat seit Ewigkeiten 16byte Prefetch(und ändert da auch nichts mit Nehalem), während AMD beim K10 erst tüchtig auf 32byte aufgerüstet hat.

Als Grund gibt David Kanter an:
The previous generation K8 fetched 16B each cycle, as does Intel’s Core 2. The instruction fetch was widened because many of the SIMD and 64 bit instructions are longer, and as these become more common, larger fetches are required to keep the rest of the core busy. Consequently, the pre-decode and pick buffer for Barcelona has been enlarged, to at least 32B, although it could be somewhat larger - the K8's predecode buffer was 1.5x the fetch size, so a 48B buffer might not be out of the question.
http://www.realworldtech.com/page.cfm?ArticleID=RWT051607033728&p=3

Die paar zusätzlichen Decode Bytes von SSE5 sollten einen K10 also nicht wirklich jucken ^^

@Bokill:
Schon klar mit dem Markt, aber das hindert ein paar "Fans" sicher nicht so zu argumentieren, das wollte ich gleich mal mit "egal" unterbinden, mit Deinem Kommentar sollte es erst recht erledigt sein :)

zum Gift ... jo da hast Du recht, aber im Vergleich zur alten 3DNOW! Zeit, wartet jetzt ein SSE5 Microsoft Compiler als Flankenunterstützung ;-)
Und die OpenSource Leute will AMD wohl mit dem SSEPlus beglücken, das macht eigentlich auch nen guten Eindruck, ersparten den Codern die Auseinandersetzung mit den CPUs.

Mal schauen, wie das Feedback der Programmierer ausfällt.

Edit:
Man weiss halt nur nicht, was da jetzt politisch passiert. Wenn AMD SSE5 gegen SSE4 getauscht hat, kann Intel darauf bestanden haben, dass SSE5 in der Rev.C noch nicht nutzbar sein darf.Öhm, wenn dann kann Intel AMD die SSE4 Nutzung verbieten / rauszögern, aber die eigene SSE5 .. da hat Intel doch nichts zu suchen ... wär ja wohl noch schöner. Ok, es könnte so ne Klausel geben ... aber die wär irgendwie ... "sehr komisch".

Ich denke, das läuft so wie immer ab, Intel hat jetzt schon ne Zeitlang SSE4.1, das darf AMD jetzt mit Shanghai nutzen, aber von SSE4.2 sieht man noch nichts ... da wird man noch warten müssen, da es zu neu ist.

ciao

Alex

[Gast]

Das sagen alle, nur Intel und AMD können sich nicht einigen ... Prinzipiell ist Intel der Schuldigedas ist immer die strategie von intel, sieht man jetzt auch bei USB3 bei dem sie der konkurenz paper vorenthalten um die ersten sein zu koennen. aber das ist ein normales vorgehen, die epic games leute wollen auch die ersten sein die mit ihrer engine auf eine plattform geld schaufeln und MS gibt dir auch erst irgendwelche api spezifikationen wenn all ihre software schon lange damit laeuft.

da ist es kompletter unfug mit "ist besser" usw. zu argumentieren, solange die big player so handeln, leiden die kunden daran dass es zig versionen gibt oder selbst unter der selben spezifikation inkompatibilitaeten (so war es am anfang mit AGP :( )

AMD sollte mal ueber den teich springen und mit IBM, NEC, Hitachi usw. zusammen einen standard fuer SIMD zu entwickeln der dann zumindestens vom assembler her gleiche instruktionen bietet. (so wie frueher 3dnow! von amd, cyrix... ) unterstuetzt wurde.

[Bokill]

... so wie frueher 3dnow! von amd, cyrix ... unterstuetzt wurde ... Lieber nicht! Da bis auf Quake-Patches und nur sehr wenige andere Programme die SIMD-Funktionen von 3DNow! wirklich nutzten.

... AMD sollte mal ueber den teich springen und mit IBM, NEC, Hitachi usw. zusammen einen standard fuer SIMD zu entwickeln der dann zumindestens vom assembler her gleiche instruktionen bietet. ... Wer sagt denn, dass IBM so etwas für die z-Linie und die Power-Architektur haben will (abgesehen davon, dass die Power-Architektur ISA von einem Konsortium verwaltet wird)?

Auch Sun (die SPARC ISA wird auch von einem Konsortium verwaltet) MIPS, ARM und Andere müssen wollen, damit eine "Universelle SIMD-Einheit" in die verschiedenen ISA Einzug hält.

Nein, die Hausaufgaben müssen zuerst im x86-Garten erledigt werden. Im Grunde genommen ist AMD sogar in der Lage die Intel-Erweiterungen (und umgekehrt) zeitverzögert zu übernehmen.

Bislang hatte Intel aber beinhart praktisch fast alle AMD-Erweiterungen nicht implementiert. "Lediglich" bei AMD64 alias x86-64 war der Leidensdruck bei Intel so stark, dass sie dieses doch in die Microarchitekturen ab dem Pentium 4 Prescott einbanden.

MFG Bobo(2008 )

[Gast]

Lieber nicht! Da bis auf Quake-Patches und nur sehr wenige andere Programme die SIMD-Funktionen von 3DNow! wirklich nutzten.
es war lediglich ein beispiel fuer company uebergreifende zusammenarbeit gegen intel bei SIMD. quake, ogl patches, wayne..


Wer sagt denn, dass IBM so etwas für die z-Linie und die Power-Architektur haben will sie haben es schon, nennt sich altivec, vmx, etc.

Auch Sun (die SPARC ISA wird auch von einem Konsortium verwaltet) MIPS, ARM und Andere müssen wollen, damit eine "Universelle SIMD-Einheit" in die verschiedenen ISA Einzug hält.schoen dass du IBM, NEC, Hitachi usw.zustimmst :)


Nein, die Hausaufgaben müssen zuerst im x86-Garten erledigt werden. Im Grunde genommen ist AMD sogar in der Lage die Intel-Erweiterungen (und umgekehrt) zeitverzögert zu übernehmen.das sind keine hausaufgaben, es ist die marktmacht von 75% gegen david. und solange sich die kleinen nicht zusammentun, werden sie einzelt den kuerzeren gegen intel ziehen und je laenger das so laeuft, desto schlimmer wird es, denn intel faehrt seine schiene strikt durch, waehrend AMD immer noch 3dnow etc. warten und einbauen muss.

Bislang hatte Intel aber beinhart praktisch fast alle AMD-Erweiterungen nicht implementiert. "Lediglich" bei AMD64 alias x86-64 war der Leidensdruck bei Intel so stark, dass sie dieses doch in die Microarchitekturen ab dem Pentium 4 Prescott einbanden.
und das wird weiter so sein, egal welche SIMD besser ist. wenn AMD jemals was dagegen ausrichten will, solange sie nicht zufaellig mal selbst 50%+ vom markt haben, muessen sie sich mit all den anderen zusammentun und einheitliches SIMD schaffen. wie sie es dann auf unterster eben im opcode implementieren ist es ihre sache, aber zumindestens das instructionset sollte kompatibel sein.


my2cent

[Coda]

Lieber nicht! Da bis auf Quake-Patches und nur sehr wenige andere Programme die SIMD-Funktionen von 3DNow! wirklich nutzten.
Naja. Die Treiber und 3D-APIs haben es schon verwendet. Da hat das vor allem bei non-T&L-Hardware schon was gebracht.

Aber 3DNow! war auch ein Fehler weil sie immer noch die FPU-Register verwendet haben.

[Gast]

Aber 3DNow! war auch ein Fehler weil sie immer noch die FPU-Register verwendet haben.
nur weil MS sich weigerte mehr als eine erweiterung zu verwenden, deswegen hat AMD genommen was da war. aber ja, das war sch....

[Gast]

Grade ne Email gekriegt:


Intel AVX is a new 256-bit SIMD FP vector extension of Intel Architecture. Its introduction is targeted for the Sandy Bridge processor family in the 2010 timeframe. Intel AVX accelerates the trends towards FP intensive computation in general purpose applications like image, video, and audio processing, engineering applications such as 3D modeling and analysis, scientific simulation, and financial analytics.

Intel AVX is a comprehensive ISA extension of the Intel 64 Architecture. The main elements of Intel AVX are:
- Support for wider vector data (up to 256-bit).
- Efficient instruction encoding scheme that supports 3 and 4 operand instruction syntax.
- Flexibility in programming environment, ranging from branch handling to relaxed memory alignment requirements.
- New data manipulation and arithmetic compute primitives, including Broadcast, permute, fused-multiply-add, etc.

[Avalox]

Grade ne Email gekriegt:


AMD wird AVX adaptieren. Brauchen dafür etwas Zeit, da wie im o.g. c`t Artikel Intel mal wieder nicht so richtig die Informationen ausrückt. Gehört wohl zum Spiel.

[robbitop]

Ich kann mir nicht vorstellen, dass aufgrund einer SIMD Erweiterung eine ganze µArch nach hinten geschoben wird. Mein Gott, dann kommt die eben erst in die nächste Revision. So schnell setzt sich das eh in Software nicht durch.
Die Verschiebung von Bulldozer hat IMO andere Gründe. Wurde nicht rechtzeitig marktreif oder sowas. Der K8 verzögerte sich damals ja auch etwas.

[Bokill]

... sie haben es schon, nennt sich altivec ... Altivec ist eine typische (sehr mächtige) SIMD-Einheit der Power-Architektur ... Mir wäre es neu, dass sie übergreifend auch für die x86-ISA verwendet wird.

Ich sprach die Bemühungen an, die notwendig wären, wenn eine ISA-übergreifende SIMD-Einheit entworfen werden sollte ...

MFG Bobo(2008 )

[S940]

Ich kann mir nicht vorstellen, dass aufgrund einer SIMD Erweiterung eine ganze µArch nach hinten geschoben wird. Mein Gott, dann kommt die eben erst in die nächste Revision. So schnell setzt sich das eh in Software nicht durch.
Die Verschiebung von Bulldozer hat IMO andere Gründe. Wurde nicht rechtzeitig marktreif oder sowas. Der K8 verzögerte sich damals ja auch etwas.
Wer hat behauptet, dass Bulldozer wg. SSE5 verschoben wurde ? Ich glaube da hast Du was falsch verstanden.

Der Inq. hat zur Bulldozerverschiebung mal nebulös wie immer davon gesprochen, dass Bulldozer nur in 32nm sinnvoll implementiert werden könnte. Was immer das nun wieder heißen mag. Spekulationen auf die Schnelle: ultrakurze Pipline, die mit 45nm auf zu wenig Takt käme, Riesenchipfläche bzw. komplexer Aufbau mit zuvielen SpeedPaths in 45nm, ... ?


ciao

Alex

[MeanMachine]

Wie wäre es mal mit einer Erklärung für Noobs :)

In welchen Situationen bzw. welcher Software bringt AVX einen Vorteil?
Müssen die Programme zwingend auf AVX Programmiert werden damit es was bringt?
Wie hoch "könnte" der Leistungsvorteil sein?
Da ja jeder PC eine Grafikkarte hat, wie wahrscheinlich ist es das die Vektorberechnungen einfach auf die Grafikkarte ausgelagert werden und somit ein Teil ( oder Vorteil ) von AVX gar nicht Praxisrelevant wird?

Würde mich freuen wenn jemand Zeit und Lust hätte mir es in groben Zügen zu erklären.
Danke schön :)

Gruß
MM

[Gast]

Altivec ist eine typische (sehr mächtige) SIMD-Einheit der Power-Architektur ... Mir wäre es neu, dass sie übergreifend auch für die x86-ISA verwendet wird.

Ich sprach die Bemühungen an, die notwendig wären, wenn eine ISA-übergreifende SIMD-Einheit entworfen werden sollte ...

dann weiss ich nicht weshalb du mich hier (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6611213&postcount=59) quotes, wenn es nichts mit meinem vorschlag einer assembler (nichtmal opcode) kompatiblen SIMD-Einheit zu tun hat.

[Bokill]

dann weiss ich nicht weshalb du mich hier (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6611213&postcount=59) quotest, wenn es nichts mit meinem vorschlag einer assembler (nichtmal opcode) kompatiblen SIMD-Einheit zu tun hat.
Meinst du das?:
... AMD sollte mal ueber den teich springen und mit IBM, NEC, Hitachi usw. zusammen einen standard fuer SIMD zu entwickeln der dann zumindestenst vom assembler her gleiche instruktionen bietet. ... Wer sagt denn, dass IBM so etwas für die z-Linie und die Power-Architektur haben will (abgesehen davon, dass die Power-Architektur ISA von einem Konsortium verwaltet wird)? Weil die anderen Hersteller und Konsortien überhaupt dafür bereit sein müssen so etwas zu tun ...

Das hängt nicht nur von AMD ab. Ob es sich dabei um identischen Binärcode, oder auch nur um einen Assembler (http://de.wikipedia.org/wiki/Assembler_(Informatik)) handelt, ist in meinen Augen nebensächlich.

Gibt es denn überhaupt "einen gemeinsamen" Assembler für unterschiedliche ISAs wie x86, ARM, und MIPS, Power-Architektur, SPARC? Ist doch schon schwer genug innerhalb einer einzigen ISA mit ihren vielen unterschiedlichen Microarchitekturen.

[Gast]

Meinst du das?:ja, dazu hatte ich verlinkt.


Weil die anderen Hersteller und Konsortien überhaupt dafür bereit sein müssen so etwas zu tun ......emm...ehh... ja, wie sollte es sonst gehen als dass alle es wollen.


Das hängt nicht nur von AMD ab. Ob es sich dabei um identischen Binärcode, oder auch nur um einen Assembler (http://de.wikipedia.org/wiki/Assembler_(Informatik)) handelt, ist in meinen Augen nebensächlich.ach, du hast rausgefunden dass es zwischen opcode und assembler nen unterschied gibt. super. jetzt musst du nur noch verstehen weshalb es nicht nebensaechlich ist. gleichen opcode zwischen CISC/RISC big/little endian etc. wird es nicht geben. gleiche instruktionen kann es geben.

Gibt es denn überhaupt "einen gemeinsamen" Assembler für unterschiedliche ISAs wie x86, ARM, und MIPS, Power-Architektur, SPARC? Ist doch schon schwer genug innerhalb einer einzigen ISA mit ihren vielen unterschiedlichen Microarchitekturen.
das problem ist nicht der syntax, das juckt niemanden, denn das kann man mit makros oder instrinsics verstecken. wichtig ist dass ein einmal geschriebener und optimierter code nicht komplett neu geschrieben werden muss wenn man eine weitere plattform unterstuetzen will. zZ ist das extrem pain, weil du optimierten code praktisch neu schreibst und optimierst. dabei geht es mir nicht darum dass du ein fmac durch mull+add ersetzt, sondern die freakigen sachen die dann auf einer plattform als eine instruktion vorhanden sind und auf einer anderen mit 9 nachgecodet werden. da kommst du leicht an den punkt wo denkst "portiert ist es, aber nicht schneller als die fpu, ich muss es komplett umstellen damit es heir gut laeuft" und mit instruktionen ist es oft nicht getan, du musst notfalls auch das layout der ganzen daten aendern. z.b. kannst sind bei manchen SIMD unaligned reads wie aligned, bei anderen SIMD implementierungen ist es garnicht moeglich unaligned zu lesen, entweder exception oder die unteren bits werden ignoriert.
wenn du die zeit nicht hast, nimmst du vermutlich einfach sse und c code auf den anderen plattformen.

[Bokill]

... wichtig ist dass ein einmal geschriebener und optimierter code nicht komplett neu geschrieben werden muss wenn man eine weitere plattform unterstuetzen will. zZ ist das extrem pain, weil du optimierten code praktisch neu schreibst und optimierst. ... So funktioniert der Weltmarkt aber nicht.

Intel will sich abgrenzen gegenüber AMD (und umgekehrt), das ist um so schwieriger, wenn beide per Patentabkommen in der ISA im Grunde sich mit zeitlicher Verzögerung immer wieder sich angleichen.

Die Abgrenzung gegenüber anderen ISAs ist da leichter beizubehalten. Intel wird sich auch hüten sich von ARM, MIPS in "ihren x86-Instruktionssatz" "reinpfuschen" zu lassen.
Da eröffnet Intel lieber einen strategischen Angriff mit einer neuen Microarchitektur (Beispiel "Atom"), um diverse ARM-Derivate mittelfristig Konkurrenz zu machen in Segmenten, worin x86(-64) bislang kaum bis gar nicht vertreten war.

Selbst innerhalb einer ISA (Beispiel ist der "Cell" mit abweichender modifiziertem Power-Architektur Istruktionssatz) gibt es immer wieder Änderungen und Ergänzungen, so dass eine übergreifende ISA-Zusammenarbeit schon aufgrund des Wunsches nach Abgrenzung der Hersteller utopisch erscheint.

Wie es sich mit Intels AVX und AMDs SSE5 anlässt vermag ich da nicht vorhersagen ... es wird vermutlich aber nicht die letzte SIMD-Einheit und Erweiterung der x86-64-ISA sein.
Und auch der Cell sowie im Allgemeinen wird die Power-Architektur weitere ISA-Ergänzungen erfahren ... Die "Pain in the ass" wird dir also auch zukünftig nicht erspart bleiben.

Ich verstehe ja deine Sichtweise (und befürworte sie), aber das ist eben nur eine Sichtweise ... es geht eben nicht um Effizienz und "Nutzen", sondern es sind noch ganz andere Kriterien, die den Weltmarkt immer wieder mit "tollen Neuerungen" aufmischen.

MFG Bobo(2008 )

[Gast]

So funktioniert der Weltmarkt aber nicht.
...
(Beispiel ist der "Cell" mit abweichender modifiziertem Power-Architektur Istraktionssatz) gibt es immer wieder Änderungen und Ergänzungen, so dass eine übergreifende ISA-Zusammenarbeit schon aufgrund des Wunsches nach Abgrenzung der Hersteller utopisch erscheint.
das funktioniert schon lange so, viele hersteller arbeiten zusammen um gegen intel z.B. bei der Fertigungstechnologie anzukommen, weil sie durch abgraenzung mehr nachteile als vorteile haben (z.B. IBM und AMD). Und fertigungstechnologie ist im gegensatz zum instruction set etwas mit tausend patenten.

Bei AMD sieht man dass sie dan bei software sogar so extrem machen, dass sie all ihre GPU informationen freigeben. Das macht weder intel noch NVidia und vor dem kauf von ATI war das auch eher unvorstellbar.

AMD sieht dass sie von aussen jede synergie brauchen, sie sind die kleinen und abgraenzung wuerde nur Intel zugute kommen.

solange die anderen das nicht machen, werden die meisten entwickler auf SSE von intel optimieren, denn irgendwann muss AMD nachziehen und dann hat man 90% vom cpu-markt (also pc+server) abgedeckt. SSE4a SSE5 liegt dann genau so brach wie 3dnow. (egal was besser ist).

jedenfalls meine Meinung.

[Ganon]

Bei AMD sieht man dass sie dan bei software sogar so extrem machen, dass sie all ihre GPU informationen freigeben. Das macht weder intel noch NVidia und vor dem kauf von ATI war das auch eher unvorstellbar.

Also Intel macht das mit den GMA-Chips auch. Und im Gegensatz zu AMD liefern sie sogar noch gleich fertige OpenSource-Treiber mit dazu.

[Bokill]

das funktioniert schon lange so, viele hersteller arbeiten zusammen um gegen intel z.B. bei der Fertigungstechnologie anzukommen, weil sie durch abgraenzung mehr nachteile als vorteile haben (z.B. IBM und AMD). Und fertigungstechnologie ist im gegensatz zum instruction set etwas mit tausend patenten. ... Bitte?

Was ist das für ein Diskussionsstil? Lese mal die letzten Postingtitel -> "Einheitliche SIMD-Einheit für Alle?".

Ich rede die ganze Zeit über Instruktionssätze und deren Erweiterungen und du machst ein neues Fass in einem völlig anderen Bereich auf.

Die Zusammenarbeit im Halbleiterbereich zur Weiterentwicklung ist mir bekannt und habe auch immer wieder darüber berichtet (http://www.orthy.de/index.php?option=com_content&task=view&id=5459&Itemid=85).
Stilistisch schiebst du mir da was unter, als hätte ich die Zusammenarbeit für unmöglich gehalten im Fertigungsbereich bei Halbleitern.

Bei AMD sieht man dass sie dann bei software sogar so extrem machen, dass sie all ihre GPU informationen freigeben. Das macht weder intel noch NVidia und vor dem kauf von ATI war das auch eher unvorstellbar. AMD hat vor kurzem den Instruktionssatz der R600-Serie veröffentlicht.
Intel hat verkündet verstärkt Treiber für Linux voranzutreiben und auch den Instruktionssatz des Larrabee schon sehr früh (+ Programmierungsbeispielen) der Linuxgemeinde vorzustellen.

Das hat aber auch nichts mit Absprachen und Kooperation zu tun, sondern AMD will sich hier auch gegenüber Nvidia abgrenzen.
Und Intel will IHRE Architektur damit voranbringen.
Was anderes wäre es, wenn sie wie Sun tatsächlich ein Chipdesign als OpenSource freigeben, so dass sogar Konkurrenten auf das Chip-IP und Instruktionsset zurückgreifen können (UltraSPARC T1 usw.).

Im Übrigen Ist SPARC, wie die Power-Architektur nicht mehr ausschliesslich in einer Herstellerhand, dort verabreden sich die Firmen jeweils (SPARC International, Power.org) tatsächlich untereinander welche Erweiterungen in ihren jeweiligen ISAs eingebracht werden.

Bei x86 hingegen herrscht so etwas wie Wildwuchs vor, wobei dann AMD und Intel (und VIA) je nach Lust und Laune und zeitlichen Sperrfristen die Erweiterungen des Konkurrenten/Wettbewerbers mit übernehmen/rauschmeissen (VIA hat 3DNow! aus den aktuellen C7 und C8 alias "Nano" rausgeschmissen!) ... oder eben auch nicht.

Um es noch mal zu betonen. Natürlich ist eine herstellerübergreifende Zusammenarbeit zur Weiterentwicklung von SIMD-Instruktionssätzen sinnvoll ... aber vor allem die ISA-Politik im x86-Bereich lässt jede realistische Hoffnung dahinschmelzen.

Bevor das möglich ist, muss diese Kraut & Rüben-Weiterentwicklung des Instruktionssatzes (ISA) zwischen AMD, Intel und VIA in geordneten kooperativen Bahnen verlaufen. Bis jetzt herrscht dort das Gesetz des Dschungels.

MFG Bobo(2008 )

[Gast]

Also Intel macht das mit den GMA-Chips auch. Und im Gegensatz zu AMD liefern sie sogar noch gleich fertige OpenSource-Treiber mit dazu.
Ich hab keine opensource treiber für Intels WLan notebook karten gefunden.

[Gast]

Bitte?

Was ist das für ein Diskussionsstil? Lese mal die letzten Postingtitel -> "Einheitliche SIMD-Einheit für Alle?".

Ich rede die ganze Zeit über Instruktionssätze und deren Erweiterungen und du machst ein neues Fass in einem völlig anderen Bereich auf.ganz locker bleiben, du hast gesagt ISAs wuerden nie zusammenarbeiten, ich hab lediglich ein weiteres beispiel dafuer genannt bei dem es gemacht wurde, nachdem dir das beispiel mit 3dnow nicht gereicht zu haben scheint.




Um es noch mal zu betonen. Natürlich ist eine herstellerübergreifende Zusammenarbeit zur Weiterentwicklung von SIMD-Instruktionssätzen sinnvoll mehr hab ich nie gesagt.

Bevor das möglich ist, muss diese Kraut & Rüben-Weiterentwicklung des Instruktionssatzes (ISA) zwischen AMD, Intel und VIA in geordneten kooperativen Bahnen verlaufen. Bis jetzt herrscht dort das Gesetz des Dschungels.Intel wird sich auf die kleinen aus prinzip nicht einlassen, all die kleinen wilden muessen es mal schaffen zusammen einen 'quasi standard' fuer SIMD zu machen, sonst wird alles so bleiben wie es ist.

damit schadet sich AMD jedesmal mehr als es bringt.

[Bokill]

ganz locker bleiben, du hast gesagt ISAs wuerden nie zusammenarbeiten, Nein das habe ich nicht gesagt.

Schon deswegen nicht, weil eine ISA keine Firma ist sondern lediglich ein Instruktionssatz für einen Prozessor/Chip.

Zudem hatte ich Konsortien erwähnt, die durchaus innerhalb einer ISA den (konkurrierenden) Wildwuchs von Varianten verhindern/abgleichen.
Das ist einer der wesentlichen Voraussetzungen, damit völlig fremde Instruktionssätze anderer Architekturen sich semantisch überhaupt angleichen (in welcher Form auch immer).

Ausserdem hatte ich AMDs SSE+ Initiative vor Augen, die die Abbildung von verschiedenen Instruktionssets ermöglicht.
So kann AMD eine recht umfassende Sammlung von SIMD-Befehlen definieren, andere "fremde" Anweisungen abgreifen und in die eigene Syntax "umbiegen".
Auch deswegen kann ich gar nicht kategorisch gesagt haben: "ISAs wuerden nie zusammenarbeiten".

Ich habe sogar ein Szenario entworfen wann es gehen könnte: -> Wenn die Firmenpolitik derartiges für sinnvoll erachtet.
Das ist kein technisches Argument, sondern ein wirtschaftspolitisches Argument.

ich hab lediglich ein weiteres beispiel dafuer genannt bei dem es gemacht wurde, nachdem dir das beispiel mit 3dnow nicht gereicht zu haben scheint. Fertigungstechnik ist ein völlig andere Baustelle, da lohnt es sich quasi "sofort" für die beteiligten Firmen zusammenzuarbeiten.
Da geht es um Millionen/Milliardenbeträge (z.B in US-Dollar, Euro), wenn dort falsche Schwerpunkte beschlossen wurden.

Am Beispiel VIA und der SIMD-Erweiterung 3DNow! sieht man hingegen, dass mitunter nur einen Federstrich kostet einen Instruktionssatz (teilweise) nicht mehr zu unterstützen

MFG Bobo(2008 )

[Coda]

Ich hab keine opensource treiber für Intels WLan notebook karten gefunden.
Die sind aber im kommen.

[KonKorT]

Großes Hickhack um SSE5.

Aus SSE5 wird AVX, XOP und FMA4

Quelle: Hardware-Infos (http://www.hardware-infos.com/news.php?news=2936)

[deekey777]

http://support.amd.com/us/Processor_TechDocs/43479.pdf

Wenn es jemandem langweilig ist...

[Gast_mboeller]

zu faul zum einloggen:

Diskussion zum Bulldozer auf Beyond3d:

Titel: AMD Bulldozer Core Patent Diagrams
http://forum.beyond3d.com/showthread.php?t=54018

die links aus dem 1. Posting sind besonders interessant:

http://citavia.blog.de/

http://www.planet3dnow.de/vbulletin/showthread.php?p=3849342#post3849342

http://brightsideofnews.com/news/2009/4/15/amds-next-gen-bulldozer-is-a-128-bit-crunching-monster.aspx?pageid=0


Wenns so kommt scheint der Bulldozer, wie hier im Thread schon angedeutet wirklich kein K7-Aufguss mehr zu werden.

[reunion]

AMDs SSE5 ist tot - lang lebe AVX (http://www.planet3dnow.de/vbulletin/showthread.php?t=362353)

Schon am Titel fällt auf: SSE5 ist tot. Liest man weiter im Dokument fällt sofort das neue Befehlsformatschema auf, das Intels AVX entspricht. Sieht man allerdings genauer hin, stellt man fest, dass gelegentlich dann aber doch ein paar Bits unterschiedlich sind.[...]

Achterbahnfahrt: zuerst SSE5, dann AVX FMA4, dann AVX FMA3 ... Anzunehmen ist auch, dass AVX seinen Anteil an AMDs Verschiebung der Bulldozer-Architektur hat. Mit selbiger sollte SSE5 eingeweiht werden, aber mit AVX wurde wohl eine Anpassung und somit auch eine Verschiebung nötig.[...]

Das ist nun aber noch nicht das Ende der frohen Kunde. Nein, frei nach dem Motto "ist denn heute schon Weihnachten" garantiert Christie im selben Beitrag auch noch, dass Bulldozer-Kerne alle weiteren sonstigen Erweiterungen unterstützen werden, also auch SSSE3, SSE4.1, SSE4.2 und AES. Letzteres wird erst mit Intels 32nm CPUs erstmals auf dem Markt erscheinen.

[Gipsel]

AMDs SSE5 ist tot - lang lebe AVX (http://www.planet3dnow.de/vbulletin/showthread.php?t=362353)
Ja, das mit dem AVX, insbesondere dem FMA4 und FMA3 ist wirklich ein Possenspiel. AMD macht sein SSE5-Proposal öffentlich. Ein Jahr später kommt intel mit AVX und FMA4. AMD schmeißt daraufhin SSE5 über den Haufen und adaptiert AVX und FMA4, nur damit intel FMA4 cancelt und FMA3 (was prinzipiell schlechter ist als FMA4) einführt. Also bescheuerter geht es ja kaum.

[HOT]

...vor allem da Sandy-Bridge überhaupt kein FMA unterstützen wird, sondern das offenbar auf Larrabee abgewälzt wird.

[AnarchX]

Haswell (2012) soll wohl FMA mitbringen (http://translate.google.com/translate?u=http%3A%2F%2Fwww.canardplus.com%2Fdossier-35-200-Processeur_de_Nehalem_a_Haswell.html&hl=en&ie=UTF8&sl=fr&tl=en). Wobei hier auch denkbar wäre, dass Intel einen Pool an LRB-ähnlichen Cores integriert.

[w0mbat]

Interlagos (Bulldozer) will have 16 cores. Valencia, will have 8. Both will be significantly faster than Magny Cours.
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=136565#p163391

Ich bin echt gespannt.

[AnarchX]

Das hatte man in einer Präsentation auch schon mal angedeutet:
http://img200.imageshack.us/img200/6996/3187.jpg
http://techreport.com/discussions.x/16797

[Tarkin]

Valencia (Server) entspricht dann quasi dem 8 Kerne Bulldozer fürn Desktop .... als "Orochi" in den Roadmaps.

wesentlich schneller als 12 Deneb-Kerne kling wirklich SEHR interessant!

[Avalox]

Das hatte man in einer Präsentation auch schon mal angedeutet:



Was soll den das für ein Kern sein, welcher im Jahr 2009 überproportional Intenger-Rechenleistung haben soll?
Was hat man sich den damals bei gedacht auf der AMD Seite?

[SavageX]

Was soll den das für ein Kern sein, welcher im Jahr 2009 überproportional Intenger-Rechenleistung haben soll?
Was hat man sich den damals bei gedacht auf der AMD Seite?

Kann ein Nebeneffekt des Benchmarks sein. SpecFP hängt sehr stark an der Speicherbandbreite, und da hat Istanbul nicht mehr zu bieten als Shanghai.

Magny-Cours hingegen mit vier (DDR3-)Kanälen wird gegen die derzeitige DDR2-Plattform wieder mehr Bandbreite pro Kern haben, so dass SpecFP wohl wieder ausgeglichener aussieht.

Natürlich unterstelle ich einfach nur, dass AMD hier den SpecFP heranzieht.

[Sorkalm]

Was soll den das für ein Kern sein, welcher im Jahr 2009 überproportional Intenger-Rechenleistung haben soll?

Steht drunter. Istanbul.
Und damals war am 22. April 2009. Ich denke mal, da kannte man Istanbul schon ziemlich gut.

[S940]

Natürlich unterstelle ich einfach nur, dass AMD hier den SpecFP heranzieht.
Für den Integerbench sicher nicht :D

[mboeller]

Valencia (Server) entspricht dann quasi dem 8 Kerne Bulldozer fürn Desktop .... als "Orochi" in den Roadmaps.

wesentlich schneller als 12 Deneb-Kerne kling wirklich SEHR interessant!

Naja, gerade bei der Integer-Leistung sieht man bei der Grafik eigentlich keine Verbesserungen.

~ 35 Punkte für den 16 Kern Bulldozer / Interlagos => 2,19 Punkte pro Kern
~ 26 Punkte für den 12 Kern Magny Cours => 2,17 Punkte pro Kern

Also keine wirkliche Verbesserung pro Kern zu sehen. Bei normalen Anwendungen die 2011 vielleicht 2-4 Kerne wirklich auslasten wird sich ein Bulldozer also anscheinend genauso verhalten wie ein K10 (Mhz für Mhz)

[SavageX]

Für den Integerbench sicher nicht :D

Schon klar. ;) Hier schien es aber in erster Linie um das "seltsame" Skalierungsverhalten bei FP zu gehen.

[S940]

Schon klar. ;) Hier schien es aber in erster Linie um das "seltsame" Skalierungsverhalten bei FP zu gehen.
Hmm ... DU antwortetest aber doch auf Integer:
Was soll den das für ein Kern sein, welcher im Jahr 2009 überproportional Intenger-Rechenleistung haben soll?
... ein Nebeneffekt des Benchmarks sein. SpecFP hängt sehr stark an der Speicherbandbreite


Naja .. egal ;-)
@mboeller:
Jein ... das stimmt eventuell für Serverthreads, wenn die Cluster getrennt arbeiten, aber für die Cluster gibts mehrere, patentierte Betriebsmodi. Im Orochi / Desktop, werden die vermutlich zusammen arbeiten. Bin mal gespannt, was das dann bringt ..

ciao

Alex

[Tarkin]

Naja, gerade bei der Integer-Leistung sieht man bei der Grafik eigentlich keine Verbesserungen.

~ 35 Punkte für den 16 Kern Bulldozer / Interlagos => 2,19 Punkte pro Kern
~ 26 Punkte für den 12 Kern Magny Cours => 2,17 Punkte pro Kern

Also keine wirkliche Verbesserung pro Kern zu sehen. Bei normalen Anwendungen die 2011 vielleicht 2-4 Kerne wirklich auslasten wird sich ein Bulldozer also anscheinend genauso verhalten wie ein K10 (Mhz für Mhz)

Die Balken lügen würde ich sagen ;)

"Both (Interlagos und Valencia) will be significantly faster than Magny Cours"

D.h. auf Deutsch: 8 Kerne (Valencia) schneller als 12 Kerne.

[Der_Korken]

Man sieht ja, dass die Balken nach oben hin nicht ganz abschließen, sondern nur leicht verschwimmen. Das soll wohl andeuten, dass nach oben hin noch Luft ist. Schließlich kann AMD das aus jetziger Sicht wohl schlecht schätzen, wie hoch genau die Taktraten ausfallen werden. Wenn der 8-Kern Bulldozer den 12-Kern Deneb aber stehen lässt, wäre das echt ein Hammer. Allerdings ist 2011 sehr spät. Man wird mit dem Prozessor wohl wieder nur auf Intels jetzige Nehalem-Architektur aufschließen können, während Intel 2011 bereits die nächste Architektur vorstellen wird.

[StefanV]

Naja, gerade bei der Integer-Leistung sieht man bei der Grafik eigentlich keine Verbesserungen.
Mit oder ohne SMT? ;)

[mboeller]

Mit oder ohne SMT? ;)

Natürlich mit SMT

Das sind Server-CPUs mit Serverworkloads. Es macht also keinen Sinn irgendwelche Single-Thread Benchmarks als Vergleich zu nehmen. Die Istanbul-Benchmarks zeigen außerdem auch sehr deutlich das man hier "alle Kerne unter Volllast" als Vergleichsmaßstab benutzt hat.

[edit]
Außerdem:
Sei froh das ich den Interlagos nicht mit dem Istanbul verglichen habe:

~ 17,5 Punkte für den 6-Core Istanbul; macht ~2,9 Punkte pro Kern
~ 35 Punkte für den 16-Core Interlagos, macht nur ~2,2 Punkte pro Kern

Ergo ist der Interlagos gegenüber dem Istanbul sogar ein Rückschritt in der pro-Core Leistung!!

[SavageX]

Hmm ... DU antwortetest aber doch auf Integer:


Jein. Also ja, err.. nein. Also Du hast schon Recht. Ich wollte nur herausstreichen, dass nicht die Integer-Leistung überproportional anwächst, sondern dass die FP-Leistung nicht mitskaliert, was an einer SpecFP-Eigenart (geil auf Speicheranbindung) liegen könnte. Das setzt voraus, dass SpecFP tatsächlich als (FP, natürlich) Benchmark herangezogen wurde.

Hätte ich genauer formulieren können, richtig.

[Tarkin]

Allerdings ist 2011 sehr spät. Man wird mit dem Prozessor wohl wieder nur auf Intels jetzige Nehalem-Architektur aufschließen können, während Intel 2011 bereits die nächste Architektur vorstellen wird.

16 Kerne sind 2011 zu spät? Naja... sehe ich nicht so.

Intels Sandy Bridge wird kommt Ende 2010 mit 4 bis 8 Kernen + HT.

Magny-Cours sollte 2010 völlig ausreichen um gegen den monströsen 8-Core Beckton bestehen zu können.

2011 wird dann die Bulldozer Architektur mit dem 8-Core Valencia und 16 Core Interlagos eingeführt... So wie es laut aktuellen Roadmaps aussieht, wird AMD aufholen. Wenn AMD es dann noch schafft die Pro-MHz Leistung zu steigern (und die Aussage "8-Core schneller als 12-Core" deutet darauf hin) braucht man sich nicht zu verstecken ... ganz im Gegenteil!

[IVN]

16 Kerne sind 2011 zu spät? Naja... sehe ich nicht so.

Intels Sandy Bridge wird kommt Ende 2010 mit 4 bis 8 Kernen + HT.

Magny-Cours sollte 2010 völlig ausreichen um gegen den monströsen 8-Core Beckton bestehen zu können.

2011 wird dann die Bulldozer Architektur mit dem 8-Core Valencia und 16 Core Interlagos eingeführt... So wie es laut aktuellen Roadmaps aussieht, wird AMD aufholen. Wenn AMD es dann noch schafft die Pro-MHz Leistung zu steigern (und die Aussage "8-Core schneller als 12-Core" deutet darauf hin) braucht man sich nicht zu verstecken ... ganz im Gegenteil!
Auch diese Steigerung (~50%) würde gerade mal ausreichen um mit dem Nehalem gleichzuziehen...

[w0mbat]

Von welcher 50%tigen Steigerung redet ihr? Ihr wollt doch nicht ernsthaft die Leistung des BD aus einer billigen und nach oben offenen Präsentation lesen, oder?

[StefanV]

Natürlich mit SMT

Das sind Server-CPUs mit Serverworkloads. Es macht also keinen Sinn irgendwelche Single-Thread Benchmarks als Vergleich zu nehmen. Die Istanbul-Benchmarks zeigen außerdem auch sehr deutlich das man hier "alle Kerne unter Volllast" als Vergleichsmaßstab benutzt hat.
Also wenn du schon postest, dann bitte nur, wenn du verstanden hast, was "der andere" geschrieben hat.
Dein Posting ist ein Beweis dafür, das du keine Ahnung hast, was ich überhaupt rein geworfen hast...

Mir ist schon klar, das hier multithreaded Software benutzt wurd, ich fragte aber, ob SMT eingeschaltet war!
SMT ist Simultaneous multithreading, für die Intel Fanboys: Hyper Threading.

War das beim Bulldozer aktiv oder nicht?!

[S940]

War das beim Bulldozer aktiv oder nicht?!
SMT gibts beim Bulldozer nicht, die Frage erübrigt sich damit :cool:

[Der_Korken]

16 Kerne sind 2011 zu spät? Naja... sehe ich nicht so.

Intels Sandy Bridge wird kommt Ende 2010 mit 4 bis 8 Kernen + HT.

Magny-Cours sollte 2010 völlig ausreichen um gegen den monströsen 8-Core Beckton bestehen zu können.

2011 wird dann die Bulldozer Architektur mit dem 8-Core Valencia und 16 Core Interlagos eingeführt... So wie es laut aktuellen Roadmaps aussieht, wird AMD aufholen. Wenn AMD es dann noch schafft die Pro-MHz Leistung zu steigern (und die Aussage "8-Core schneller als 12-Core" deutet darauf hin) braucht man sich nicht zu verstecken ... ganz im Gegenteil!

Gut, in der Anzahl der Kerne wäre AMD da vermutlich vorne. Aber selbst wenn AMDs 8-Core-Bulldozer schneller wäre als ein 12-Core-Deneb würde man damit pro Kern in etwa das Niveau erreichen, das der Nehalem heute schon vorgibt. Sandy Bridge wird bis dahin bei der Effizienz sicherlich wieder zulegen. Intel wird damit bei der Leistung/Watt wieder vorne liegen, da ein reines Erhöhen der Kerne wie AMD es macht zwar Leistung bringt, aber eben nicht unbedingt effizient ist. Eine höhere IPC zahlt sich eben auch aus.

[StefanV]

SMT gibts beim Bulldozer nicht, die Frage erübrigt sich damit :cool:
Laut meiner Information eben doch, zumindest in einer "vereinfachten Version" (technisch)...

Man verdoppelt die ALUs hinterm Decoder einfach.

[deekey777]

Deine Informationen sind nicht zufällig Äußerungen von Dresdenboy? (http://www.planet3dnow.de/vbulletin/showthread.php?p=3849342#post3849342)

[CrazyIvan]

@S940
Kann man das jetzt schon so endgültig beantworten? Ich weiß, dass AMDs Standpunkt immer der war, dass man SMT nicht braucht, sondern lieber viele "echte Cores" verbaut. Andererseits beweist IMHO der Nehalem, wie nützlich SMT ist. Beim P4 habe ich das auch eher als Kaschieren architekturbedingter Schwächen abgetan - mittlerweile sehe ich das ein wenig anders.
Grundsätzlich sollte ja SMT negativ mit der Anzahl physikalischer Cores skalieren. Nur frage ich mich, ob nicht intel den Sweet-Spot für die nächsten Jahre getroffen hat, indem man im Consumer-Bereich erstmal nicht großartig über 4 Kerne hinausgeht und diese dank SMT besser auslastet. AMD wiederum will also bald mit 8 Kernen antreten, von denen kein Mensch weiß, ob sie durch Anwendungen und vor allem Spiele auch ausreichend gewürdigt werden.
Ich würde jedenfalls bessere Chancen mit einem 6-Kerner mit ordentlicher pro Core Performance und SMT sehen, als mit einem 8-12 Kern Siliziummonster.

[IVN]

@S940
Kann man das jetzt schon so endgültig beantworten? Ich weiß, dass AMDs Standpunkt immer der war, dass man SMT nicht braucht, sondern lieber viele "echte Cores" verbaut. Andererseits beweist IMHO der Nehalem, wie nützlich SMT ist. Beim P4 habe ich das auch eher als Kaschieren architekturbedingter Schwächen abgetan - mittlerweile sehe ich das ein wenig anders.
Grundsätzlich sollte ja SMT negativ mit der Anzahl physikalischer Cores skalieren. Nur frage ich mich, ob nicht intel den Sweet-Spot für die nächsten Jahre getroffen hat, indem man im Consumer-Bereich erstmal nicht großartig über 4 Kerne hinausgeht und diese dank SMT besser auslastet. AMD wiederum will also bald mit 8 Kernen antreten, von denen kein Mensch weiß, ob sie durch Anwendungen und vor allem Spiele auch ausreichend gewürdigt werden.
Ich würde jedenfalls bessere Chancen mit einem 6-Kerner mit ordentlicher pro Core Performance und SMT sehen, als mit einem 8-12 Kern Siliziummonster.
Auch beim P4 ist es sehr nützlich. Ich hatte früher einen Desktop-PC mit einem Northwood 2,8 GHZ + HT drin. Den habe ich immer dem Dothan 1,6 (in meinem Notebook) als vergleichbar schnell eingeschätzt. Allerdings nur bei single-threaded Aufgaben. Beim Multi-Tasking sieht der Dothan kein Land. Nicht weil die Leistung des P4 auf einmal steigt, nein, sondern weil sie besser eingesetzt wird. So kann es z.B. mit dem Dothan passieren, das die Mucke im Hintergrund beginnt zu stottern, wenn man beim Surfen auf eine Flash-überladene Seite stößt, mit dem P4 ist mir das nie passiert - eigentlich ist mir mit dem generell nie passiert, dass der ganze PC lahmgelegt wurde, nur weil eine rechenintensive und gierige App aktiviert wurde...

In Zeiten wo es keine Mehrkern-CPUs gab, empfand ich HT als einen Segen. :)

[S940]

Laut meiner Information eben doch, zumindest in einer "vereinfachten Version" (technisch)...

Man verdoppelt die ALUs hinterm Decoder einfach.
Nene Du, das ist "etwas" komplizierter und hat technisch mit SMT nix am Hut. Das Ergebnis mag am Ende ähnlich sein, aber man sollte den Namen da nicht benützen. Les mal im Thread von deekey777 nach, wie das genau geht ;-)

@IVN:
Das ist definitiv:
2. It has been said before and I will say it again. We will not have HyperThreadng in any of our products any time soon. There are places where it gives you better performance, places where it hurts performance. We will focus on more standardized places to deliver performance.
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=136452&st=0&sk=t&sd=a&hilit=smt&start=25#p160770

@deekey777:
Klar, wieso ? ;-)

ciao

Alex

[robbitop]

Laut den Patentrecherchen von Dresdenboy und Hans van de Vries soll der Bulldozer CMT haben. Das Ding soll die spekulatives Multithreading beherrschen (i.e. mehrere Zweige einer If-Anweisung werden parallel durch die 2x Cluster durchgerechnet und das passende Ergebnis wird genutzt, das andere verworfen - das sollte, sofern es funktioniert, eine Steigerung der IPC im single-threaded Bereich geben). Es ist IMO eine konsequente Weiterentwicklung von SMT. Kerne hat man irgendwann sowieso genug vorhanden, so dass mehr virtuelle Kerne nicht notwendig sind (Amdahl ahoi). Aber mit CMT kann man die Performance eben doch noch steigern.
SMT war der richtige Schritt bis zu einer gewissen Anzahl von Kernen. Den hat AMD, wohl aus Ressourcenmangel, ausgelassen.

Ob diese Patente tatsächlich auch so in den Bulldozer eingeflossen sind, ist die andere Frage. Es ergibt sich jedenfalls aus den Patentrecherchen schon ein schlüssiges Bild über die µArch vom Bulldozer und die sieht nicht schlecht aus.

[Undertaker]

Ist soetwas wie CMT im Bereich von Desktop- und ganz speziell auch Mobilprozessoren wirklich sinnvoll? Die mögliche Performancesteigerung steht außer Frage, aber die Energieeffizienz müsste durch die Vielzahl verworfener Rechenschritte doch nennenswert leiden....

Und btw: Sollte soetwas nicht ohne größere Änderungen auf jeder CPU mit SMT/HT nutzbar sein, um diese Techniken auch in Szenarien geringer Parallelisierung nutzen zu können? Da wäre die Frage, warum nicht schon P4 oder aktuell Nehalem diese Möglichkeit nutzen.

[robbitop]

Ist soetwas wie CMT im Bereich von Desktop- und ganz speziell auch Mobilprozessoren wirklich sinnvoll? Die mögliche Performancesteigerung steht außer Frage, aber die Energieeffizienz müsste durch die Vielzahl verworfener Rechenschritte doch nennenswert leiden....
Ist doch sinnvoller alle Einheiten rechnen zu lassen (und damit die Performance zu steigern), als wenn man sie idlen lassen würde. ;) Die gesteigerte IPC kann man nutzen, um weniger Takt für die gleiche Endleistung zu brauchen und damit auch eine geringere TDP. Dein Argument zählt natürlich genauso auch für/gegen SMT.

Und btw: Sollte soetwas nicht ohne größere Änderungen auf jeder CPU mit SMT/HT nutzbar sein, um diese Techniken auch in Szenarien geringer Parallelisierung nutzen zu können? Da wäre die Frage, warum nicht schon P4 oder aktuell Nehalem diese Möglichkeit nutzen.
Ich bin kein CPU-Guru, aber das was ich an Patenten gesehen habe, war relativ komplex, um spekulatives MT zu ermöglichen. Ich glaube, die µArch muss schon ganzheitlich darauf ausgelegt werden. Genaueres musst du dir von jemanden wie BBSR erfragen.

[Aquaschaf]

Ist soetwas wie CMT im Bereich von Desktop- und ganz speziell auch Mobilprozessoren wirklich sinnvoll? Die mögliche Performancesteigerung steht außer Frage, aber die Energieeffizienz müsste durch die Vielzahl verworfener Rechenschritte doch nennenswert leiden....

Wenn die spekulativen Pfade nicht zu lang sind, dann kann es sich lohnen. Nach einem branch miss muss man sonst ja auch Rechenschritte verwerfen.

[mboeller]

Also wenn du schon postest, dann bitte nur, wenn du verstanden hast, was "der andere" geschrieben hat.
Dein Posting ist ein Beweis dafür, das du keine Ahnung hast, was ich überhaupt rein geworfen hast...

Mir ist schon klar, das hier multithreaded Software benutzt wurd, ich fragte aber, ob SMT eingeschaltet war!
SMT ist Simultaneous multithreading, für die Intel Fanboys: Hyper Threading.

War das beim Bulldozer aktiv oder nicht?!

Wie auch schon von S940 geschrieben wird es beim Bulldozer kein SMT geben. AMD entwickelt anscheined was besseres. Das ganze heißt CMT bzw. Cluster-based Multi-threading
http://citavia.blog.de/2009/07/07/more-details-on-bulldozers-multi-threading-and-single-thread-execution-6464533/


Und um das ganze nochmal darzulegen. Warum sollte AMD ServerCPUs ohne SMT/CMT in einer Präsentation darstellen. Bei sowas geht es darum möglichst gut dazustehen. Deshalb meine Antwort. Wenn du glaubst das AMD sich hier in einer Präsentation selbst schlecht aussehen lässt indem man "absichtlich" auf sowas für Server Workloads hilfreiches "verzichtet" kann ich dir auch nicht mehr helfen.

[edit2]: gerade gelesen. robbitop hat es auch schon sehr gut erklärt

[robbitop]

Ich glaube, dass Bulldozer noch gar nicht soweit ist, dass man etwas benchen geschweige denn ein- oder ausschalten kann. Das Ding existiert vermutlich aktuell nur in Verilog.

[mboeller]

Ich glaube, dass Bulldozer noch gar nicht soweit ist, dass man etwas benchen geschweige denn ein- oder ausschalten kann. Das Ding existiert vermutlich aktuell nur in Verilog.

Hihi.. schon klar.
Aber in einer Präsentation "rechnest" du sowas wie CMT doch möglichst optimistisch mit rein, oder? Präsentationen zeigen immer die best-mögliche "Realität" oder zumindest das was die Chefs für die bestmögliche Realität halten. "Powerpoint-Engineering" ist nicht umsonst ein Schimpfwort. ;)

[S940]

Ich glaube, dass Bulldozer noch gar nicht soweit ist, dass man etwas benchen geschweige denn ein- oder ausschalten kann. Das Ding existiert vermutlich aktuell nur in Verilog.
Denke ich auch.

Noch ein Addendum zum früheren Post:
Was Du noch vergessen hast, der SpMT Modus ist nur ein Betriebsmodus ... dabei hat man eben auch nur 1 Thread. Anstatt den 2ten Cluster aber spekulieren zu lassen, kann der auch einen eigenständigen 2ten Thread bearbeiten, oder wenn man möchte gibts noch Modus 3, da rechnen beide Cluster das gleiche. Logischerweise nur in Spezialfällen sinnvoll.

Edit:
@mboeller:
Eher nicht, die wirklichen Leistungsdaten will man bis zum Schluss geheim halten, um die Reaktion des Mitbewerbers zu erschweren. ATi verfälschte bei den letzten DX11 Demos z.B. extra die FPS Anzeige, damit nVidia keine Rückschlüsse auf die GPU Leistung ziehen kann ;-)
Das ist bei den CPUs nicht anders. Die Folien für die Analysten, die von Technik eh keine Ahnung haben, sind nicht wirklich wichtig. Hauptsache sie zeigen nach oben und haben ne schöne Farbe ^^

ciao

Alex

[StefanV]

Deine Informationen sind nicht zufällig Äußerungen von Dresdenboy? (http://www.planet3dnow.de/vbulletin/showthread.php?p=3849342#post3849342)
Öhm eigentlich schon...
Ist aber schon 'ne Weile her, das ich den Thread mir anschaute...

[mboeller]

@mboeller:
Eher nicht, die wirklichen Leistungsdaten will man bis zum Schluss geheim halten, um die Reaktion des Mitbewerbers zu erschweren. ATi verfälschte bei den letzten DX11 Demos z.B. extra die FPS Anzeige, damit nVidia keine Rückschlüsse auf die GPU Leistung ziehen kann ;-)
Das ist bei den CPUs nicht anders.

hoffen wir mal das das stimmt. Ansonsten wäre der Interlagos wirklich schlecht.

16 Core Interlagos = ~35 Punkte (macht 2,2 Punkte pro Core)
6 Core Istanbul = ~17,5 Punkte (macht 2,92 Punkte pro Core)

Wenn man dann noch die FLOPS-Werte miteinander vergleicht (~45 / ~13,75) dann sollte der Interlagos hier mit ca. 3.2GHz laufen ( (45/16) /(13,75/2,6/6) = 3,19 ). Taktbereinigt wäre der Interlagos also noch langsamer. 2,6/3,2 x 2,2 = 1,8 <-> 2,9 beim Istanbul! Der Istanbul wäre also MHz für MHz bei Integer 60% schneller!

ABER: gestern abend ist mir eine Idee gekommen. War wäre wenn der Interlagos kein richtiger 16 Core Chip ist, sondern ein 8 x DualCore Chip? Also nur 8 CMT-Cores die bei Multithreading-Software wie 16 Core arbeiten und deshalb auch so beworben werden. Die FP-Einheiten müssten dann aber 256bit breit sein damit der FLOPS-Wert im Diagramm wieder stimmt.

[robbitop]

Soweit ich weiß, sind die SIMDs 256 Bit breit (wegen AVX).

[S940]

ABER: gestern abend ist mir eine Idee gekommen. War wäre wenn der Interlagos kein richtiger 16 Core Chip ist, sondern ein 8 x DualCore Chip? Also nur 8 CMT-Cores die bei Multithreading-Software wie 16 Core arbeiten und deshalb auch so beworben werden.
Mit der Idee bist Du nicht der erste, ich DDBoy und HOT rätseln drüben bei P3D schon lange, wie die Kerne gemeint sind ... sind es 8 Kerne mit je 2 INT Cluster, oder "echte" 16 mit 32 Int Cluster ...
Logische Schlussfolgerung/Kompromiss aufgrund der Größe waren 8 Kerne für Interlagos, bzw. 4 fürs einzelne (Valencia) DIE. 8/16 pro Die wäre wohl zu groß, selbst in 32nm.
Die FP-Einheiten müssten dann aber 256bit breit sein damit der FLOPS-Wert im Diagramm wieder stimmt.
Nicht notwendigerweise, 3Operand Befehle & FMA böten schon bei 128bit ein schönes Leistungsplus.
Hans de Vries meinte auf aceshardware oder amdzone, dass eine erste Implementierung mit 128bit besser wäre, 256bit AVX Befehle würden dabei in zwei 128bit Schritten/Takten berechnet. Aber mal abwarten, für eine shared FPU wären 256bit, die sich in 2x128bit (pro Takt) splitten ließen, auch nicht verkehrt. Link kann ich gerade nicht suchen, amdzone.com spackt bei mir.

ciao

Alex

[robbitop]

Ich vermute, dass es eine Quadcore- (Nachfolger von Deneb/Shanghai) und eine Octacorevariante von Bulldozer geben wird. Die Octacorevariante (Nachfolger v. Istanbul) kann über MCM sicher auch als 16xCore Variante zusammengeklebt werden (Nachfolger von Magny Cours)

[HOT]

Das Wahrscheinlichste Scenario mMn ist, dass die erste BD-Generation aus einem Design bestehen wird - mit 4 Kernen und 8 Clustern/Threads. Dieser Chip würde dann als Orochi, Valencia verkauft auf AM3/C32 und auchnoch als geklebter 8-Kerner mit 16Clustern/Threads für G34 bereit stehen, wohlgemerkt würde man so alles mit dem gleichen Die erschlagen. Später (vllt. Anfang 2012) könnte dann wahrscheinlich noch ein 6-Kern/12Thread Die folgen, ähnlich wie beim Istanbul, womit die G34-Variante dann 12 Kerne/24 Cluster hätte. Durch die MCMs ist AMD ganz gut aufgestellt im Serverbereich und hat kaum Mehrkosten in Entwicklung und Produktion, die Intel für die Server-400mm²+-Monster ausgibt (Dunnington oder Beckton).
Auch nach Unten hin passiert ja offenbar nichts in 2011 mit BD, da Llano ja K10-Basierend sein soll, also ein 32nm-Propus mit etwas mehr L2-Cache und IGP (mMn nicht mehr als 150mm², eher deutlich darunter. Der IGP wird sicherlich erheblich kleiner werden als der IGP auf Sandy und bei Cachedichte sollte sich bei 32nm auch einiges getan haben). Warum Llano kein BD wird ist unklar, es könnte einfach sein, dass ein 2K/4CL-BD unwirtschaftlicher ist als ein K10, immerhin wird zu dem Zeitpunkt fast der gesamte Softwarebereich auf 4-Kerne ausgerichtet sein. Man bräuchte also die rSMT-Fähigkeit des BD nicht und wäre vermutlich nicht wesentlich schneller als 4 echte K10-Kerne und hätte trotzdem ein grösseres oder heißeres Die. Das Llano Die soll ja schließlich auch in die Notebooks wandern, da muss man also Kompromisse eingehen.

[mboeller]

Das Wahrscheinlichste Scenario ....... .


Was mir an der idee mit den geklebten CPUs (wie beim Magny Cours) nicht schmeckt ist, das anscheinend der Snoop-Filter dadurch nicht funktioniert. Vergleiche einmal die Integer-Werte zw. Istanbul und Magny Cours. Magny Cours schneidet dabei ziemlich schlecht ab (so wie übrigens der Interlagos auch).

[S940]

Was mir an der idee mit den geklebten CPUs (wie beim Magny Cours) nicht schmeckt ist, das anscheinend der Snoop-Filter dadurch nicht funktioniert. Vergleiche einmal die Integer-Werte zw. Istanbul und Magny Cours. Magny Cours schneidet dabei ziemlich schlecht ab (so wie übrigens der Interlagos auch).
Sollte kein Problem sein ... das Problem ist eher, dass die MCMs wegen der Verlustleistung niedriger takten ...

@HOT:
Danke fürs nochmalige erklären :)

[StefanV]

Was mir an der idee mit den geklebten CPUs (wie beim Magny Cours) nicht schmeckt ist, das anscheinend der Snoop-Filter dadurch nicht funktioniert. Vergleiche einmal die Integer-Werte zw. Istanbul und Magny Cours. Magny Cours schneidet dabei ziemlich schlecht ab (so wie übrigens der Interlagos auch).
Naja, das sollte nicht daran liegen, eigentlich.
Da kannst eher 'nen BIOS Fehler oder so vermuten.

PS: denk auch dran, das nur der Istanbul aka 6 Kerner das D0 Step hat, entsprechend auch nur der Snoopfilter...

Sollte kein Problem sein ... das Problem ist eher, dass die MCMs wegen der Verlustleistung niedriger takten...
Oder man eine recht derbe TDP hat...

[mboeller]

PS: denk auch dran, das nur der Istanbul aka 6 Kerner das D0 Step hat, entsprechend auch nur der Snoopfilter...


Magny Cours besteht doch aus 2 Istanbul, oder?

Und wenn du dir die FP-Punkte anschaust kann der Magny Cours nicht wirklich niedrig getaktet sein:

Floatingpoint: ~13,9 <-> ~26,8 Punkten (= 1:1,93 => Magny Cours würde damit mit ca. 2,5GHz laufen)

=> Integer: ~17,5 <-> ~26,5 Punkten (= 1:1,51 => Istanbul zeigt bei Integer eine wesentlich bessere proMHz / proCore Leistung, die ca. 27% höher ist)

[edit: Rechenfehler]

[S940]

Magny Cours besteht doch aus 2 Istanbul, oder?
Mehr oder minder, JF reitet immer drauf rum, dass dem nicht so ist und der MCours aus 2 Lisbon Cores besteht .. aber der Unterschied wird sich auf ein neues Stepping/Revision beschränken, z.B: D1.
Und wenn du dir die FP-Punkte anschaust kann der Magny Cours nicht wirklich niedrig getaktet sein:
Ohne jetzt genau auf die Zahlen geschaut zu haben, bei SpecFP muss man auch den schon auf der letzen Seite erwähnten Punkt miteinbeziehen: Speicherbandbreite .. Die SpecRate werte sind da extrem abhängig .. Istanbul hat nur DDR2, MC bekommt QuadChannel DDR3 ...

Oder man eine recht derbe TDP hat...
Jo, aber das will man bei Servern eher nicht ... gibt ein paar SE Parts, aber naja. Wobei man daran sieht, dass das Bildchen nicht viel aussagt ... Istanbul gibts von 2 Ghz bis 2,8 ... die Spannbreite ist da einfach zu groß, als das man viel rauslesen könnte.

ciao

Alex

[StefanV]

Du darfst aber auch nicht vergessen, das das quasi ein 'Doppelsockel' für High Performance ist, hier ersetzen 4 G34 Sockel 8 Sockel F.

Allerdings denke ich nicht, das man über 175W TDP geht...

[Tarkin]

Das Wahrscheinlichste Scenario mMn ist, dass die erste BD-Generation aus einem Design bestehen wird - mit 4 Kernen und 8 Clustern/Threads. Dieser Chip würde dann als Orochi, Valencia verkauft auf AM3/C32 und auchnoch als geklebter 8-Kerner mit 16Clustern/Threads für G34 bereit stehen, wohlgemerkt würde man so alles mit dem gleichen Die erschlagen. Später (vllt. Anfang 2012) könnte dann wahrscheinlich noch ein 6-Kern/12Thread Die folgen, ähnlich wie beim Istanbul, womit die G34-Variante dann 12 Kerne/24 Cluster hätte. Durch die MCMs ist AMD ganz gut aufgestellt im Serverbereich und hat kaum Mehrkosten in Entwicklung und Produktion, die Intel für die Server-400mm²+-Monster ausgibt (Dunnington oder Beckton).
Auch nach Unten hin passiert ja offenbar nichts in 2011 mit BD, da Llano ja K10-Basierend sein soll, also ein 32nm-Propus mit etwas mehr L2-Cache und IGP (mMn nicht mehr als 150mm², eher deutlich darunter. Der IGP wird sicherlich erheblich kleiner werden als der IGP auf Sandy und bei Cachedichte sollte sich bei 32nm auch einiges getan haben). Warum Llano kein BD wird ist unklar, es könnte einfach sein, dass ein 2K/4CL-BD unwirtschaftlicher ist als ein K10, immerhin wird zu dem Zeitpunkt fast der gesamte Softwarebereich auf 4-Kerne ausgerichtet sein. Man bräuchte also die rSMT-Fähigkeit des BD nicht und wäre vermutlich nicht wesentlich schneller als 4 echte K10-Kerne und hätte trotzdem ein grösseres oder heißeres Die. Das Llano Die soll ja schließlich auch in die Notebooks wandern, da muss man also Kompromisse eingehen.

jetzt bin ich komplett gaga ;)

Valencia bzw. Orochi haben doch 8 Kerne, oder nicht???

[S940]

Valencia bzw. Orochi haben doch 8 Kerne, oder nicht???
Das weiss eben keiner so genau was AMD mit "Kern" meint ... nen echten Kern mit 2 Clustern + FPU oder nur einen Cluster ... darum gehts doch gerade ;-)
Orochi steht ausserdem nur mit ">4 cores" in der Liste ... ich denke da werden die teildefekten Valencia Dies entsorgt. Naja ist ja jetzt auch schon so, teildefekte Denebs gibts nur im Desktopsegment.

@StefanV:
Klar, aber irgendwie musst Du das Teil kühlen ... das geht bei 2 DIEs im engen
Gehäuse viel schlechter als bei 2 DIEs auf getrennten Sockeln ;-)

Schon MCourse wird sicher keine Taktrekorde brechen ;-)

ciao

Alex

[StefanV]

Nein, es gibt auch teil defekte Istanbuls, die wohl als Opteron (1xxx Serie) für AM2/AM3 verkauft werden (eben weil der Deneb im Cx Step nicht auf AM2 laufen würde).

[S940]

Nein, es gibt auch teil defekte Istanbuls, die wohl als Opteron (1xxx Serie) für AM2/AM3 verkauft werden
Laut JF eben nicht ...

Are there plans to release the current Six-Core AMD Opteron processor in a quad-core variant in the future?

There are currently no plans, but there are plans for quad-core models of the C32 processor in the first half of 2010.
http://blogs.amd.com/work/2009/08/12/playing-20-questions-part-3/
Wundert mich ja auch, die Yields sind sicherlich nicht so toll .. aber wenn der AMD Cheffe das sagt ...
Solange keine D0 Quads auftauchen, glaub ichs Ihm auch ;-)

(eben weil der Deneb im Cx Step nicht auf AM2 laufen würde).HMmm wo steht das denn ? Gibt bei Gigabyte einige AM2 Boards, auf denen die Phenom2 laufen. Ich kenne Ähnliches nur vom Istanbul, der läuft nur auf split-voltage Socket-F Boards.

ciao

Alex

[mboeller]

Ohne jetzt genau auf die Zahlen geschaut zu haben, bei SpecFP muss man auch den schon auf der letzen Seite erwähnten Punkt miteinbeziehen: Speicherbandbreite .. Die SpecRate werte sind da extrem abhängig .. Istanbul hat nur DDR2, MC bekommt QuadChannel DDR3 ...


Noch ein letztes Mal zurück zu dem Chart auf Seite 5:

________Quad-Core_______ Istanbul_________ Magny Cours

Integer__10,5____________ 17,5____________ 26,5____________ Punkte

FP______11______________13,9____________ 26,8____________ Punkte


Scaling-Effekte:

1) Quad-Core -> Magny Cours:

Integer: _______Quad-Core -> Magny Cours: 10,5 / (3GHz x 4 Cores) x (2,5GHz x 12 Cores) = 26,25
FP:___________Quad-Core -> Magny Cours: 11,0 / (3Ghz x 4 Cores) x (2,5GHz x 12 Cores) = 27,5

=> Scaling vom PhenomII zum Magny Cours stimmt also => keine Verbesserung der Architektur. Die
Verbesserung der Speicherbandbreite kann 1:1 umgesetzt werden. Keine Verbesserung bei der
Integer-Leistung gegenüber dem PII (MHz für MHz; Core für Core)

=> die Annahme, das der Magny Cours 2,5GHz erreicht scheint zu stimmen


2) Istanbul -> Magny Cours:

Integer: _________Istanbul -> Magny Cours: 17,5 / (2,6GHz x 6 Cores) x (2,5GHz x 12 Cores) = 33,65
FP:______________Istanbul -> Magny Cours: 13,9 / (2,6Ghz x 6 Cores) x (2,5GHz x 12 Cores) = 26,7

=> Bei FP stimmt das Scaling wieder! Bei Integer aber nicht.

=> durch den Snooping-Filter, den nur der Istanbul hat ist der Istanbul bei Integer taktbereinigt
gegenüber dem PII und dem Magny Cours pro Kern um ca. 27% schneller!

=> wiederum passt die Annahme, das der Magny Cours 2,5GHz erreicht zumindest bei FP sehr gut.


=>
Entweder der Snooping-Filter funktioniert bei MCM nicht, oder AMD hält hier wirklich viel Leistung in der Hinterhand.

Was mich auch interessieren würde wäre wieviel schneller ein PII wäre wenn er so einen Snooping-Filter hätte.
Würde auch normale Software davon profitieren oder nur Server-Software? Mit, taktbereinigt 27% mehr Integer-Leistung
wäre wahrscheinlich ein PII um ein Stück schneller als ein Core2Quad (bei gleichem Takt) und auch ein gutes Stück näher am i7.

AMD sollte also den PII zum PIII aufrüsten und einen Snooping-Filter einbauen, insofern das auch für normale Software
Sinn macht.

[StefanV]

Der Snoopfilter bringt doch nur in MPS Umgebungen was, oder?!

[S940]

2) Istanbul -> Magny Cours:

Integer: _________Istanbul -> Magny Cours: 17,5 / (2,6GHz x 6 Cores) x (2,5GHz x 12 Cores) = 33,65
FP:______________Istanbul -> Magny Cours: 13,9 / (2,6Ghz x 6 Cores) x (2,5GHz x 12 Cores) = 26,7

=> Bei FP stimmt das Scaling wieder! Bei Integer aber nicht.

Jo, aber Du könntest auch rechnen:

Integer: _________Istanbul -> Magny Cours: 17,5 / (2,6GHz x 6 Cores) x (2,0GHz x 12 Cores) = 26,9
FP:______________Istanbul -> Magny Cours: 13,9 / (2,6Ghz x 6 Cores) x (2,0GHz x 12 Cores) = 21,3

Und den Rest der FP Zahlen dem Quad-DDR3 zurechnen. Würde auch zu den INT Werten passen, die sind eher latenzabhängig, könnten mit DDR3 also etwas kleiner ausfallen. Die werden ja auch kaum OC RAMs einsetzen ;-)

AMD sollte also den PII zum PIII aufrüsten und einen Snooping-Filter einbauen, insofern das auch für normale Software
Sinn macht.
Sollten sie nicht, da der Snoop Filter nur was bei >2P/DIEs Systemen bringt. Also ab G34 2P, da man dort aufgrund der MCM ja 4 DIEs hat.

Richtig lustig wirds bei 4P und 8P, da bringts dann einiges.

Edit:
@StefanV:
Genau.

ciao

Alex

[HOT]

Das weiss eben keiner so genau was AMD mit "Kern" meint ... nen echten Kern mit 2 Clustern + FPU oder nur einen Cluster ... darum gehts doch gerade ;-)
Orochi steht ausserdem nur mit ">4 cores" in der Liste ... ich denke da werden die teildefekten Valencia Dies entsorgt. Naja ist ja jetzt auch schon so, teildefekte Denebs gibts nur im Desktopsegment.[...]
Ne das glaube ich nicht. Orochi ist genau wie Valencia ein vollständiger Prozessor. Man wird sicher noch Teildeaktivierungen sehen wie z.B. Heka oder Callisto eine ist. So wie es aussieht, rechnet AMD lieber 1 Kern = 1 Cluster, was ja einfach nur Definitionssache wäre, also legitim, aber Marketingtechnisch besser kommt. Bisher scheint sich AMD nicht sicher zu sein, wie man handeln soll, das impliziert das ">4" auf der Folie. Sagt man jetzt aus, dass 1 Kern wirklich Kern ist (also 4) oder ob man einen Cluster als "Kern" bezeichnet (also 8). Ein BD-AMD-Marketing-Kern wäre also wahrscheinlich theoretisch etwas schwächer als ein K10 Kern, dafür hat man mehr und man kann 2 quasi zusammenschalten. Ich würde aber die Bezeichnung vorziehen, dass ein AMD Kern aus 2 Clustern besteht, die zusammen oder getrennt arbeiten können, je nach Bedarf und zwar unabhängig davon, wofür sich das Marketing von AMD entscheidet.
Orochi = Valencia = 1/2 Interlagos = 4 Kerne = 8 Cluster = 4-8 Threads, je nach Bedarf.

Eine Anm. und Spekulation meinerseits noch: Man sieht, dass AMD sich durchaus Gedanken gemacht hat, inwieweit sich Multithreading effektiv einsetzen lässt. Diese Design wäre ein Schritt absolut in die richtige Richtung, weil man einen guten Kompromiss zwischen Anwendungen gefunden hat, die wenig Threads brauchen und Anwendungen die mit vielen Threads was anfangen können - man kann das Threading nicht ins Unendliche vorantreiben. Von daher denke ich auch, dass es von nun an eine sehr lange Zeit bei 4 Kernen bleiben wird, die eher mehr Cluster bekommen werden. Vielleicht oder gar wahrscheinlich gingen die ursprünglichen Designs von K9 und K10 in eine ähnliche Richtung, da DDBoy ja die Patente schon seit geraumer Zeit sammeln dürfte und viele davon schon recht alt sind. Nur es leuchtet ein, dass ein Frontend für einen solchen BD-Kern sehr komplex ausfallen dürfte und das in 90nm und mit dem auf billige Massenfertigung ausgelegten 65nm-Prozess einfach nicht wirtschaftlich zu realisieren war und für ein 45nm-Design schlicht kein Geld mehr vorhanden war. Das mündete natürlich in dem K8-Derivat, das wir heute K10 oder K10.5 nennen ;) und das und wahrschienlich auch bis 22nm in Form des Llano begleiten dürfte.

[S940]

Ne das glaube ich nicht. Orochi ist genau wie Valencia ein vollständiger Prozessor. Man wird sicher noch Teildeaktivierungen sehen wie z.B. Heka oder Callisto eine ist.
Ja klar, aber solange es keine Codenamen für die teildefekten Teile gibt, nenn ich das auch noch Orochi ;-)
(Wobei ich auf den ganzen Codenamengedöns wirklich gerne verzichten könnte, es nervt einfach) ...
Nennen wir das Ding Server/Desktop 12h CPU oder wie auch immer und fertig :)

ciao

Alex

[HOT]

Hehe, stimmt, ich ertapp mich auch ständig dabei, wie ich Hekas und Callistos Deneb nenne ;). Ich mag aber Namen lieber als "12h", deswegen werd ich weiter Deneb dazu sagen :D, wobei man allerdings hier korrekterweise Shanghai sagen müsste. Es sind tatsächlich 4 Namen für ein und dasselbe Die - das ist echt nicht schön :D.

[Gast_mboeller]

Jo, aber Du könntest auch rechnen:

Integer: _________Istanbul -> Magny Cours: 17,5 / (2,6GHz x 6 Cores) x (2,0GHz x 12 Cores) = 26,9
FP:______________Istanbul -> Magny Cours: 13,9 / (2,6Ghz x 6 Cores) x (2,0GHz x 12 Cores) = 21,3



Stimmt. Das geht natürlich auch. Würde wahrscheinlich auch besser zu einer 12-Core CPU passen.

[mboeller]

Hi;

ich nochmal wegen dem Snoop-Filter beim Istanbul. Link: http://de.wikipedia.org/wiki/Bus_snooping

Irgendwie verstehe ich das ganze nicht. Ich dachte der L3-Cache "erledigt" das so nebenbei, bzw. die Kohärenz der Daten ist ein wichtiger Grund für den L3-Cache?

Aus meiner Sicht (und nach dem was ich gelesen habe) sollten doch im L3-Cache nur die abgeglichenen Daten der 4-6 CPU-Cores enthalten sein und damit ein Snoop-Filter eigentlich überflüssig sein??????

=> heißt das, das der L3-Cache auch beim Shanghai nicht richtig funktioniert (oder ich verstehe, sehr wahrscheinlich nur die Funktion nicht richtig) :)

=> der Snoop-Filter sollte doch eigentlich zwischen den einzelnen L2-Caches der einzelnen CPU-Cores eines Shanghai/Propus/Istanbul sitzen, oder?

könnte es sein, das die Propus-CPUs schon so einen Snoop-Filter zwischen den einzelnen L2-Caches besitzen? Ich bin eigentlich auf die ganze Idee gekommen als ich mir das Die-Bild eines Propus angeschaut habe und es eigenartig fand, das die L2-Caches bei den AMD CPUs immer in der Mitte des Die liegen (außer beim Istanbul).

[Coda]

Also so wie ich das verstanden haben geht's dabei um Anfragen von anderen CPUs.

[StefanV]

Öhm, bei AMD ist der L3 auch exklusiv, heißt, was da drin ist, ist nur da drin und nicht in den Caches der anderen Cores.
Der Snoop Filter vom Istanbul krallt sich AFAIR einen Teil des Speichers vom L3 Cache und fängt damit einige Fragen ab, so dass die L2 (oder gar L1 Caches) der Cores nicht bemüht werden müssen.
Wenn ich mich nicht irre natürlich nur...

HT assist is not much of a benefit with 2P, it is really a 4P play. You give up 1MB of cache in order to cache the lookup tables. So in a 4P, you give up 1MB but reduce the probe traffic and the latency of multiple hops. Good advantage. In 2P, you give up 1MB and you don't gain much in latency because there was only 1 hop to the other proc. HT assist may be available in C32, but it will be of little value; it is much more of a play on G34. [8]http://www.planet3dnow.de/vbulletin/showpost.php?p=3999609&postcount=3453

[S940@Gast]

Also so wie ich das verstanden haben geht's dabei um Anfragen von anderen CPUs.
Präzise, der Snoop Filter ist dazu da Informationen darüber zu speichern, welche CPUs Daten aus dem RAM einer best. CPU bzw. CPU-Sockels haben.

In 4P Systemen weiss man ohne Snoop Filter nicht, welche Cache/Speicher Inhalte nach einer Datenänderung in den Caches/Speichern andrer CPUs aktualisiert werden muss, deswegen "schnüffelt" / "snoopt" man die alle an. Wenn man ne Tabelle hat, welcher Chip was von wo gechacht hat, kann man sich ne Menge der Schnüffeleien sparen, da man die Daten gezielt updaten kann.

In nem 2P System gibts nur eine Möglichkeit, wo die Daten sein können ... deswegen braucht man da keinen Snoop Filter. Eben erst darüber, ab 3P wirds wichtig.

Die Cores in einem Chip kommunizieren über den L3, die brauchen keinen Snoop Filter, das stimmt.

ciao

Alex

P.S Der L3 von AMD ist nicht total exklusiv, der kann auch mal inklusiv sein ;)

[mboeller]

also S940;

scheint so als ob du recht hattest. Der Snoop-Filter arbeitet auch im Magny Cours und die CPUs takten ca. 25% geringer:

http://www.semiaccurate.com/2009/08/24/amd-outs-socket-g34/

[reunion]

AMD’s Bulldozer Processors to Feature Simultaneous Multi-Threading Technology:

Advanced Micro Devices announced during Hot Chips conference that its next-generation code-named Bulldozer microprocessors will feature simultaneous multi-threading technology (SMT) akin to Intel Corp.’s HyperThreading.

AMD did not reveal many details about its SMT capability and only said that its Bulldozer processors would support it in 2011. Still, it is rather likely that AMD’s approach may be somewhat different compared to Intel’s HT and may even be of the same kind like Sun Microsystems’ simultaneous multi-threading feature than supports execution of four threads on one physical core.

http://www.xbitlabs.com/news/cpu/display/20090825073221_AMD_s_Bulldozer_Processors_to_Feature_Simultaneous_Multi_Threadin g_Technology.html

Also doch SMT für Bulldozer, sehr schön.

[Gast]

Also doch SMT für Bulldozer, sehr schön.
Glaub ich nicht, dazu waren die Aussagen von JF zu deutlich. Da hat wohl nur jemand CMT falsch verstanden.

[S940]

Wie zu erwarten war:
The next big turn of the screw for AMD will involve plugging its next-generation Bulldozer core into a Magny-Cours design. The new core expands what has been the single-threaded nature of the AMD cores "in a different fashion than Hyperthreading," said Conway, referring to Intel's method for supporting two threads on a core.
http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=219400955&pgno=2

Edit: xbitlabs hats mittlerweile auch mitbekommen:
UPDATE: AMD has contacted X-bit labs claiming that it has not announced any simultaneous multi-threading technologies for Bulldozer processors. Still, there are other multi-threading implementations that may still be supported.
http://www.xbitlabs.com/news/cpu/display/20090825073221_AMD_s_Bulldozer_Processors_to_Feature_Simultaneous_Multi_Threadin g_Technology.html

[Knuddelbearli]

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

[AnarchX]

3GHz 16-Core-Bulldozer @ wprime? (http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=136778)

http://img14.imageshack.us/img14/9111/obero.png

Der Leaker @ OCW hat dort seinen Screenshot wieder entfernt...

[Knuddelbearli]

16 core ? 117 threads ok aber 16 cores ?

unglaubwürdig ( wobei ich jetzt nit weiss wie MCPU Platformen in CPUZ aufscheinen aber glaube kaum das er mehr als 1 Bulldozer haben wird wenn überhaupt ^^ )

[robbitop]

Ich glaube nicht, dass Bulldozer schon so weit ist, dass er wprime ausführen kann und schon gar nicht in 3 GHz. Es ist nichteinmal klar, ob bereits mehr als eine Simulation @Verilog vorhanden ist. Vieleicht gibt es ja Vorseriensamples, wie beim K8, die damals noch auf dem alten 130 nm Prozess mit Bulk und ohne LowK mit 800 MHz liefen. Es ist ja noch > 1 Jahr bis zur Auslieferung.

[Chrisch]

Ist OCW nicht bekannst für gefakte screens die da hin und wieder mal auftauchen? Hab zumindest schon öfter davon gelesen.....

[Gast HITCHER]

schaut aus wie zwei 8-Kern DIEs auf einem Träger mit jeweils 12MB L3 Cache,
oder könnte der auch monolithisch sein?

[Chrisch]

Der Screenshot ist nen Fake...

erstens stimmen die Abstände der Zahlen nicht (bei den 28MB L3) und zweitens hat Franck von CPU-Z gesagt das CPU-Z die 32nm CPUs von AMD noch nicht erkennen kann und folglich zeigts auch keine 32nm an ;)

http://www.abload.de/img/fake111ls2a.png

[HOT]

Zudem glaube ich nicht, dass man die Cache-Hierarchie so ausdrücken kann :D. Definitiv Fake. Das wären nämlich wohl eher 16x 64kB L1-D und 8x xxxkB L1-I und 8x 1MB L2 (wenn die Zahlen so zutreffen, was ich mal dahingestellt lasse :D), da die BD-Kerne keine wirklichen Kerne sind, sondern Cluster. Purer Mumpitz also.

[Coda]

128k L1 halte ich auch für Quatsch. Das würde viel zu hohe Latenzen nach sich ziehen.

[w0mbat]

http://img5.imagebanana.com/img/gv7ybz07/Capture.PNG

So, was sagt und das jetzt?

[Der_Korken]

"Two tightly linked cores share ressources to increase efficiency"

Irgendwie muss ich dabei an das Gerücht denken, dass AMD quasi ein "reverse-SMT" implementiert, mit dem 2 Kerne an einem Thread arbeiten können. In Anwendungen, die nicht alle Kerne benutzen wäre das natürlich genial. Ansonsten sagt mir dieses Schema gar nichts, da habe ich keine Ahnung von :tongue:.

[Botcruscher]

Vom Diagramm her geht es eher in die Richtung von Intel.

[BlackBirdSR]

Da muss ich spontan an den originalen K9/10 denken.
8-9 issue und "L0"-Caches direkt vor den Ausführungsclustern.

Allerdings wurde das Projekt IMO aus gutem Grund fallen gelassen. Man erreicht nicht eben mal eine anhaltende Single-Thread-Issue Rate von über 2µOps.

Das aktuelle Bild macht im Zusammenhang mit SMT allerdings schon mehr Sinn. Integer und Load/Store belegen den überwältigenden Teil des üblicherweise anfallenden Arbeitsaufwands. Die etwas länger laufenden FP/SIMD-Anweisungen kommen relativ selten zum Einsatz und sind dafür eher vorhersehbar.

Ergo 2-Way SMT pro Core mit höherem relativen Leistungsplus als bisheriges SMT bei Intel. Dazu AMDs SSE5 mit FMAC. L1-D-Caches so klein wie möglich. Dann bleibt noch der ganze Rest der CPU, der über die eigentliche Performance entscheidet. Davon wissen wir gar nichts.

IMO eine! logische Evolution von Multithreading.

[Botcruscher]

Die "Nebenwirkungen" für single-Thread-Anwendungen sind ja bei Intel gut zu sehen (auch wenn es nur bedingt vergleichbar ist). Imo bleibt da eben die Frage wie man die Last auf die Kerne verteilt.

[BlackBirdSR]

Die "Nebenwirkungen" für single-Thread-Anwendungen sind ja bei Intel gut zu sehen (auch wenn es nur bedingt vergleichbar ist). Imo bleibt da eben die Frage wie man die Last auf die Kerne verteilt.

Das hat in diesem Fall wenig damit zu tun. Wenn 2 Threads plötzlich auf einem physikalischen Kern landen, wenn wo anders noch ein Kern frei wäre, ist klar was passiert.

Hier wird die Last, auf den ersten Blick ohne Infos, nicht dynamisch verteilt, sondern es geht einfach je ein Thread an einen Int-Cluster. Das kann abwechselnd geschehen, wie es auch bei Intel der Fall ist. Das Front-End arbeitet dann im x,y,x,y,x,y-Takt, während die Ex-Cluster parallel laufen. Bei Anforderungen an die FP-Einheiten wird dann eben gewartet. Das ist halb so wild.

[StefanV]

Naja, ich würd eher sagen, das man 2 'ALUs' an einen Decoder hängt, also man macht hier einen Schritt Richtung GPU (gut, da gibts keinen Decoder aber einen Thread Dispatcher)...

[Coda]

Was ist da jetzt der Unterschied zu SMT mit mehr Ausführungseinheiten als bei Intel?

NVIDIA macht bei Fermi übrigens (ganz grob) eine ähnliche Sache indem es zwei Cluster zusammenfasst, bestimmte Teile aber nicht verdoppelt.

[StefanV]

Was ist da jetzt der Unterschied zu SMT mit mehr Ausführungseinheiten als bei Intel?
Bei Intel werden mehrere Kerne vorgetäuscht um so Lücken in der Pipeline zu füllen (bzw unbenutzte Einheiten zu benutzen), hier hat man mehrere Ausführungseinheiten, also quasi 2 Cores am selben Frontend.

NVIDIA macht bei Fermi übrigens (ganz grob) eine ähnliche Sache indem es zwei Cluster zusammenfasst, bestimmte Teile aber nicht verdoppelt.Ich würd hier mal vermuten, das das eine ganz andere Baustelle ist und was ganz anderes.

[S940]

Was ist da jetzt der Unterschied zu SMT mit mehr Ausführungseinheiten als bei Intel?
Jeder Thread hat garantierte Resourcen -> Behinderungen sind geringer. SMT kostet single-thread Performance, CMT nicht. Mal ein willkürliches Boinc Beispiel.

Ausserdem vereinfacht sich das Pipline Design bei 2+2, statt 1x4. Dadurch kann man höher takten. Wurde zumindest irgendwo früher mal erwähnt, ich glaub das stand in einem Forschungspapier, das Dresdenboy ausgegraben hatte.

@BlackBirdSR:
Da steht nur was von 8 piplines ... mMn wird das nicht 8issue sondern 4issue und die übrigen 4 piplines sind gewöhnliche AGUs ;-)

ciao

Alex

[Undertaker]

SMT kostet single-thread Performance

Unter Windows 7 kein bisschen.

Die Frage ist ja auch das Kosten-Nutzen Verhältnis, bei HT zu Pentium 4 Zeiten sprach Intel von 1-2% zusätzlicher Transistoren - das ist praktisch konkurrenzlos günstig. Wie sieht das bei CMT aus?

[Coda]

Bei Intel werden mehrere Kerne vorgetäuscht um so Lücken in der Pipeline zu füllen (bzw unbenutzte Einheiten zu benutzen), hier hat man mehrere Ausführungseinheiten, also quasi 2 Cores am selben Frontend.
Das ist trotzdem im Prinzip das gleiche, außer dass man bestimmte Funktionseinheiten verdoppelt hat um zu garantieren, dass diese auch verfügbar sind. Die geteilte FPU wird dadurch schließlich auch besser ausgenutzt als nur mit einem Thread.

Suns Niagrara hatte auch schon mal die FPU geteilt für alle Integer-Cores. Das ist weit weniger revolutionär als du wahrscheinlich denkst.

Ich würd hier mal vermuten, das das eine ganz andere Baustelle ist und was ganz anderes.
Payne. Es ging um die Struktur des Cores und die Idee dahinter. Und nein, das ist nicht "eine ganz andere Baustelle". Es geht in beiden Fällen darum Transistoren zu sparen indem man gewisse Teile von zwei Pipelines zusammenlegt und damit im Endeffekt mehr Performance/Transistor rauszuquetschen.

Außerdem sagt das noch lange nichts über die Single-Threaded-Performance aus. Wenn sie da nicht mit Intel aufschließen kann das ganze Konzept noch so schlüssig sein.

[S940]

Grobes Fazit:
A single Bulldozer core will appear to the OS as two cores, just like a Hyper Threaded Core i7. The difference is that AMD is duplicating more hardware in enabling per-core multithreading. The integer resources are all doubled, including the schedulers and d-caches. It’s only the FP resources that are shared between the threads. The benefit is you get much better multithreaded integer performance, the downside is a larger core.
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3674

[Coda]

Sag ich doch ;)

[S940]

Sag ich doch ;)

Genau.

Mittlerweile ist auch klar, dass die angekündigten 8 Kerne aus 4 Bulldozer "Modulen" besteht.

Auf Deutsch, ein Bulldozer wird "nur" 8 Threads verarbeiten können:
http://www.planet3dnow.de/photoplog/file.php?n=8211&w=o

Hatte damit aber eh schon gerechnet, die Performance Estimates waren für echte 8 Kerne / 16 Threads zu schlecht.

ciao

Alex

[reunion]

Genau.

Mittlerweile ist auch klar, dass die angekündigten 8 Kerne aus 4 Bulldozer "Modulen" besteht.

Auf Deutsch, ein Bulldozer wird "nur" 8 Threads verarbeiten können:
http://www.planet3dnow.de/photoplog/file.php?n=8211&w=o

Hatte damit aber eh schon gerechnet, die Performance Estimates waren für echte 8 Kerne / 16 Threads zu schlecht.

ciao

Alex

Passt ja auch. Der Unterschied zu acht "echten" Cores scheint einzig und alleine zu sein das die FP-Einheiten geshared sind, welche man ohnehin relativ selten braucht. Die wichtigen int-Einheiten sind zweimal vorhanden. Dazu gibt es zumindest pro Modul auch geshareten L2-Cache. Der L3-Cache ist vermutlich über alle Module geshared. In High-End Servern gibt es eh wieder ein MCM aus zwei Bulldozer mit 16 Cores.

Das ist weit weniger revolutionär als du wahrscheinlich denkst.


Hat ja auch keiner behauptet das es besonders revolutionär ist.

[BlackBirdSR]

Also wie ich gesagt habe :biggrin: (stinkend auf die Schulter klopf)
Jetzt fehlen nur noch die wichtigen Details

[Coda]

Die FP-Pipelines sehen zumindest auf dem Schaubild orthogonal aus ist mir gerade aufgefallen. Evtl. sind die nochmal in Add/Mul unterteilt.

Nur 2 Float-Pipelines wäre sonst wohl ein Rückschritt gegenüber K10 und ggü. 4 Integer-Pipelines auch etwas wenig.

[reunion]

Aja, ein K10 hat ja AFAIK nur drei int-Pipelines, also hier auch ein Fortschritt und ein gleichziehen mit Intel.

[Coda]

Wer redet von den Integer-Pipelines?

[reunion]

Wer redet von den Integer-Pipelines?

Ich! Wo ist das Problem?

[Coda]

Dachte du hättest mich falsch verstanden.

Nehalem hat eigentlich nur zwei Integer-Pipelines, aber ich denke mal AMD rechnet da auch Load und Store dazu um auf 4 zu kommen.

[reunion]

Nein, aber da du die vier int-Pipelines erwähnt hattest ist es mir aufgefallen. Aber ich habe es wohl tatsächlich mit den Decoder verwechselt. Dort hatte Intel ab dem Core 2 IIRC vier und AMD nur drei.

[Coda]

Das ganze ist etwas komplexer. Bei AMD hägen die Floating-Point-Einheiten an andereren Ports, bei Nehalem an gemeinsam genutzten:

http://commons.wikimedia.org/w/thumb.php?f=AMD%20K10%20Arch.svg&width=600px
http://commons.wikimedia.org/w/thumb.php?f=Intel%20Nehalem%20arch.svg&width=600px

Was die reine Zahl an Ausführungseinheiten angeht sind K10 und Nehalem wohl relativ ähnlich. Ich zähle eine Address-Generation-Unit mehr bei Intel. Aber welche Ops jetzt welche Pipeline kann steht da auch nicht.

[S940]

Die FP-Pipelines sehen zumindest auf dem Schaubild orthogonal aus ist mir gerade aufgefallen. Evtl. sind die nochmal in Add/Mul unterteilt.

Nur 2 Float-Pipelines wäre sonst wohl ein Rückschritt gegenüber K10 und ggü. 4 Integer-Pipelines auch etwas wenig.
Naja .. da steht nur was von "fused multiply-accumulate" (FMAC), aber nichts von Pipelines ... AMD wollte einfach nur andeuten, dass man 2x128bit FMAC µOPs verarbeiten kann. Wie das genau gelöst wird, das weiss man offiziell erst einmal nicht. Aber inoffiziell kann man in Dresdenboys Patenten nachschauen ;)

ciao

Alex

[S940]

JF erklärt CMT vs. SMT:
No, think about it this way:

1 thread on 1 core = 100%
2 threads on 1 core (HT) = ~120% (of course, there are workloads where 2 threads on 1 core = <100% ;) )
2 threads on 2 cores (bulldozer) = 180%+

So if both HT and bulldozer = ~5% more die space, then it would seem that Bulldozer would be a far better choice. So, now, can everyone STOP saying that if AMD doesn't do HT that we are disadvantaged? http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137054#p170543
Klingt ja schon fast irgendwie zu gut ^^

ciao

Alex

[IVN]

JF erklärt CMT vs. SMT:
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137054#p170543
Klingt ja schon fast irgendwie zu gut ^^

ciao

Alex
Klingt für mich nach "word-of-mouth advertising".

[reunion]

Das ganze ist etwas komplexer. Bei AMD hägen die Floating-Point-Einheiten an andereren Ports, bei Nehalem an gemeinsam genutzten:


Aus dem Schaltbild werde ich nicht schlau. Ich weiß nur das Intel beim Core 2 intensiv mit ihren vier Decodern gewoben hat ggü. den dreien bei AMD und Intel vor Core 2. Darauf habe ich mich bezogen.

[S940]

Klingt für mich nach "word-of-mouth advertising".Im ersten Moment schon, im zweiten musst Du Dir überlegen, was sie großartiges gegenüber einem 1x4issue Kern verändern.

Da ist nicht viel ... und dass bei 2issue Kernen das beste Kosten/Nutzenverhältnis herrscht ist auch schon lange bekannt.

Die 3 oder gar 4issue Kerne sind/waren nur das Produkt der single-thread performance Ära, Leistung um jeden Preis .. jedes Promill mehr zählte.

Eigentlich eine gute Idee, die Kerne gleich auf 2issue zu begrenzen und auf das bisschen 3/4issue Vorteil zu pfeifen.

Dafür hat man dann bei 2 Threads die Nase deutlich vorne ;-)

ciao

Alex

[IVN]

Im ersten Moment schon, im zweiten musst Du Dir überlegen, was sie großartiges gegenüber einem 1x4issue Kern verändern.

Da ist nicht viel ... und dass bei 2issue Kernen das beste Kosten/Nutzenverhältnis herrscht ist auch schon lange bekannt.

Die 3 oder gar 4issue Kerne sind/waren nur das Produkt der single-thread performance Ära, Leistung um jeden Preis .. jedes Promill mehr zählte.

Eigentlich eine gute Idee, die Kerne gleich auf 2issue zu begrenzen und auf das bisschen 3/4issue Vorteil zu pfeifen.

Dafür hat man dann bei 2 Threads die Nase deutlich vorne ;-)

ciao

Alex
Ja, schon klar. Ich meinte die 180%+. Das ist, denke ich, einfach unrealistisch. Was passiert mit FP? Da gibt es 0 Speed-Bump...

[BlackBirdSR]

Im ersten Moment schon, im zweiten musst Du Dir überlegen, was sie großartiges gegenüber einem 1x4issue Kern verändern.

Da ist nicht viel ... und dass bei 2issue Kernen das beste Kosten/Nutzenverhältnis herrscht ist auch schon lange bekannt.

Die 3 oder gar 4issue Kerne sind/waren nur das Produkt der single-thread performance Ära, Leistung um jeden Preis .. jedes Promill mehr zählte.

Eigentlich eine gute Idee, die Kerne gleich auf 2issue zu begrenzen und auf das bisschen 3/4issue Vorteil zu pfeifen.

Dafür hat man dann bei 2 Threads die Nase deutlich vorne ;-)

ciao

Alex

Das wird sicher nicht auf 2-Issue begrenzt. Die Int.Cluster sind eindeutig nach dem Front-End, genau so wie die FP-Einheiten. Also muss das Frontend weiterhin relativ breit bleiben.

Wie gesagt: Verteilung der Threads abwechselnd mit jedem 2. Takt.

[S940]

Aus dem Schaltbild werde ich nicht schlau. Ich weiß nur das Intel beim Core 2 intensiv mit ihren vier Decodern gewoben hat ggü. den dreien bei AMD und Intel vor Core 2. Darauf habe ich mich bezogen.
Vielleicht eindeutiger hier:
One important difference between AMD and Intel’s microarchitectures is that AMD has their address generation units (AGUs) separate from the load store units (LSUs). This is because, as we noted earlier, AMD’s micro-ops can contain a load, an operation and a store, so there must be at least as many AGUs as ALUs. In contrast, Intel uops totally decouple calculations from memory accesses, so the AGUs are integrated into the load and store pipelines. The difference in the underlying uops and micro-ops result in the different AGU arrangements.
Another distinction between the Barcelona and Core microarchitectures is that AMD’s ALUs are symmetric and can execute almost any integer instruction, while the ALUs for Core 2 are not symmetric and are slightly more restrictive. Each of the lanes must be nearly identical for AMD’s distributed schedulers and instruction grouping to work optimally. This is a clear architectural trade-off of performance and decreased control complexity versus power and increased execution complexity. Replicating three full featured ALUs uses more die area and power, but provides higher performance for certain corner cases, and enables a simpler design for the ROB and schedulers.

http://www.realworldtech.com/page.cfm?ArticleID=RWT051607033728&p=6
(Im Notfall den ganzen Artikel durchlesen ;-))

@Blackbird:
Ja natürlich, ich meinte die Begrenzung 2issue per Core/Cluster, nicht per Modul ;-)
Das Front End ist natürlich 4issue breit, aber das müßte es bei einem 1x4issue ja auch sein, von daher erstmal der gleiche Aufwand.

@IVN:
Hmm ... wenn ein 256bit AVX Befehl des Weges kommt, und Thread 2 die FPU gerade nicht benötigt gibts da schon einen Vorteil ;)

ciao

Alex

[BlackBirdSR]

Sag nicht Modul sondern CPU.
AM Ende ist es immernoch eine CPU Marke: 1xFrontend 1x Backend, wobei das Backend unterteilt ist.

[S940]

Sag nicht Modul sondern CPU.
AM Ende ist es immernoch eine CPU Marke: 1xFrontend 1x Backend, wobei das Backend unterteilt ist.

Naja die CPU ist aber dann sowas wie Zambezi, das ist das komplette Stück Silizium inkl. mehreren Kernen/Cluster/Modulen und Northbridge verpackt in einem Gehäuse.

Auf irgendwas müssen wir uns einigen, nachdem AMD jetzt Module & Kerne benützt ... ist der Standard wohl gesetzt.

Ausser Du setzt als Mod andere 3DC Richtlinien durch, da halte ich mich auch gerne daran, mir egal :D

ciao

Alex

[reunion]

Die Erklärung von AnandTech bezüglich der gesharten FP-Einheiten macht natürlich auch Sinn:

Doubling the integer resources but not the FP resources works even better when you look at AMD’s whole motivation behind Fusion. Much heavy FP work is expected to be moved to the GPUanyway, there’s little sense in duplicating FP hardware on the Bulldozer core when it will eventually have a fully capable GPU sitting on the same piece of silicon. While the first incarnation of Bulldozer, the Zambezi CPU, won't have an on-die GPU, presumably future APUs will use the new core. In those designs the Bulldozer cores and the GPU will most likely even share the L3 cache. It’s really a very elegant design and the basis for what AMD, Intel and NVIDIA have been talking about for years now. The CPU will do what it does best while the GPU does what it is good at.

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3674

[Coda]

Was ein Quatsch. Nur weil etwas Floating-Point ist heißt es noch lange nicht dass es gut auf einer GPU läuft.

Aber anscheinend hat K10 ja auch nur zwei "echte" FP-Pipelines, von daher passt es.

[reunion]

Was ein Quatsch. Nur weil etwas Floating-Point ist heißt es noch lange nicht dass es gut auf einer GPU läuft.

Das sagt ja niemand. Die FP-Einheiten werden ja nicht gestrichen. Dennoch könnte man da sicherlich so mache Dinge auf die GPU auslagern.

[Gipsel]

Aber anscheinend hat K10 ja auch nur zwei "echte" FP-Pipelines, von daher passt es.
Die FMISC-Pipe ist schon ziemlich wichtig. Zum einen erlaubt sie Load/Store-Operationen während die "richtigen" Pipelines beschäftigt sind und zum anderen werden die langwierigen Operationen (Division, Wurzel, sin/cos usw.) zum großen Teil da abgewickelt ohne die MUL/ADD Pipelines zu blockieren.

Ich könnte mir übrigens sehr gut vorstellen, daß Bulldozer darauf verzichten wird und ähnlich wie Itanium oder auch GPUs Division und Wurzel mit Hilfe der beiden FMA-Pipelines iterativ berechnet.

Die FP-Kapazität von Bulldozer wird also pro Modul 4 double precision FMAs pro Takt, also 8 Flops betragen. Das ist jetzt nicht wirklich überragend. Vier Module (offiziell 8 Kerne) werden also von der Peakleistung auch nicht über einem MCM aus zwei Shanghais liegen. Allerdings dürfte in der Praxis die Auslastung doch meist deutlich höher liegen (+50% ?).

Eine Frage wäre noch, ob die FPU überhaupt an den L1 Caches hängt. Ich würde ja fast vermuten, daß die direkt an den L2 angebunden ist. Man würde Bandbreite und Ports am L1 sparen (käme wohl auch mit weniger L1 aus) bzw. kann die Latenzen sehr niedrig halten (für Integer wichtiger als FP).

Übrigens, wenn man sich mal anschaut, wie klein eigentlich die Integereinheiten sind, würde ich nicht ausschließen wollen, daß da zwei mal vier ALU/AGU-Paare verbaut werden, die gezeigten Pipelines also echte 4 Integer-Pipelines darstellen. Würde zwar meist nur geringe Vorteile bringen, aber das würde auch nur 5% Diefläche oder so kosten. Beim Bobcat-Kern (der aber erklärtermaßen für's Stromsparen und auf nur 90% heutiger Mainstreamleistung ausgelegt ist) sprechen die Folien dagegen ausdrücklich von nur 2 Integer-Pipelines und je einer Load- bzw. Store-Pipeline. Das ist zwar für das Stromsparen gut, würde aber doch etwas an Leistung verschenken.

[Gipsel]

Was passiert mit FP? Da gibt es 0 Speed-Bump...Da gibt es den gleichen wie mit Hyperthreading. Insbesondere bei latenzsensitivem FP-Code kann der sehr schnell mal +50% oder auch größer werden.

[mrt]

Was ein Quatsch. Nur weil etwas Floating-Point ist heißt es noch lange nicht dass es gut auf einer GPU läuft.

Aber anscheinend hat K10 ja auch nur zwei "echte" FP-Pipelines, von daher passt es.
Wieviele Fälle gibt es wo die FPU limitiert und man die Operationen nicht auf eine IEEE-754-konforme GPU machen kann? Wohl eher nich so oft als dass man da viele Transistoren verschwenden sollte ;)

[mboeller]

AnarchX hatte ja auf Seite 5 in diesem Thread die "Benchmark"-Folie für die neuen AMD-CPUs (Istanbul, Magny Cours, Interlagos) gepostet.

Wenn man jetzt mal den Istanbul mit 2,7GHz als Basis für die Performance-Erwartungen des Interlagos mit 16 Integer-"Kernen" und 8 FP-"Kernen" (=8 Bulldozer-Module) nimmt, und die Annahme trifft das die FP-Einheiten pro Takt nicht schneller sind als beim Istanbul, dann müsste der Interlagos mit ca. 4GHz an den Start gehen.

kann das so stimmen? 4GHz für eine 8-Module-Server-Variante sind imho ziemlich viel. Die 4-Module-Homeuser-Variante sollte dann doch fast schon mit 4,8-5GHz kommen. Das wäre dann ein riesiger Sprung zum Phenom-II.

Grundlage für die Überlegung:
Integer: 45/13,75-fache Performance laut Slide + 8/6 Module + 1,8-fache Integer-Multithreading-Leistung pro Modul beim Interlagos + geringfügig schlechtere Single-Threading-Leistung pro Modul beim Interlagos (-5 bis -10%, da es anscheinend ja nur 2 statt 3 Pipelines pro halbem Modul gibt) => ~ 4GHz / 2,7GHz

FP: 36/17,5-fache Leistung + 8/6 Module => ~4GHz / 2,7GHz


Was mir gerade auffällt: wo steht eigentlich der 3DCenter-Server? Da herrscht ja immer noch die Sommerzeit. :)

[S940]

und die Annahme trifft das die FP-Einheiten pro Takt nicht schneller sind als beim Istanbul
Die Annahme ist nur leider falsch, ich glaube bei früheren Folien stand was von ~30% Mehrleistung aufgrund der FMA Befehle, für Integer wird es die vermutlich auch geben (Als XOP), von daher bringt die ganze Rechnerei nichts. Was Du auch wieder vergißt ist der DDR2<> DDR3 Unterschied.

Im übrigen gabs am 11ten eine neue Version der Performancefolie, da steht bei Istanbul auch dabei welcher Typ (also Taktfrequenz gemeint ist):
http://www.planet3dnow.de/photoplog/file.php?n=8090&w=o
2435 -> 2,6 GHz.

Magny Cours wurde im übrigen anscheinend etwas nach oben verschoben, anstatt ~26 SPECrates gibts jetzt 28/29 ;-)

ciao

Alex

[mboeller]

Die Annahme ist nur leider falsch, ich glaube bei früheren Folien stand was von ~30% Mehrleistung aufgrund der FMA Befehle, für Integer wird es die vermutlich auch geben (Als XOP), von daher bringt die ganze Rechnerei nichts. Was Du auch wieder vergißt ist der DDR2<> DDR3 Unterschied.

Alex

Danke,

ich dachte mir schon das meine einfach "Rechnung" nicht richtig ist. Ich wollte nur sichergehen. Ist dir auch aufgefallen, das Interlagos jetzt bei Integer um ca. 5 Punkte von ~45 auf ~40 gefallen ist. Es scheint so als ob AMD entweder die Taktziele nicht erreichen kann (das sollten sie aber noch nicht wissen) oder aber ihre Integer-Pipeline mal wieder nicht die Leistung erreicht die sie erwartet haben. Schade!

Die neuen PDF's lade ich mir mal runter. Mal sehen was noch so alles drin steht.

grüsse

Manfred

[Coda]

Für Server ist es natürlich auch eine sehr gute Idee die Integer-Performance deutlich mehr zu skalieren als Float.

Wieviele Fälle gibt es wo die FPU limitiert und man die Operationen nicht auf eine IEEE-754-konforme GPU machen kann? Wohl eher nich so oft als dass man da viele Transistoren verschwenden sollte ;)
Das Problem ist doch viel mehr, dass GPGPU wahrscheinlich immer ein erheblicher Aufwand darstellen wird. Vor allem ohne IDE. Nur darauf zu setzen halte ich schon für mutig.

Aber du hast schon recht. Vieles was FP ist, ist auch ziemlich parallel.

[w0mbat]

@mboeller: Das sind keine Angaben zur Performace sondern eine graphische Darstellung dass diese CPU schneller wird. Aus diesen Folien kann man rein gar nichts über den BD raus lesen. Dass sich die Angaben ständig verändern liegt daran, dass es keine Angaben sind sondern einfach ein Hinweis dass BD > K10.

Bei der obigen Folie wurden die Balken so angepasst, dass der Pfeil noch Platz hat. Wenn das anderes gelöst worden wäre, könnte bei BD auch 50/60 stehen oder der gleichen.

Ich finde es ja wirklich nett was ihr alles daraus lesen wollt, aber das geht eben nicht.

[mboeller]

Ich glaube schon, das man die relative Performance ganz gut aus den Charts rauslesen kann. Beim Magny Cours funktioniert es jedenfalls gut. Der wird Ende Januar/Anfang Februar anscheinend jetzt mit 2,33GHz starten. das ist ein wenig schneller als bisher gedacht (sagt zumindest dieses neue Chart. ;) )

Eine kurze google suche nach FMA brachte folgende Resultate:

http://software.intel.com/en-us/forums/intel-avx-and-cpu-instructions/topic/61121/


In graphics and multimedia code the occurence of a multiply followed by an addition is so common that effective performance increases of over 50% are no exception.


50% schneller bei Multimedia FP-Code ist nicht ohne. Und Sandy Bridge hat kein FMA...

www.hpcx.ac.uk/research/hpc/technical_reports/HPCxTR0703.pdf [Seite 10ff, da wird es interessant was FMA angeht ]

[w0mbat]

@mboeller: Klar, bis zum MC geht das wunderbar, da sind die Balken ja auch abgeschlossen. Beim BD aber nicht und das soll nicht andeuten dass der Balken nur ungefähr ist, sondern dass er eben schneller ist, aber man nicht nicht sagen kann/will wie weit.

[Coda]

FMA muss auch erstmal verwendung finden, bevor da irgendwelche Performanceverbesserungen sichtbar werden.

[S940]

FMA muss auch erstmal verwendung finden, bevor da irgendwelche Performanceverbesserungen sichtbar werden.
Hmm ... wie wärs mit nem "µOP FMA Fusion" im Dekoder ?
Sollte doch eigentlich relativ einfach hinhauen, oder siehst Du da größere Probleme ?

[Coda]

Bei x87-Code wird das sehr schwierig zu erkennen sein. Bei Scalar/Vector-SSE schon eher, aber ob sich das lohnt weiß ich nicht.

[S940]

Stimmt auch wieder .. Kosten / Nutzen ist wichtig. Bei Graphiccode mags interessant sein, aber beim restlichen Code ... hmm schwer zu sagen.

Naja vielleicht was für nen späteren Bulldozer Fusion ^^

ciao

Alex

[Tarkin]

Anandtech: AMD Core Counts and Bulldozer: Preparing for an APU World (http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3683)

[HOT]

Die Folie ist so designt, dass Magny-Cours möglichst gut aussieht, immerhin ist das ja das nächste kaufbare Produkt. Die BD-Balken sind deshalb ausgegraut, weil a.) die Performance noch nicht messbar ist, b.) man mit diesen Daten noch nicht rausrücken möchte.
Die einzige Info, die daraus hervorgeht, ist, dass die FP-Leistung stärker zunimmt als die Int-Leistung, was angesichts FMA auch kein Wunder ist.
Wie es im Moment aussieht, ist eine BD-Modulhälfte schon heftiger als ein K10-Kern, was Int angeht. Mehr werden wir aber wohl erst Ende 2010 erfahren. AMD wird vor Magny-Cours wohl kaum mit irgendwelchen BD Leistungszahlen rausrücken.

[Coda]

FMA gibt's doch erst in Bulldozer dachte ich?

[sklave_gottes]

FMA gibt's doch erst in Bulldozer dachte ich?

Genau das sagt HOT doch.

mfg martin

[AnarchX]

AMD has come back to us with a clarification: the 5% figure was incorrect. AMD is now stating that the additional core in Bulldozer requires approximately an additional 50% die area. That's less than a complete doubling of die size for two cores, but still much more than something like Hyper Threading.
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3683

Damit liegt ein BD-Modul wohl dann etwa auf dem Niveau eines Nehalem-Kerns.

[Tarkin]

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3683

Damit liegt ein BD-Modul wohl dann etwa auf dem Niveau eines Nehalem-Kerns.

du meinst von der Die-Größe, oder? (wäre der Nehalem auch 32nm schätze ich mal)

Leistungsmässig dürfte man wohl darüber liegen, nicht?

Ich hab hier noch keine Einschätzung bzgl. Leistung gehört.. würde mich interessieren was die Techniker und Ingenieure vom Bulldozer-Design halten :)

[BlackBirdSR]

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3683

Damit liegt ein BD-Modul wohl dann etwa auf dem Niveau eines Nehalem-Kerns.

Alles andere wäre auch völlig unrealisitisch gewesen. Alleine der Bedarf an Registern und Ports würde das schon sprengen.

[StefanV]

Dresdenboy (http://citavia.blog.de/2009/12/01/256-bit-integer-xop-avx-compatible-execution-7490564/) hat was zu den 4 ALUs spekuliert, die eventuell auch AVX ausführen könnten.

[Limit]

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3683

Damit liegt ein BD-Modul wohl dann etwa auf dem Niveau eines Nehalem-Kerns.

I am trying to find out how this update happened. This is not right.

http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137095&st=0&sk=t&sd=a&start=100#p172691

Dort dementiert AMD (JF) die Aussage von Anandtech.

[CrazyIvan]

http://groups.google.com/group/comp.arch/browse_thread/thread/759bcccbfa0b8b07/3cd3bfa93b736a56?q=#3cd3bfa93b736a56
Keine Ahnung wie ich darauf gestoßen bin und ob ich auch nur 20% dessen, was dort geschrieben steht, verstehe. Aber wenn der Mensch nur die Hälfte von dem ist, was er zu sein vorgibt, dann ist es vor allem für die Gurus unter uns hochgradig lesenswert ;)

[w0mbat]

Ist schon lange bekannt :)

[Gast]

doch keine 50%:


Our engineers estimate that the amount of discrete circuitry that is added to each Bulldozer module in order to allow for a second integer thread to run only adds ~12% additional circuitry to each module, which translates into only ~5% of circuitry to the total Bulldozer die.

Link: http://blogs.amd.com/work/2009/12/11/aiming-for-the-sweet-spot-in-2010-and-beyond/

Gefunden habe ich den Link natürlich beim Dresdenboy, wo sonst. :)

[Coda]

Nur 12%? Da bin ich mal auf Die-Shots gespannt.

[Tarkin]

http://www.xbitlabs.com/news/cpu/display/20091217115203_AMD_to_Start_Production_of_First_Bulldozer_Processors_in_1H_2011_ Sources.html

"According to a source familiar with AMD’s server plans, the chipmaker plans to commence mass production of certain versions of its code-named Interlagos microprocessors with 12 or 16 cores already in the first half of 2011. Other versions of the chips, e.g. with reduced power consumption or increased performance, will still be produced in the second half of the year."

Sieht aus als wäre man voll im Zeitplan... Kommen die Desktop CPUs mit 8 "Kernen" bzw 4 Bulldozer "Modulen" womöglich Ende 2010, Anfang 2011?

[AnarchX]

Wenn es wieder nach dem Schema "erst Opteron, später Phenom" abläuft, wird man bei einem Produktionsstart Anfang 2011 wohl "Phenom" erst im Q2 2011 sehen.
Was wohl auch der Grund sein dürfte, warum 2010 noch Thuban antritt.

[reunion]

Wobei Interlagos die MCM-Variente ist die üblicherweise später kommt.

[AnarchX]

Wobei Interlagos die MCM-Variente ist die üblicherweise später kommt.
MCM wird wohl in Zukunft weit wichtiger werden für AMD:
http://www.computerbase.de/bildstrecke/27452/15/

[StefanV]

Naja, schauen wir mal, wie die Preise sind und die Verteilung...

Obs wirklich wichtiger wird, werden wir sehen...

[AnarchX]

Obs wirklich wichtiger wird, werden wir sehen...
Die Roadmap sagt doch eindeutig aus, dass man das Mainstream-Server-Segment, wo man heute noch Single-Die-Opterons verkauft, ab 2010 mit MCMs besetzt.
Das passt eben auch zur Aussage von XBL, dass Interlagos AMDs erstes Bulldozer-Produkt ist.

[StefanV]

Das sehe ich nicht so.

Ich würd eher sagen, dass man da die MCM Chips auch sieht, aber nicht ausschließlich.

Hier müssen wir ersteinmal abwarten, wie die Preise werden.

[Gast]

Ich denke eher das MCM eine Nische für "dicke" Server wird AMD hat selbst auf Folien mal angegeben das sie den Markt im 1 und 2 CPU Systemen sieht MCM ist für 2 und 4 gedacht da die Strategie ja auch bei den CPU´s Mainstream ist sollte das eher selten sein aber vielleicht versteh ich auch gerade was falsch.

[AnarchX]

Wie es dann real sich entwickeln wird, ist natürlich noch Zukunft.
Aber den Fakt, dass hier AMD in dieser Roadmap die MCM-Plattformen eindeutig als Mainstream bezeichnet, sagt doch schon etwas darüber aus, was AMDs Stragtegie momentan ist.

Und wenn man in 2010 blickt, dann braucht es schon MCMs um sich gegen die Westmere-Xeon mit 6C/12T@ bis zu 3.33GHz zu behaupten.

Aber eigentlich ging es ja darum, die Aussage von XBL zu prüfen, ob Interlagos die erste Bulldozer-CPU sein könnte. Und das könnte der Fall sein, wenn AMD wie bisher wieder Mainstream-Opterons zuerst launcht.

[reunion]

Und wenn man in 2010 blickt, dann braucht es schon MCMs um sich gegen die Westmere-Xeon mit 6C/12T@ bis zu 3.33GHz zu behaupten.


Anfang 2010 kommt eh Magny-Cours, der allerdings auf Instanbul basiert, den es dann schon 9 Monate geben wird.

Aber eigentlich ging es ja darum, die Aussage von XBL zu prüfen, ob Interlagos die erste Bulldozer-CPU sein könnte. Und das könnte der Fall sein, wenn AMD wie bisher wieder Mainstream-Opterons zuerst launcht.

Der Punkt ist das ein MCM immer zusätzliche Tests erfordert, ev. auch eine Selektion von Chips die mit weniger Spannung laufen, etc. Dh der "Singel-Die" muss früher zur Verfügung stehen, denn ohne das zumindest ein Die läuft braucht man an ein MCM gar nicht zu denken.

[AnarchX]

Anfang 2010 kommt eh Magny-Cours, der allerdings auf Instanbul basiert, den es dann schon 9 Monate geben wird.
Und Interlagos kann auf die bewährte Infrastruktur von Magny-Cours zurückgreifen.


Der Punkt ist das ein MCM immer zusätzliche Tests erfordert, ev. auch eine Selektion von Chips die mit weniger Spannung laufen, etc. Dh der "Singel-Die" muss früher zur Verfügung stehen, denn ohne das zumindest ein Die läuft braucht man an ein MCM gar nicht zu denken.
Wie schon gesagt mit Magny-Cours schafft man die Basis, auf die Interlagos aufsetzen wird. Und wenn man sich die Taktraten der kommenden MCMs anschaut, ist hier wohl keine besonders große Selektion nötig.
Und dass man Bulldozer-Dies erst einzeln testet steht hier nicht zur Debatte, sondern in welcher Form man sie zuerst auf den Markt liefern wird.
Und da sprechen XBLs Quellen von MCM und auch die bisherige Strategie und die aktuelle Server-Roadmap von AMD untermauern diese Spekulation.

[reunion]

Und Interlagos kann auf die bewährte Infrastruktur von Magny-Cours zurückgreifen.

Das ist natürlich richtig, macht aber meinen zweiten Quote nicht obsolet. :)

[Undertaker]

Übrigens gab es gleichen Fall auch schon in der Vergangenheit. ;) Der 45nm Wolfdale wurde zuerst als MCM in Form des QX9650 verkauft, bevor Monate später die einzelnen Chips auf den E8000 Dualcores folgten. Und das, obwohl die Fertigung Berichten nach Anfangs überhaupt nicht gut lief und für den QX9650 sehr gute Dies gebraucht wurden...

Natürlich ist dieser Fall in einigen Punkten nicht wirklich vergleichbar, dass grundlegend aber zuerst das MCM-Modell kommen könnte, wäre durchaus denkbar.

[reunion]

Wie schon gesagt mit Magny-Cours schafft man die Basis, auf die Interlagos aufsetzen wird. Und wenn man sich die Taktraten der kommenden MCMs anschaut, ist hier wohl keine besonders große Selektion nötig.
Und dass man Bulldozer-Dies erst einzeln testet steht hier nicht zur Debatte, sondern in welcher Form man sie zuerst auf den Markt liefern wird.
Und da sprechen XBLs Quellen von MCM und auch die bisherige Strategie und die aktuelle Server-Roadmap von AMD untermauern diese Spekulation.

Ja, das ist schon klar, warten wir ab. Wenn dann ist das aber IMHO eher eine politische Entscheidung, denn der Single-Die kommt aus Prinzip vor dem MCM, der ja darauf aufbaut. Selbst wenn man auf der Plattform von Magny-Cours aufbauen kann so ist Bulldozer doch eine völlig neue Architektur mit der man erst mal entsprechende Erfahrungen machen muss. Und da ist ein MCM mit Sicherheit eine zusätzliche Problematik zum Singel-Die.

[aylano]

Der Punkt ist das ein MCM immer zusätzliche Tests erfordert, ev. auch eine Selektion von Chips die mit weniger Spannung laufen, etc. Dh der "Singel-Die" muss früher zur Verfügung stehen, denn ohne das zumindest ein Die läuft braucht man an ein MCM gar nicht zu denken.
Muss nicht sein.
Das ist eine Frage der im voraus zu verfügungstehenden Zeit.
Und Bulldozer hat deutlich mehr Zeit zum Reifen als frühere Architektur-Einführungen.
Und MCM-Erfahrungen macht AMD ja dann mit Magny-Cours

Dass Interlagos früher kommt als die Single-Version, kann sehr gut Möglich sein, denn dann könnte AMD mit der gleichzeitigen Bulldozer-Einführung und eventuellen "überhohlen von Intel" mit Imterlagos Marketing/Image-mäßig per Paukenschlag viel bewirken.

[Gast]

Es gibt neue Infos. Auch wenn die sechsfache Leistung sicher nur ein ausgewählter Benchmark war, die TDP von unter 45W klingt vielversprechend.

ich kenn die (aktuelle) leistung, weil ich gerade bei amd in indien bin (jetzt ueber silvester nicht direkt bei amd, hab gerade ferien). und dank meiner begeisterung fuer BD hatte ich die chance mal ein laufendes system zu begutachten d.h. ich durfte daneben sitzen und er hat mir ein paar sachen erklaert.

viele dinge kann man zb noch gar nicht starten damit es keine vorab-leaks geben kann. wenn du zb futuremark oder einen aehnlichen bench starten willst kommt nur einen fehlermeldung, jeder test muss vorher "angemeldet" werden.

das system bestand aus einem am3 board (mir unbekannt, stand amd drauf), 1gb ram (ka wieso so wenig), einer hdd und der cpu mit einem boxed kuehler. sah aus wie so ein aufbau fuer eine oc session auf einer messe.

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.

http://www.planet3dnow.de/vbulletin/showthread.php?p=4109035#post4109035

[Coda]

"mehr als 7 mal so schnell". Was soll das denn bitte für ein Test sein?

Selbst bei reinem Integer ist das mehr als suspekt.

[StefanV]

Naja, kann schon angehen, die Frage ist nur, was das für ein Test war und was getestet wurde...


Im Schnitt ists natürlich bei weitem nicht so viel.

[Psychopat]

Liest man in dem Thread weiter wird spekuliert das es sich bei dem Speedup um die Vorteile der neuen Instruktionen handelt (AVX). In einem Speziell darauf ausgelegtem Benchmark sind das doch normale Größenordnungen. So ein Test sagt aber leider wenig über die generelle Leistungsfähigkeit des Bulldozer.

[AnarchX]

Vielleicht auch HW-beschleunigtes AES wie bei Intels Westmere und VIAs CPUs.

[Coda]

Liest man in dem Thread weiter wird spekuliert das es sich bei dem Speedup um die Vorteile der neuen Instruktionen handelt (AVX).
Gut, das mag sein.

[Gast]

"mehr als 7 mal so schnell". Was soll das denn bitte für ein Test sein?

Selbst bei reinem Integer ist das mehr als suspekt.


Hat Bulldozer nicht 8 Kerne? Also 4 gegen 8 Kerne? Nunja, so ein Wert in einem Forum ohne nähere Angaben ist schlicht nichtssagend.

Warum sollte seine story überhaupt stimmen? Ist denn wombat ein Insider? Oder ist er glaubwürdig?

[Coda]

Doch er hat 8 Kerne, aber dann ist das immer noch ein Faktor 3,5 pro "Kern"

[StefanV]

Das mit den Kernen ist beim Bulldozer nicht mehr so einfach...

Was sind Kerne?
Frontends (also Decoder) oder Ausführungseinheiten oder gar beides zusammen??

[Coda]

Das mit den Kernen ist beim Bulldozer nicht mehr so einfach...
Natürlich ist das einfach. Das einzige was geteilt wird ist die FPU.

[SavageX]

Doch er hat 8 Kerne, aber dann ist das immer noch ein Faktor 3,5 pro "Kern"

Würde mich nicht wundern, wenn es Code gäbe, der dem K8/K10 so wenig liegt, dass er nur eine Instruktion pro Takt fertigstellen kann, den Bulldozer aber ungebremest 4-fach superskalar abfrühstücken kann.

Wenn das geht, ist das natürlich seeeeeeehr synthetisch.