Ausblick auf Bulldozer-Nachfolger: Vishera, Steamroller, Excavator

[S940]

Caches sind aber NICHT nur dafür da die Latenz zu senken, sondern auch um die datenlikalität aus zu nutzen, um damit die Bandbreite zu steigern und sogar noch Strom zu sparen, da man kürzere signalwege hat und nixht offchip muss.
Bandbreite ist auch richtig, aber Stromsparen? Bist Du Dir da sicher? Transistoren kosten Strom, die im Cache zwar nicht viel, aber sie brauchen auch was. Da stell ich mir ne Speicheranfrage an DDR3 stromgünstiger vor.
Der eine Thread muss natürlich länger warten und tut nichts in der Zeit, aber genau dafür laufen schließlich ein paar 100 Threads quasi-parallel auf ner GPU.
Siehe oben, ein Cache hilft auch einer igpu. Insbesondere wenn die Datenzugriffe etwas irregulärer werden hilft ein Cache extrem. Die igpu bricht dann einfach nicht so schnell ein wie ohne Cache. Und das ist wirklich ein Problem von gpus! Sie erfordern einen hohen datenrese auf recht kleinen Datensätzen. Deswegen sind gpus auch schwieriger effiziente zu programmieren, vor allem weil man ja auch noch schneller sein muss als einfach mit der CPU. Caches sind daher sehr schön, weil man damit das Problem des leistungseinbruchs reduzieren kann, was wiederum dazu führt, dass man die igpu für mehr Aufgaben sinnvoll einsetzen kann.Ist das wirklich die Schwierigkeit von GPUs? Dachte bisher, dass das größte Problem ist die hohe Parallelität auszunutzen. Alle Probleme lassen sich einfach nicht in mehrere Threads zerlegen.

Caches wären sicherlich auch für ne GPU sinnvoll, aber aufgrund der vielen Threads schauts dort mit der Datenlokalität doch ziemlich sch..lecht aus.

Aktuell hat ein GCN-Chip pro Speicherkanal (ich nehm mal an sie meinen das im Sinne von Kanal = 64bit) 64-128kb L2. Eine 7970 hätte demnach unter der Maximalannahme mit 128kB, 756kB L2 Cache.
Bis man da die Datenlokalität pro Thread hat, die man aus CPU-Zeiten gewöhnt ist (1Thread = 1MB L2+1MB L3), bräuchte man ein paar 100 MB Cache.

Da schließe ich mich dann HOT an, in dem Fall müsste es dann stacked-RAM sein.

Das hatte ich ganz vergessen. Mit so nem Teil wär dann auch ne APU Desktop-tauglich (im Sinne von spieletauglich) und für Serverapps wärs sicherlich auch vorteilhaft. Die Bandbreite wäre wohl noch nen Tick langsamer, aber aktuell läuft der L3 auch schon mit nur mageren 2,2 GHz, da wäre nicht viel verloren.

Frag mich nur, was sowas kosten würde ...

[Gipsel]

Aktuell hat ein GCN-Chip pro Speicherkanal (ich nehm mal an sie meinen das im Sinne von Kanal = 64bit) 64-128kb L2. Eine 7970 hätte demnach unter der Maximalannahme mit 128kB, 756kB L2 Cache.In dem Fall ist ein Kanal nur 32bit breit. Pitcairn und Tahiti haben 64kB pro Kanal, CapeVerde und Bonaire 128kB pro 32bit Kanal (also 512kB insgesamt). Das ist auch wichtig für die Bandbreite, weil jeder L2-Tile 64Byte/Takte liefern kann und das bei Tahiti eben 12 L2-Tiles sind und nicht nur 6 (L2 Bandbreite also aggregiert 768 Byte/Takt, da gibt es eine richtig fette Crossbar zwischen den 12 L2-Tiles auf der einen Seite und 32 vL1-D, 8 sL1-D und 8 L1-I Caches auf der anderen, alle Clients sind jeweils mit 64Byte/Takt angebunden).

[Skysnake]

Bandbreite ist auch richtig, aber Stromsparen?
ja

Bist Du Dir da sicher?

Ja, ganz sicher ;)

nVidia hat doch vor mehr als einem Jahr mal ne Presentation gemacht, die hier auch Gipsel gezeigt hat. Ansonsten such einfach mal nach Exaskale und Powerconsumption usw. Da gibts genug Papers, die sich mit der Problematik beschäftigen.

Eine DP-Flop kostet ungefähr so viel Strom, wie die Daten dafür einen Millimeter über den Chip zu jagen. Wenn du offchip gehst und eben die SerDes brauchst, dann kommste auf nen Faktor ~1000! mal mehr Energiebedarf für den Datentranser als für den Millimeter onChip.

Das ist ja auch einer der Punkte, an denen nVidia ansetzen will mit ihrem großen zentralen Registerfile usw usw usw.

Auch HMC schlägt da mit seiner Near- and Longrange Anbindung in diese Kerbe. Ich weiß jetzt aber nicht, ob ich dazu noch mehr sagen kann, daher belasse ich es mal dabei.


Transistoren kosten Strom, die im Cache zwar nicht viel, aber sie brauchen auch was. Da stell ich mir ne Speicheranfrage an DDR3 stromgünstiger vor.

Da liegst du leider völlig daneben, und das ist durchaus ein sehr sehr sehr sehr sehr! großes Problem!


Der eine Thread muss natürlich länger warten und tut nichts in der Zeit, aber genau dafür laufen schließlich ein paar 100 Threads quasi-parallel auf ner GPU.

Das ist gar nicht so das riesen Problem. Ohne Caches musst du öfters auf den RAM, und das killt dir die Effizienz. Das ist ja auch einer der Punkte, warum APUs prinzipbedingt effizienter sein können.


Ist das wirklich die Schwierigkeit von GPUs? Dachte bisher, dass das größte Problem ist die hohe Parallelität auszunutzen. Alle Probleme lassen sich einfach nicht in mehrere Threads zerlegen.

Nein lassen Sie sich nicht...

Das Problem ist eigentlich "nur": "Wie bekomme ich schnell genug die Daten zu den ALUs, damit die nicht leer laufen"!

Und dafür nimmt man eben höhere Latenzen in Kauf, um mehr Bandbreite zu erreichen, und die Caches erhöhen halt den Datenreuse, weil man selbst mit dem schnellsten Speicher am 512Bit Interface die Rohleistung nicht auf die Straße bekommen würde. Deswegen eignen sich GPUs ja nur für Algorithmen, die eine hohen Datenreuse und eine gutartige Datenlokalität, sowie gutartige Zugriffsmuster haben...

Trifft das nicht zu, verhungern dir schnell die ALUs, und du bist langsamer als mit ner CPU, die über ihre fetten! Caches vieles abpuffern kann an irregulären und weitverstreuten Zugriffen, also insbesondere bei "geringer" Datenlokalität.


Caches wären sicherlich auch für ne GPU sinnvoll, aber aufgrund der vielen Threads schauts dort mit der Datenlokalität doch ziemlich sch..lecht aus.

Nein, weil siehe oben. Du nimmst du entsprechende PRobleme und größere Caches bedeutet, du kannst Probleme "sinnvoll" angehen, die mit kleineren eben nicht gingen, wegen zu schlechter Datenlokalität usw.

[Locuza]

Mal kurz ein "altes Thema" hervor gekaut:
Steamroller fetched doch jetzt nur alle 2 Takte und nicht jeden Takt wie Bulldozer/Piledriver.
Nimmt das nicht viel Wind aus den Segeln?

[S940]

Eine DP-Flop kostet ungefähr so viel Strom, wie die Daten dafür einen Millimeter über den Chip zu jagen. Wenn du offchip gehst und eben die SerDes brauchst, dann kommste auf nen Faktor ~1000! mal mehr Energiebedarf für den Datentranser als für den Millimeter onChip.

Das ist ja auch einer der Punkte, an denen nVidia ansetzen will mit ihrem großen zentralen Registerfile usw usw usw.
Hmm ok, klingt einigermaßen plausibel ;-) Danke :)

Das ist gar nicht so das riesen Problem. Ohne Caches musst du öfters auf den RAM, und das killt dir die Effizienz. Das ist ja auch einer der Punkte, warum APUs prinzipbedingt effizienter sein können.
Moment .. wenn APUs jetzt prinzipbedingt effizienter sein sollen, dann kann das doch nur wg. der GPU sein, und das wär dann mein Argument oder? GPUs haben zumindest im Moment ja eben keine Riesenchaches (btw: Danke an Gipsel für die Detailangaben).

Und dafür nimmt man eben höhere Latenzen in Kauf, um mehr Bandbreite zu erreichen, und die Caches erhöhen halt den Datenreuse, weil man selbst mit dem schnellsten Speicher am 512Bit Interface die Rohleistung nicht auf die Straße bekommen würde. Deswegen eignen sich GPUs ja nur für Algorithmen, die eine hohen Datenreuse und eine gutartige Datenlokalität, sowie gutartige Zugriffsmuster haben... Naja, das ist nun der springende Punkt. Datenbanken brauchen sehr große Caches. Glaube jetzt kaum, dass das bisschen kB bei den aktuellen Chips groß was ausrichten würde. Nochdazu da auf einer GPU deutlich mehr Threads laufen, die trashen sich dann doch den L2-Cache in jedem Takt/Wavefront-wechsel. Oder meintest Du mit Re-Use, dass mehrere Threads die gleichen Daten brauchen? Stell ich mir bei ner DB dann auch schlecht vor.
Trifft das nicht zu, verhungern dir schnell die ALUs, und du bist langsamer als mit ner CPU, die über ihre fetten! Caches vieles abpuffern kann an irregulären und weitverstreuten Zugriffen, also insbesondere bei "geringer" Datenlokalität.Also sind wir uns da einig, dass die aktuellen GPU-Caches bei schlechter Datenlokalität nicht viel helfen? Davon ging ich aus, hatte da schon im ersten Post den Datenbankfall im Hinterkopf.
Frage die mich jetzt noch interessieren würde, wäre die benötigte Cachegröße in Abhängigkeit von den Threads. Aber das ist wohl nur wieder ne Funktion der entsprechenden Anwendung, je nachdem ob der Code nun viel Daten wiederverwendet oder nicht. Bei HPC-Sachen gehts gut, bei DB-Sachen dagegen wohl eher nicht, genauer wird mans schlecht eingrenzen können, oder?
Im Endeffekt sind wir dann wieder beim deutlich größeren Caches mittels TSVs / HMC. Da ist immerhin die erste Spec fertig, mal schauen, obs 2014 Chips damit gibt.

Mal kurz ein "altes Thema" hervor gekaut:
Steamroller fetched doch jetzt nur alle 2 Takte und nicht jeden Takt wie Bulldozer/Piledriver.
Nimmt das nicht viel Wind aus den Segeln?
Überleg mal logisch: Wie sinnvoll wäre es, wenn eine Komponente auf dem Chip per Designentscheidung in 50% der Fälle (jeden 2. Takt) überhaaupt NICHTS machen würde?

Wäre selten blöd... was man da noch beachten muss ist auch der Fall, dass GCC im Defaultfall nur Code für einen Thread/Prozess erzeugt. Bin mir aus beiden Gründen deshalb zu 99% sicher, dass sich das auf einen Thread bezieht und im 2. Takt halt schlicht der 2. Thread drankommt.

Das 1% Unsicherheit bezieht sich darauf, dass der Info nicht zu 100% getraut werden kann. Im alten Code für BD hatten sie einfach die K10-Logik mit 3 Fast-Decoder + 1 Complex kopiert.

Interessanter sind da die Infos von 4 Ops maximal für beide Threads. Klingt nach nem 2+2 Decoder, nicht 4+4. Offiziell versprach AMD ja auch nur die Dispatchbandbreite zu erhöhen, über Decode sagten sie nichts, außer dass es 2 eigene Decoder geben soll. Aber mal schauen was kommt.

[Skysnake]

Moment .. wenn APUs jetzt prinzipbedingt effizienter sein sollen, dann kann das doch nur wg. der GPU sein, und das wär dann mein Argument oder? GPUs haben zumindest im Moment ja eben keine Riesenchaches (btw: Danke an Gipsel für die Detailangaben).

Jaein.

Bei den APUs kannst du halt für simplere Sachen die iGPU nutzen, die halt "dümmer" ist, und z.B. halt weniger Decoderoperationen/Instruktion ausführt durch das SIMD/Wavefront/Warp-Design. Das spart dir schonmal Energie. Dazu kommt halt noch die "fehlende" Branchprediktion, die einen halt nicht stört, wenn man Sie eh nicht braucht. ;)

Hilft auch wieder Energie zu sparen usw usw.

Gegenüber CPU+dGPU, hat man diesen Vorteil bzgl. Logik/Funktionsumfang nicht. Da hat man ja auch eine "dumme" GPU. Dafür muss man halt erst die Daten rüber bekommen... Und ich hab ja vorher ausführlich erklärt, wieviel Energie so ein bischen Daten hin und her schieben kostet. Vor allem wenn man offChip muss, was halt bei dGPU immer der Fall ist ;)

Daher ist die APU prinzipbedingt effizienter, wobei man sich natürlich schon die Implementierung anschauen muss!


Naja, das ist nun der springende Punkt. Datenbanken brauchen sehr große Caches.

Jaein.

Kommt immer darauf an, WAS! du machst.

Sind die Datenzugriffe mit einer gewissen Lokalität gegeben, ist das Workingset jetzt groß oder klein?

Willst du "nur" lesen, oder auch schreiben?
Willst du etwas suchen?
Oder willst du eventuell die DB sortieren?

Gerade beim sortieren von Daten kann eine GPU trotz der kleinen Caches+Register ziemlich viel performance bringen! Voll auslasten geht aber nicht.

Zudem ist es halt so, das je kleiner die Caches sind, desto mehr muss man über den Offchip Speicher... Wieder viel Energieverbrauch..


Glaube jetzt kaum, dass das bisschen kB bei den aktuellen Chips groß was ausrichten würde.

Oh unterschätz so ein paar kB nicht!
16kB mehr oder weniger pro CU sind halt mal schnell ~50% Unterschied, einfach weil die Caches so klein sind. Das kann schnell darüber entscheiden, ob du die GPU auslasten kannst oder nicht. Also natürlich immer bei "gutartigen" Programmen.


Nochdazu da auf einer GPU deutlich mehr Threads laufen, die trashen sich dann doch den L2-Cache in jedem Takt/Wavefront-wechsel.

Nicht zwingend. Durch die größeren Caches musst du ja seltener die Threads durchrotieren, weil du die Daten schon da hast usw usw.


Oder meintest Du mit Re-Use, dass mehrere Threads die gleichen Daten brauchen?

Nein, aber kommt natürlich auch vor.

Ich meinte, dass die Threads die Daten, die Sie selbst produzieren eben selbst nutzen können.

Wenn die Caches/Register zu klein sind, stalled halt die GPU im Normalfall, weil du eben einfach keine Daten zu den ALUs bekommst! Das ist wie schon gesagt eigentlich DAS Problem bei GPUs. Wie bekomme ich genug Daten zu den ALUs. Darum dreht sich eigentlich alles! Deswegen macht man ja auch z.B. so Späße wie: Hey ich rechne einen Wet lieber 10 mal aus, und hab dafür 10x64Bit mehr Platz, wo ich dann wieder Rohdaten drin speichere, dann kann ich nämlich Y Rechenoperationen mehr machen, denn wenn ich das Zwischenergebnis speichern würde, würde ich trotzdem nicht genug Daten zu den ALUs bekommen... Also "stört" es mich nicht, das ich etwas mehfach berechne. ;D Bei CPU-Programmierung würde man dich für so etwas erschlagen ;)

Kleines Rechenbeispiel:

Wenn du 1TFlop/s DP Rechenleistung hast, und A*B=C machst, dann brauchst du 3*64Bit/Flop*1TFlop/s=192TBit/s also 24TB/s!!! an Bandbreite um die ALUs nicht verhungern zu lassen. Und jetzt schau dir mal an, wie viel du über ein 384Bit GDDR5 Interface mit dem schnellsten Speicher bekommst ;)

Ich hoffe dir wird klar, warum Datenreuse/-lokalität so EXTREM wichtig ist für GPUs.


Stell ich mir bei ner DB dann auch schlecht vor.

Datenbanken eignen sich für GPUs eher nicht. Wenn dann für die Berechnung irgendwelche Hash-Funktionen, oder eben zum sortieren der Daten, einfach weil Sie so Bandbreitenoptimiert sind.


Also sind wir uns da einig, dass die aktuellen GPU-Caches bei schlechter Datenlokalität nicht viel helfen? Davon ging ich aus, hatte da schon im ersten Post den Datenbankfall im Hinterkopf.

Schlag dir Datenbanken aus dem Kopf... Das ist zu stark auf einen zu kleinen Anwendungsfall fokusiert.

Wenn du größere Caches hast, kannst du GPUs einfach für mehr! nehmen, weil Sie nicht so schnell mehr in der Leistung einbrechen. Und bei GPUs helfen einfach schon vergleichsweise kleine Cachevergrößerungen sehr viel, weil man eh von "gutartigen" Problemen ausgehen muss, weil man sonst eh nicht schneller ist als mit der CPU...

CPUs haben auch schon sehr große Caches. Da machen 16kB mehr pro Core nicht viel aus. Bei ner GPU sind 16kB mehr Cache pro CU sehr sehr viel ;)


Frage die mich jetzt noch interessieren würde, wäre die benötigte Cachegröße in Abhängigkeit von den Threads.

Hängt vom Problem ab.


Aber das ist wohl nur wieder ne Funktion der entsprechenden Anwendung, je nachdem ob der Code nun viel Daten wiederverwendet oder nicht.

Richtig. GPUs will man eigentlich immer verwenden, bei vielen Problemen geht es aber halt einfach nicht. Du musst dir da IMMER! nen Kopf drum machen, ob es überhaupt Sinn macht. Deswegen ist GPU-Programmierung auch noch mehr eine Kunst als Multi-Thread-Programmierung auf der CPU, und schon da steigen viele aus...


Bei HPC-Sachen gehts gut, bei DB-Sachen dagegen wohl eher nicht, genauer wird mans schlecht eingrenzen können, oder?

Bei HPC kommts auch darauf an, aber ja, im Allgemeinen sind die Probleme da relativ gutartig, so dass Sie sich "gut" auf GPUs mit ihren Einschränkungen mappen lassen.

Bei DB-Sachen kommt es halt wie gesagt darauf an. Sachen wie Sortieren können da schon sehr von ner GPU profitieren, wobei man da dann schauen muss, ob eher von dGPU oder iGPU. Die dGPUs haben halt den Vorteil der hohen GDDR5 Bandbreite. Das hat die APU nicht. Dafür muss die dGPU erst mal die Daten durch den PCI-E Flaschenhals bekommen und wieder zurück schicken...

Ist also ALLES! nur NICHT! einfach.


Im Endeffekt sind wir dann wieder beim deutlich größeren Caches mittels TSVs / HMC. Da ist immerhin die erste Spec fertig, mal schauen, obs 2014 Chips damit gibt.

Jaein.

TSV/HMC machen die Sache deutlich angenehmer als mit nem externen Interface wie GDDR5, aber deswegen kann man die Caches/Registerfiles nicht einfach vergessen... Die sind trotzdem noch so wichtig wie bisher auch. Die Datenmengen sind einfach abartig groß, haste ja oben an dem Rechenbeispiel gesehen.

Ich hoffe jetzt ist es klarer, wenns noch Fragen gibt, immer her damit ;)

[Blediator16]

Ein Lacher für zwischendurch:

http://wccftech.com/rumor-amd-phenom-iv-x12-170-baeca-25nm-cpu-leaked-features-12-cores-6-ghz-core-clock-am4-socket-compatbility/

[Skysnake]

omfg wie schlecht :facepalm:

[OBrian]

it's true, I read it on the internet.

Mal sehen, in wievielen Monaten DAS wieder rumkommt und irgendwo als "neuestes Gerücht" präsentiert wird.

[S940]

@Skysnake:
Danke für die detaillierte Antwort. Mit den Aussagen bin ich zufrieden:
1.
Datenbanken eignen sich für GPUs eher nicht.Also auch nicht für APUs, ergo lieber CPUs mit viel Cache für Datenbankserver. Das war ja der Startpunkt, als ich APUs mit L3 als weder Fisch noch Fleisch bezeichnete. Erkenntnisgewinn ist also, dass nach Deiner Aussage ein L3 schon etwas bringen würde, da man dann die GPU auf mehr Probleme ansetzen kann, Nachteil wird sein, dass die aktuellen Probleme/Algorithmen nicht viel vom Cache haben und mit mehr Shadern besser bedient wären. Ist dann halt die Frage, was man will.
Kontext war ja auch der 8MB große L3-Cache. Der frisst einiges an die Fläche. Logische Weiterentwicklung wäre dann für ne APU kein Riesen-L3 ein paar kB mehr L1+L2 und möglichst mehr Shader. Ich denke da sollten wir dann auf ner Linie sein, oder?

TSV/HMC meinte ich auch nicht als RAM-Ersatz, sondern als L3-Cache-Ersatz. Auf nem extra DIE gäbs das dann ja für quasi umsonst, man müsste deshalb nicht die Shaderfläche reduzieren.
2.
Wenn du größere Caches hast, kannst du GPUs einfach für mehr! nehmen, weil Sie nicht so schnell mehr in der Leistung einbrechen. Und bei GPUs helfen einfach schon vergleichsweise kleine Cachevergrößerungen sehr viel, weil man eh von "gutartigen" Problemen ausgehen muss, weil man sonst eh nicht schneller ist als mit der CPU... Das ist halt wieder die Frage zw. qualitativer und quantitativer Aussagen. Wo beginnt "mehr" und wo hört es auf. Datenbanken und angeschlossene ERP-Systeme sind mir halt für nicht-gutartige Probleme in Erinnerung. Einzelne Vorgänge wie Sortieren mögen schön berechenbar sein, aber im Großen und Ganzen läufts da eher chaotisch ab, das sind einfach Riesendatenmengen, 16kB mehr Cache mögen 50% mehr sein, aber wenn der Datensatz einige TB umfasst und selbst das Workingset davon nur 1/100 beträgt, sind Kilobyte nur Peanuts. Du schriebst dann ja selbst:
Schlag dir Datenbanken aus dem Kopf Das war halt nur genau mein Argument, dass es mit DBs&Co schlecht auf GPUs aussieht.

Was wäre aus Deiner Sicht denn die Worst-Case-Anwendung für ne GPU?

Um mal kurz dem Bogen zu der anderen Diskussion über Power/PPC zu spannen: Ne APU aus Jaguar+GPU mit huma und/oder nem ARM64-Kern wäre dann aus "Perf/Watt-HPC-Green500-Sicht" so ziemlich optimal, oder? Mal schauen ob MS seinen XBox1-SoC auch noch im HPC-Bereich einsetzen will, wenn sies schon auf der hotchips präsentieren...

[Gipsel]

TSV/HMC meinte ich auch nicht als RAM-Ersatz, sondern als L3-Cache-Ersatz.Welchen Sinn soll denn das machen? Wenn ich schon den Aufwand für HMC treibe, dann staple ich auch in einem Cube mit mindestens 4 wenn nicht gleich 8 DRAM-Dies auch gleich die zu je mindestens 4 oder gleich 8 GBit, das macht dann also 2, 4 oder 8GB pro Cube. Für nur 2 Dies mit nur 1GBit (werden die überhaupt noch hergestellt? in einem Jahr sicher nicht mehr) braucht man sich den ganzen Kostenaufwand doch nicht antun.

[Hübie]

Mal ne Frage in den Raum geworfen: Werden die neuen CPUs auch mal bzgl. des Speichers Energiesparmechanismen einführen? Ich frage mich schon lange warum auf der Graka der VRAM herunter taktet, die Spannung senkt und somit den Energiebedarf reduziert, aber normaler DRAM immer noch mit konstanten Einstellungen läuft. Die Möglichkeit ist ja da.
Wäre es ungleich komplexer einen IMC mit solchen Mechanismen auszustatten? So dass der Entwickler sagt: "Okay der Aufwand rechtfertigt nicht den Nutzen!". Besonders in kommenden Generationen kommt doch Speicher und Bandbreite immer mehr Bedeutung zu.

Was ist denn TSV nun wieder für eine Terminologie? Turn und Sportverein sicher nicht... :confused:;D

[S940]

Welchen Sinn soll denn das machen? Wenn ich schon den Aufwand für HMC treibe, dann staple ich auch in einem Cube mit mindestens 4 wenn nicht gleich 8 DRAM-Dies auch gleich die zu je mindestens 4 oder gleich 8 GBit, das macht dann also 2, 4 oder 8GB pro Cube. Für nur 2 Dies mit nur 1GBit (werden die überhaupt noch hergestellt? in einem Jahr sicher nicht mehr) braucht man sich den ganzen Kostenaufwand doch nicht antun.
Ach stimmt ja, HMC erlaubt ja noch größere Speichermengen. Sorry, mein Fehler, hatte da fälschlicherweise noch Intels 64MB Lösung in Erinnerung.

Wobei es bei gaaaanz großen Anwendungen eventuell doch noch Sinn machen könnte ^^
Samsung hat für DDR4 LRDIMMs mit 128GB angekündigt. Mit dem üblichen Quadchannel wären das dann also 512GB. Da wären 8GB als L3-Cache in dem Extremfall vielleicht doch nicht mal soo verkehrt.

Edit: @Hübie:
TSV = "Durch-Silizium-Verbindung":
https://de.wikipedia.org/wiki/Silizium-Durchkontaktierung

Damit kann man halt 2 DIEs mit "supertoller" Bandbreite verbinden. Da böte sich halt v.a. ne Kombination aus CPU+Speicher an. Um das "supertoll" besser einordnen zu können, es stehen 1024 bit im Raum, Dual-channel DDR3 hat zum Vergleich 128bit ... noch Fragen? :)

Zu den Stromsparmodi: Ich glaub Mobile-CPUs können das schon, aber im Desktop ists Kleinkram, ein RAM-Modul braucht so ~5W maximal, eher weniger, da spart man mit ein paar weniger Mhz nicht wirklich viel. Dann eher gleich Low-Voltage RAMs mit 1,25/1,35V.

[Hübie]

Through silicone via hätte mir gereicht. Hab da vor Jahren mal was gelesen. Danke für die ausführliche Antwort.
LP-DRAM ist ja nix weiter als handselektierte Module zu labeln. Bei Energiesparmechanismen meine ich gleich Dinge wie Takt senken, Spannung abfallen lassen und ggf. partielle Abschaltung. Ich habe nur absolut keine Ahnung wie ein IMC aufgebaut ist. Kann mir da jemand eine Lektüre empfehlen/verlinken?

[Gipsel]

LP-DRAM ist ja nix weiter als handselektierte Module zu labeln. Bei Energiesparmechanismen meine ich gleich Dinge wie Takt senken, Spannung abfallen lassen und ggf. partielle Abschaltung.Nicht ganz, die ganzen LP-DDRx sind zwar verwandt, aber inkompatibel zu dem normalen DDRx. Da wird schon etwas mehr geändert als nur die Versorgungsspannung. Das wäre dann DDR3L (1,35V) oder DDR3U (manchmal auch UL genannt, 1,25V), welche man auch ganz normal an einem jedem DDR3-Controller betreiben kann, mit LP-DDR3 geht das nicht unbedingt (gibt natürlich auch Kombi-Controller), das Interface und Protokoll unterscheidet sich.

[Skysnake]

@Skysnake:
Danke für die detaillierte Antwort. Mit den Aussagen bin ich zufrieden:
1.
Also auch nicht für APUs, ergo lieber CPUs mit viel Cache für Datenbankserver. Das war ja der Startpunkt, als ich APUs mit L3 als weder Fisch noch Fleisch bezeichnete. Erkenntnisgewinn ist also, dass nach Deiner Aussage ein L3 schon etwas bringen würde, da man dann die GPU auf mehr Probleme ansetzen kann, Nachteil wird sein, dass die aktuellen Probleme/Algorithmen nicht viel vom Cache haben und mit mehr Shadern besser bedient wären. Ist dann halt die Frage, was man will.

AH... ;D

Das ist halt kompliziert. Datenbanken an sich eignen sich nicht für GPUs. Also Datenbanken in denen man fast nur lesen muss. Da ändert sich einfach nichts. Wenn man die Daten in der Datenbank aber ständig auswerten/vergleichen muss, oder diese ständig anpassen und neu sortieren muss, dann lohnt sich ne GPU schon wieder. Die kann nämlich durchaus gut eingesetzt werden um die Datenbank zu sortieren. Auch wenn du ständig Hashvalues neu berechnen musst usw ist ne GPU schick.

Es kommt also immer! darauf an, was du mit der Datenbank machen willst. Eine "klassische" Datenbank profitiert nicht wirklich von nur iGPU geschweige denn ner dGPU. Aber bei google reden wir von BigData und eben komplexer Datenanalyse/Auswertung. Das ist zwar auch "Datenbank" aber doch wieder anders. Das ist ja der Grund, warum ich sage es hat absolut seinen Grund warum da google dabei ist, und das ich denke dass sie die treibende Kraft dahinter sind. Ne ZSeries würden die wohl nie einsetzen. Das ist dann doch wieder total weg von ihrem! ganz speziellen Einsatzbereich.

Interessant ist wie gesagt die Zweigleisigkeit zwischen Microserver und dem Power+GPU Konzept. Da muss man schauen, was draus wird. Eventuell will google aber auch zwei unterschiedliche Architekturen einsetzen. Keine Ahnung. google ist so ein Monster, das könnte sich sogar für Sie lohnen. Die Stromkosten fressen Google einfach die Haare vom Kopf... Da könnte sich der Aufwand für gleich zwei Speziallösungen durchaus lohnen.


Kontext war ja auch der 8MB große L3-Cache. Der frisst einiges an die Fläche. Logische Weiterentwicklung wäre dann für ne APU kein Riesen-L3 ein paar kB mehr L1+L2 und möglichst mehr Shader. Ich denke da sollten wir dann auf ner Linie sein, oder?

Nein, ohne Cache verhungert die iGPU.

Du musst dir einfach klar werden, was ein Cache bewirkt. Er sorgt dafür dass du ein Datum nicht nur einmallig oder zweimalig verwendest, sondern 10, 20, 100 oder auch 1000 mal.

Dafür muss das Workingset halt in den Cache passen... Sonst wird er schnell nutzlos, weil du nur noch den Cache trashst.... Deswegen ist es wie beim Hubraum bei Motoren bigger ist better und Hubraum kann nur durch eins ersetzt werden MEHR Hubraum :biggrin:
Caches bringen dir halt flexibilität, und daran mangelt es GPUs leider noch immer.


TSV/HMC meinte ich auch nicht als RAM-Ersatz, sondern als L3-Cache-Ersatz. Auf nem extra DIE gäbs das dann ja für quasi umsonst, man müsste deshalb nicht die Shaderfläche reduzieren.

Mit HMC usw. Werden die Grenzen zwischen klassischen Cache und RAM immer fliesender. Man schließt halt Lücken wo es geht. Das macht die Sache aber halt immer schwieriger zu bewerten :( Über die Sachen machen sich deswegen auch sehr sehr viele Leute gedanken, was denn die "richtigen" Werte/Entscheidungen sind, und realistisch betrachtet wird man wohl einfach immer die falsche Entscheidung im Einzelfall treffen. Die Probleme sind einfach zu unterschiedlich, und gleichzeitig ist man gezwungen ZU spezielle Lösungen zu machen, um überhaupt die gewünschten Leistungssteigerungen zu erreichen :( Die niedrigen Früchte sind halt schon alle lange gepflückt.


2.
Das ist halt wieder die Frage zw. qualitativer und quantitativer Aussagen. Wo beginnt "mehr" und wo hört es auf. Datenbanken und angeschlossene ERP-Systeme sind mir halt für nicht-gutartige Probleme in Erinnerung. Einzelne Vorgänge wie Sortieren mögen schön berechenbar sein, aber im Großen und Ganzen läufts da eher chaotisch ab, das sind einfach Riesendatenmengen, 16kB mehr Cache mögen 50% mehr sein, aber wenn der Datensatz einige TB umfasst und selbst das Workingset davon nur 1/100 beträgt, sind Kilobyte nur Peanuts.
...
Ok, ich versuchs zu erklären, aber ich befürchte es wird mir nicht gelingen. Um das(die) Problem(e) wirklich zu begreifen muss man glaube ich einfach mal selbst einige Probleme implementiert haben, um einfach ein "feeling" für gewisse Dinge zu entwickeln.

Sortieren, auf was ich hier anspiele, ist relativ gutartig, wenn man die entsprechenden Sortieralgorithmen verwendet. Da bringen schon einige kB mehr Cache einen um faktor 10 oder mehr höheren Datenreuse, weil man nach dem Prinzip "devide and concer" arbeitet. Das ist halt die Grundlage dieser Algorithmen, und auch mit ein Grund, warum Sie sich so gut für Cachesysteme eignen, ganz abgesehen von der Komplexität.

Wie gesagt, das sollte man aber einfach mal selbst implementiert haben als SingleThread auf ner CPU, MultiThread CPU, und auf ner GPU. Erst dann erkennt man viele Zusammenhänge und Auswirkungen. Mach dir bitte wirklich nichts draus, wenn du das nicht verstehen kannst. >90% der Informatikstudenten werden das wohl auch nicht verstehen, weil noch immer in ner SingleThread Welt leben... Und von den 10% die Multithread denken, steigen nochmal locker 50% der Leute bei dem Verständnis von GPUs aus. Das ist einfach richtig harter Tobak, für den sich viele Leute auch gar nicht interessieren.

Ich kann dir da nur das Buch hier empfehlen:Programming Massively Parallel Processors: A Hands-On Approach (Applications of GPU Computing Series) (http://www.amazon.de/b%C3%BCcher/dp/0123814723)
Das hatten wir in der Vorlesung auch als Grundlage. Einen besseren Einstieg gibt es glaube ich auch nicht wirklich, um es "leicht" zu verstehen.

Das Problem ist, das Buch ist eigentlich schon wieder outdated... Ich hab selbst rein gar nichts im Rahmen der Vorlesung aus dem Buch mitnehmen können, einfach weil es inzwischen sogar schon 2-3 Generationen hinten dran ist. Bei GPUs ist die Entwicklung noch extrem schnell und groß! Das macht die Sache auch so extrem aufwändig richtig zu verfolgen ein zu schätzen. 6-12 Monate und die Welt sieht ziemlich anders aus. Die Grundsätze bleiben erhalten, aber die Grenzen verschieben sich teilweise massiv! Das erfordert SEHR viel Initiative um da up to date zu bleiben. Du willst gar nicht wissen, wieviele Stunden ich mich fortlaufend intensiv mit GPUs und allgemein Hardwaretechnologie beschäftige. Im Schnitt werden das sicherlich 20h+ im Monat sein. Man kann einfach nur lesen lesen lesen und versuchen auch mal selbst was zu programmieren. Mit etwas glück bleibt man halbwegs am Ball.



Du schriebst dann ja selbst:

Das war halt nur genau mein Argument, dass es mit DBs&Co schlecht auf GPUs aussieht.

Ok, ich sollte doch manchmal aufpassen, das ich mich klarer ausdrücke, es fällt mir aber teilweise schwer die RIESEN wulst an Wechselwirkungen unter kontrolle zu halten und dann auch noch so zu formulieren, das es noch irgendjemand versteht, dem es nicht eh "klar" ist.

Ich meinte da "klassische" Datenbanken, also solche in denen man 99,999% der Zeit nur liest und mal einen einzelnen Wert abändert, aber nicht ständig umsortieren muss, und auch keine Berechnungen erst durchführen muss um überhaupt mit den Daten etwas anfangen zu können. Also nicht BigData.


Was wäre aus Deiner Sicht denn die Worst-Case-Anwendung für ne GPU?

Teile davon ja.

BigData führt halt zu "neuen" Problemen, die man lösen muss, und da kann eine iGPU!!!, ganz wichtig, dGPUs eigentlich nicht, teilweise dann schon wieder glänzen. Die Probleme werden halt vielschichtiger mit BigData. Wird aber schon wieder alles sehr speziell und trifft nicht für jeden zu. Deswegen wird es auch nicht allgemein entwickelt, sondern Firmen wie Google und Facebook stoßen von SICH! aus die Entwicklung an, einfach weil Sie so groß sind, dass sich der Aufwand für sich "allein" schon wieder lohnt. Die sind halt vom "normalen" Makrt schon wieder teilweise total abgehoben.


Um mal kurz dem Bogen zu der anderen Diskussion über Power/PPC zu spannen: Ne APU aus Jaguar+GPU mit huma und/oder nem ARM64-Kern wäre dann aus "Perf/Watt-HPC-Green500-Sicht" so ziemlich optimal, oder? Mal schauen ob MS seinen XBox1-SoC auch noch im HPC-Bereich einsetzen will, wenn sies schon auf der hotchips präsentieren...
Jaein.

Ein Supercomputer besteht nicht nur aus der CPU/APU, sondern auch aus dem Interconnect usw. Und da seh ich dann schon schwächen. Allein schon das fehlende ECC ist eigentlich ein KO Kriterium.

Auf der anderen SEite wäre ein Supercomputer aus Smartphones wohl am "Effizientesten" aber halt nur für ganz spezielle Probleme, und dann auch nur mit extremem Aufwand. So was kannste normal einfach nicht einsetzen...

BOINC hat aber z.B. inzwischen auch Smartphones includiert in ihr Grid. Grid Probleme sind aber wieder ganz Speziell und BOINC nochmals.

Das ist halt echt alles SEHR komplex, und es gibt so viele Fallstricke, das man da echt aufpassen muss mit irgendwelchen Aussagen. Es ist halt einfach nicht einfach ;D Aber deswegen SEHR spannend :biggrin: :up:

Aber um nochmal auf den Punkt zu kommen. JA man sollte davon ausgehen, das AMD in nächster Zeit APUs auch in den HPC-Bereich bringt. So wirklich durchsetzen wird sich das aber frühestens wenn GDDR5 hierfür verwendet wird, oder so etwas wie HMC bei den APUs zum Einsatz kommt. DDR3 ist einfach doch ein ziemliches Handycap für APUs, vor allem wenn man keinen großen eDRAM oder so hat wie Intels Haswell. Das kann vieles abfedern, aber ist dann doch auch wieder nicht so trivial wie man sieht an Haswel...

dGPUs leben halt auch mit von ihrem sehr sehr breiten SI und der hundertprozentigen Optimierung auf Durchsatz. Bei APUs muss man da gewisse Kompromisse eingehen. Dafür hat man halt den PCI-E Flaschenhals nicht, der in einigen/vielen/den meisten Problemen ein KO-Kriterium ist. Die ganze Sachen sind halt wie gesagt sehr komplex und sehr vielschichtig.

[Exxtreme]

Interessante Diskussion. :up:


In einer Sache will ich aber einhaken:


Datenbanken eignen sich für GPUs eher nicht. Wenn dann für die Berechnung irgendwelche Hash-Funktionen, oder eben zum sortieren der Daten, einfach weil Sie so Bandbreitenoptimiert sind.


Rund 85% der Datenbankaktivität, die eine CPU durchführt sind in der Tat das Erzeugen und Vergleichen von irgendwelchen Hash-Werten. ;) Wobei das jetzt nicht so wichtig ist, da eine DB ganz woanders viel krasser limitiert.

[Skysnake]

Kommt drauf an, ob Sie gehasehed ist oder nicht. Gibt ja auch noch balances Trees usw ;)

Das Fass wollte ich jetzt aber nicht auch noch aufmachen... Das ist halt das Problem an der ganzen Sache, wenn man mal anfängt wirklich vernünftig darüber zu reden kommt man vom hundersten ins tausendste... Man findet einfach gar kein Ende, was denn alles zu beachten ist, und was nicht, und wie wo welche Spezialfälle da sind und schlag mich tot. Das artet ECHT in Arbeit aus... Den ganzen Shit zieh ich mir auch nicht mehr einfach so aus den Fingern, sondern muss mal drüber nachdenken oder auch mal was nachschlagen...

Und ja, teilweise überseh ich so Sachen dann auch zu erwähnen, das normal Datenbanken ja auf Hashtables aufbauen, aber halt auch nicht immer, wobei ich jetzt sagen muss, bzgl dem wie Datenbanken dann jeweils wirklich genau Implementiert werden bin ich auch nicht drin. Datenbanken hab ich selbst nicht gehört. Irgendwo muss man auch mal nen Schlussstrichmachen, sonst wird man NIE fertig und hört 100 Vorlesungen...

[samm]

Man kann nie genug wissen :) Fand die DB-Vorlesungen für ein zunächst trocken scheinendes Thema äusserst spannend und umfassend, hab da ne Menge über konkrete Anwendung von Algorithmen, Datenstrukturen, I/O-Optimierung, Kompressionsverfahren, API-Design und eher deutlich DB-spezifische Themen wie Historisierung/Timestamping, Concurrency und Locking-Mechanismen etc. gelernt - also wenn es das Studium irgendwo erlaubt, und die entsprechenden Profs was taugen u. Praxis mit dabei ist: nimm dir die Zeit :)

[Skysnake]

Das hab ich schon bei zu vielen! Vorlesungen gemacht. Hab heute im PCGH bei nem Link den ich gepostet hab zufällig festgestellt, das ich nebenher die Vorlesungen für nen weiteren Master gehört hab :ugly:

Irgendwann muss auch mal gut sein, man will ja fertig werden ;D

[S940]

So nun hab ich endlich Zeit fürs Komplizierte ^^
(Vorneweg: Vielen Dank fürs Erklären).
Das ist halt kompliziert. Datenbanken an sich eignen sich nicht für GPUs. Also Datenbanken in denen man fast nur lesen muss. Da ändert sich einfach nichts. Wenn man die Daten in der Datenbank aber ständig auswerten/vergleichen muss, oder diese ständig anpassen und neu sortieren muss, dann lohnt sich ne GPU schon wieder. Die kann nämlich durchaus gut eingesetzt werden um die Datenbank zu sortieren. Auch wenn du ständig Hashvalues neu berechnen musst usw ist ne GPU schick.
Es kommt also immer! darauf an, was du mit der Datenbank machen willst.

Ja der Einsatzzweck ist sicherlich ein wichtiger Gesichtspunkt. "Datenbank" allein ist echt ein schwammiger Begriff. Blöd halt nur, dass man das in der Populärliteratur dann auch nicht detaillierter erklärt findet.


Interessant ist wie gesagt die Zweigleisigkeit zwischen Microserver und dem Power+GPU Konzept. Da muss man schauen, was draus wird. Eventuell will google aber auch zwei unterschiedliche Architekturen einsetzen. Keine Ahnung. google ist so ein Monster, das könnte sich sogar für Sie lohnen. Die Stromkosten fressen Google einfach die Haare vom Kopf... Da könnte sich der Aufwand für gleich zwei Speziallösungen durchaus lohnen.
Lol, ja gogle kann sich alles leisten. Frag mich nur, ob sie nur nen PPC+dGPU Ansatz verfolgen werden oder auf PPC+igpu setzen werden.
Wobei das mit PPC ja noch nicht in trockenen Tüchern ist, die Rede war im Konsortium glaube ich nur von der Freigabe des POWER8-Kerns... schließt PPC noch nicht aus, aber geht zumindest mal in die falsche Richtung.

Nein, ohne Cache verhungert die iGPU.Moment, Moooment, ich schrieb doch:

Logische Weiterentwicklung wäre dann für ne APU kein Riesen-L3 ein paar kB mehr L1+L2 und möglichst mehr Shader.Du hattest mir doch vorher erklärt, dass 32kb statt 16kB schon riesig viel bewegen würden, deswegen nahm ich an, dass Dir das gefällt. Also doch nicht, willst Du lieber L3 in MB-Slices, oder hattest Du die Passage falsch gelesen? Die restlichen Cacheerklärungen leuchten schon ein.

Ok, ich versuchs zu erklären, aber ich befürchte es wird mir nicht gelingen. Um das(die) Problem(e) wirklich zu begreifen muss man glaube ich einfach mal selbst einige Probleme implementiert haben, um einfach ein "feeling" für gewisse Dinge zu entwickeln.
DAnke für die Mühe. Knüpft eigentlich an den Anfang an. Vom Datenbankbegriff sind wir eine Ebene tiefer auf die verschiedenen Datenbankszenarien gegangen und jetzt gehts nochmal ne Ebene tiefer auf die Implementierungsebene.

Sortieren, auf was ich hier anspiele, ist relativ gutartig, wenn man die entsprechenden Sortieralgorithmen verwendet. Da bringen schon einige kB mehr Cache einen um faktor 10 oder mehr höheren Datenreuse, weil man nach dem Prinzip "devide and concer" arbeitet. Das ist halt die Grundlage dieser Algorithmen, und auch mit ein Grund, warum Sie sich so gut für Cachesysteme eignen, ganz abgesehen von der Komplexität.
Glaub ich gerne, hab mal vor Urzeiten nen Bubble und Heapsort programmiert, von daher leuchtet die Cachevorliebe für Sortieralgos ein ^^
(Unwichtige Typoanmerkung: Conquer, nicht concer, altfranzösisch ^^)

Wie gesagt, das sollte man aber einfach mal selbst implementiert haben als SingleThread auf ner CPU, MultiThread CPU, und auf ner GPU. Erst dann erkennt man viele Zusammenhänge und Auswirkungen. Mach dir bitte wirklich nichts draus, wenn du das nicht verstehen kannst. >90% der Informatikstudenten werden das wohl auch nicht verstehen, weil noch immer in ner SingleThread Welt leben... Und von den 10% die Multithread denken, steigen nochmal locker 50% der Leute bei dem Verständnis von GPUs aus. Das ist einfach richtig harter Tobak, für den sich viele Leute auch gar nicht interessieren.
Lol, ok multithread Sortieren ... öhm ... 3 Fragezeichen *G*
Geht das mit sowas wie Mapreduce? Anders kann ich mir da nichts vorstellen, aber mein Wissen in dem Bereich ist ... "begrenzt" ^^

Ich kann dir da nur das Buch hier empfehlen:Programming Massively Parallel Processors: A Hands-On Approach (Applications of GPU Computing Series) (http://www.amazon.de/b%C3%BCcher/dp/0123814723)
Das hatten wir in der Vorlesung auch als Grundlage. Einen besseren Einstieg gibt es glaube ich auch nicht wirklich, um es "leicht" zu verstehen.
Ich schau mal ob ichs in der hiesigen Bib finde, eine Blick reinzuwerfen trau ich mir, ob ich was verstehen werde (wenn sie das Buch überhaupt dahaben) ist aber ne andere Frage *G*


Das erfordert SEHR viel Initiative um da up to date zu bleiben. Du willst gar nicht wissen, wieviele Stunden ich mich fortlaufend intensiv mit GPUs und allgemein Hardwaretechnologie beschäftige. Im Schnitt werden das sicherlich 20h+ im Monat sein. Man kann einfach nur lesen lesen lesen und versuchen auch mal selbst was zu programmieren. Mit etwas glück bleibt man halbwegs am Ball.
Jupp nichts ist schnelllebiger als die Computerbranche. Gerade hat man noch C Pointer gelernt, dann kommt Java und wenn man das Javabuch dann hat, gibts plötzlich C# und Cuda und OpenCL und und und :freak:


Ok, ich sollte doch manchmal aufpassen, das ich mich klarer ausdrücke, es fällt mir aber teilweise schwer die RIESEN wulst an Wechselwirkungen unter kontrolle zu halten und dann auch noch so zu formulieren, das es noch irgendjemand versteht, dem es nicht eh "klar" ist.

Ich meinte da "klassische" Datenbanken, also solche in denen man 99,999% der Zeit nur liest und mal einen einzelnen Wert abändert, aber nicht ständig umsortieren muss, und auch keine Berechnungen erst durchführen muss um überhaupt mit den Daten etwas anfangen zu können. Also nicht BigData.
Haha, ja das ist das Problem, jeder stellt sich unter Datenbanken was anderes vor, aber ich denke, jetzt haben wirs wirklich teifgründig diskutiert. Danke für Deine Ausdauer sehr informativ :)

BigData führt halt zu "neuen" Problemen, die man lösen muss, und da kann eine iGPU!!!, ganz wichtig, dGPUs eigentlich nicht, teilweise dann schon wieder glänzen. Die Probleme werden halt vielschichtiger mit BigData. Wird aber schon wieder alles sehr speziell und trifft nicht für jeden zu. Deswegen wird es auch nicht allgemein entwickelt, sondern Firmen wie Google und Facebook stoßen von SICH! aus die Entwicklung an, einfach weil Sie so groß sind, dass sich der Aufwand für sich "allein" schon wieder lohnt. Die sind halt vom "normalen" Makrt schon wieder teilweise total abgehoben.
Alles klar, dazu nur ne Anmerkung, dass erinnert mich an AMDs Custom-SoC-Abteilung, die meinten da ja, dass sich größere Firmen einen eignen SoC nach ihren Anforderungen basteln können, und sich das auch leisten können. Schlägt wohl in ne ähnliche Kerbe, auch wenn man in Richtung AMD und custom APUs außer den Konsolen nichts gehört hat.

Jaein.
Ein Supercomputer besteht nicht nur aus der CPU/APU, sondern auch aus dem Interconnect usw. Und da seh ich dann schon schwächen. Allein schon das fehlende ECC ist eigentlich ein KO Kriterium.
Naja, das ist jetzt wieder ein ähnliches Mißverständnis wie bei den Datenbanken, wenn ich von ner APU mit Jaguar oder ARM64Kernen plus entsprechender iGPU für HPC rede, dann mein ich damit natürlich auch, dass die APU alles üblichen "HPC-Beiwerk" enthält, also ECC+IO. Ansonsten würde das Gedankenspiel doch gar keinen Sinn machen. Ne APU ohne ECC wäre bei HPC wahrlich nutzlos.

Auf der anderen SEite wäre ein Supercomputer aus Smartphones wohl am "Effizientesten" aber halt nur für ganz spezielle Probleme, und dann auch nur mit extremem Aufwand. So was kannste normal einfach nicht einsetzen...
Ok Smartphones ... aber naja, ne APU mit ARM-Cores ist davon ja nicht wirklich weit entfernt. Oder meinst DU eventuell nur Smartphone-CPUs?
Ansonsten könnte man noch diskutieren, wie die aktuellen iGPUs bei OpenCL / HPC-Workload abschneiden, die sind ja noch recht klein. Aber gut, in der Masse dann mit 1000++ Stück ... Allerdings wäre das dann wirklich zu weit weg voM Thema ^^

Aber deswegen SEHR spannend :biggrin: :up:Absolute Zustimmung :)

Aber um nochmal auf den Punkt zu kommen. JA man sollte davon ausgehen, das AMD in nächster Zeit APUs auch in den HPC-Bereich bringt. So wirklich durchsetzen wird sich das aber frühestens wenn GDDR5 hierfür verwendet wird, oder so etwas wie HMC bei den APUs zum Einsatz kommt. DDR3 ist einfach doch ein ziemliches Handycap für APUs, vor allem wenn man keinen großen eDRAM oder so hat wie Intels Haswell. Das kann vieles abfedern, aber ist dann doch auch wieder nicht so trivial wie man sieht an Haswel...
Hast Du das aktuelle ct Prozessorgeflüster gelesen? Da wird ne Chinesenseite erwähnt, die Excavator tolle Werte andichtet (ja die haben angeblich sogar schon Samples) und außerdem fabulieren die auch noch über Speculative Multithreading (der Witz wird langsam alt), als auch über ne "Wave-Cache-Architektur".
Für ein Bulldozerdesign halte ich das auch für Blödsinn, da das ne eigene ISA spezifiziert, die nichtmal dem von-Neumann Modell entspricht, wie man das auf ner x86-CPU integrieren soll, ist mir nicht klar, naja egal ziemlich sicher Fake, aber für ne GPU wärs vielleicht was. Paper gibts auch, liest sich schon recht "nett":

http://cseweb.ucsd.edu/users/swanson/papers/TOCSWaveScalarArch.pdf
(Thx@Complicated@P3D)

So ein Dataflow-Design bräuchte wohl v.a. große Caches, aber mit HMC wär das wohl auch kein Problem..

[Skysnake]

Moment, Moooment, ich schrieb doch:
Du hattest mir doch vorher erklärt, dass 32kb statt 16kB schon riesig viel bewegen würden, deswegen nahm ich an, dass Dir das gefällt. Also doch nicht, willst Du lieber L3 in MB-Slices, oder hattest Du die Passage falsch gelesen? Die restlichen Cacheerklärungen leuchten schon ein.

Ok, dann hatte ich dich falsch verstanden/schlecht gelesen.

Bei Caches gilt hat wie bei Hubraum "bigger is better" ;)
Man muss da auch immer die Stufen der Caches berücksichtigen. 16kB mehr L1 sind eventuell 100% mehr. Bei L2 sind es dann z.B. nur 10% mehr. Das ist schon entscheidend, weil der L1 ja auch mit einer viel höheren Bandbreite angebunden ist usw usw.

Je höher die Cachestufe, desto weniger bandbreite, und umso größer muss der Cache sein, weil ja schon in der Stufe drunter vieles abgefangen wird.

Ein L2 bringt ja z.B. NUR! etwas, wenn das Datenset größer als der L1, aber eben kleiner als der L2 ist. Sobald es auch größer als der L2 ist, bringt der Cache nichts mehr, da man sich diesen fortwährend flushed.

Auf GPUs berücksichtigt man die Cachegrößen immer direkt in den Algorithmen, weil man einfach so extrem an der Speicherbandbreite hängt. Ich hoffe es ist jetzt klar.

Bzgl Multithread sortieren:
Bucketsort (http://de.wikipedia.org/wiki/Bucketsort) ist da ein Ansatz ;)
Den Algorithmus kann man ziemlich einfach parallelisieren. Das "Problem" ist das Speichereffiziente schreiben in die buckets. Da muss man nämlich entweder mit Atomics/Mutex arbeiten, oder aber apriori die Ablage der Daten schon insoweit kennen, das man weiß, das man sich Daten nicht gegenseitig überschreiben kann. Letzteres ist halt relativ ineffizient bzgl Speicherverbrauch, aber eben die schnellste Möglichkeit. Je gutartiger die Verteilung der Daten, desto besser funktioniert das.

Bzgl. parallelen Sortieralgorithmen kann ich dir noch bitonisches Sortieren empfehlen. Als Anwendung gibt es dann Tritonsort. Das ist wenn ich mich richtig erinnere der aktuelle Spitzenreiter bei einem Sortierwettbewerb im TB-Bereich von Datensätzen.


Hast Du das aktuelle ct Prozessorgeflüster gelesen? Da wird ne Chinesenseite erwähnt, die Excavator tolle Werte andichtet (ja die haben angeblich sogar schon Samples) und außerdem fabulieren die auch noch über Speculative Multithreading (der Witz wird langsam alt), als auch über ne "Wave-Cache-Architektur".
Für ein Bulldozerdesign halte ich das auch für Blödsinn, da das ne eigene ISA spezifiziert, die nichtmal dem von-Neumann Modell entspricht, wie man das auf ner x86-CPU integrieren soll, ist mir nicht klar, naja egal ziemlich sicher Fake, aber für ne GPU wärs vielleicht was. Paper gibts auch, liest sich schon recht "nett":

http://cseweb.ucsd.edu/users/swanson/papers/TOCSWaveScalarArch.pdf
(Thx@Complicated@P3D)

Ne kenn ich nicht, schau ich mir mal bei Gelegenheit an. ;)


So ein Dataflow-Design bräuchte wohl v.a. große Caches, aber mit HMC wär das wohl auch kein Problem..
Muss ich mir wie gesagt erst mal anschauen bevor ich da was zu sagen kann :tongue:

[S940]

Danke für die Bucket und Tritonsortstichpunkte, da mach ich mich mal schlau :)
Ich gestehe: Noch nie gehört ^^
Muss ich mir wie gesagt erst mal anschauen bevor ich da was zu sagen kann :tongue:Hehe, ja ich habs auch noch nicht richtig von vorne nach hinten durchgelesen, lass Dir Zeit, hast Du Dir nach der letzten langen Antwort verdient ^^

Edit:
Hab für Wavecache nen eigenen Thread aufgemacht, wäre hier mMn zu sehr OT:
http://www.forum-3dcenter.org/vbulletin/images/3dc/insanedruid/misc/tag.png WaveCache-Architektur - paralleles Rechnen ohne vonNeumann (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=544916)

[Skysnake]

Hier die HP:http://tritonsort.eng.ucsd.edu/

TritonSort ist im Prinzip einfach nur ein paralleler verteilter(!) Bucketsort auf grundlage einer verteilten Datenbank/Filesystem. Eigentlich ist das nichts besonderes vom Ansatz her. Als wir Bucketsort in der Vorlesung Algorithmen & Datenstrukturen gemacht haben, ist mir auch sofort aufgefallen, dass sich der Algo sehr sehr sehr gut für (verteiltes) paralleles sortieren eignet. Der Knackpunkt bei Tritonsort, und wo man auch Hirmschmalz rein gesteckt hat ist auf der einen Seite das lesen/schreiben von Platte und der Speicherverbrauch. Die haben das so gut gemacht, dass Sie nur durch die maximale Lese/Schreibrate der Platte limitiert sind. Und die machen so so Tricks wie lesen/schreiben lieber außen auf der Platte als innen, weil die Bandbreite höher ist ;)

Ich hab mir mal überlegt, einen Bucketsort auf ner GPU zu implementieren, um zu sehen, wie weit man noch die Performance per Node, worum es in TritonSort ja auch ging, zu steigern. Das Ergebnis aus einigen Überschlagsrechnungen war, dass das I/O Problem auf "Platte", hier SSD, noch viel viel viel größer wird, einfach weil die GPUs so schnell sind, das man alles weg rotzt... Deswegen hatte ich eingeplant 1-2 PCI-E SSDs zu nehmen pro GPU, wobei man sagen muss, dass das dann die FusionIO Octal wären, weil man da mit 6/4GB/s lesen/schreiben kann. Sprich man nippelt am PCI-E Interface.

Eine Beispielkonfiguration einer 1 Node maschine sähe halt wie folgt aus: 2 SSDs (16x) Hauptdaten + 2 (8x) SSDs für Buffering + 2 (16x) GPUs + 2 SB-E/IB-E Xeons
Wenn man ein Multinode-System will dann halt noch an die Lanes des Chipsates die NICs.

Das ist jetzt aber unter der Prämisse, das man PCI-E 3.0 auch für die SSDs nutzt. Das ist aktuell nicht der Fall. Daher müsste man da einen PCI-E 3.0-2.1 Switch rein packen, damit man die volle Bandbreite bekommt. Wären dann halt jeweils doppelt so viele SSDs.

Kostenpunkt/Node mit den 8 PCI-E 2.0 SSD ~600.000€. Wobei man da das Problem hat, das man eigentlich zu wenig Speicher hat, um das Datenset zu fassen, das man eigentlich bearbeiten will :(

Ich glaub es ist aber nachvollziehbar, warum ich mich mit Sortierbenchmarks auf GPUs nicht weiter beschäftigt habe oder? Bischen teuer halt ;D

[Duplex]

Nächstes Jahr wird IBM´s neuer Power8 in "22nm SOI" hergestellt http://www.heise.de/newsticker/meldung/Hot-Chips-Power-Geschuetz-von-IBM-1943751.html
Vielleicht plant AMD mit diesem Prozess auch CPU & APUs auf Steamroller/Excavator Basis, Excavaor APU in 22nm ab Q4/2014?
Das der Prozess bereits nächstes Jahr bereit ist überrascht mich etwas, evtl. kommen die Chips aus den USA?

[S940]

Nächstes Jahr wird IBM´s neuer Power8 in "22nm SOI" hergestellt http://www.heise.de/newsticker/meldung/Hot-Chips-Power-Geschuetz-von-IBM-1943751.html
Vielleicht plant AMD mit diesem Prozess auch CPU & APUs auf Steamroller/Excavator Basis, Excavaor APU in 22nm ab Q4/2014?
Das der Prozess bereits nächstes Jahr bereit ist überrascht mich etwas, evtl. kommen die Chips aus den USA?
Natürlich kommen die Chips aus USA, aber AMD hat zukünftigen 22nm SHP-Prozessen abgeschworen, die Entwicklungszahlungen haben sie an GF eingestellt. Wohl kein Geld dafür übrig. Das war letztes Jahr in der Presse.
Witzig wärs jetzt natürlich, wenn sie IBM direkt mit der Fertigung beauftragen würden, die haben ja nen Anteil an der Fab in NY.

Aber dafür müssten sie wieder extra fürs WSA an GF zahlen ... blöd.

Wobei .. wenn die WSA-Ausnahmezahlungen an GF billiger wären, als die Entwicklungszahlungen damals an GF .. hmhm :freak:

Es geistert ja auch immer wieder ein 28SHP Prozess herum ... könnte auch sein, dass der recht ähnlich zu dem 22nm SHP ist. Hab immer noch keine Daten gefunden, aber der 22nm Prozess hat auf alle Fälle größere Maße als der 20nm Prozess bei GF.

[HarryHirsch]

Natürlich kommen die Chips aus USA, aber AMD hat zukünftigen 22nm SHP-Prozessen abgeschworen, die Entwicklungszahlungen haben sie an GF eingestellt. Wohl kein Geld dafür übrig. Das war letztes Jahr in der Presse.
Witzig wärs jetzt natürlich, wenn sie IBM direkt mit der Fertigung beauftragen würden, die haben ja nen Anteil an der Fab in NY.

Aber dafür müssten sie wieder extra fürs WSA an GF zahlen ... blöd.

Wobei .. wenn die WSA-Ausnahmezahlungen an GF billiger wären, als die Entwicklungszahlungen damals an GF .. hmhm :freak:

Es geistert ja auch immer wieder ein 28SHP Prozess herum ... könnte auch sein, dass der recht ähnlich zu dem 22nm SHP ist. Hab immer noch keine Daten gefunden, aber der 22nm Prozess hat auf alle Fälle größere Maße als der 20nm Prozess bei GF.

Witzig wäre es wenn sie nach Jahren mal wieder eine ordentliche CPU auf die Beine stellen. Aber wer erwartet schon was von AMD.

[S940]

Witzig wäre es wenn sie nach Jahren mal wieder eine ordentliche CPU auf die Beine stellen. Aber wer erwartet schon was von AMD.
Eben, das wär nicht witzig, das wär unfassbar :freak:

[2phil4u]

Diesen IBM Chip sollten sie mal für Desktop und Konsolen rausbringen, 12 Kerne, 8 Threads pro Kern müsst ihr Progger halt auf 96 Kerne optimieren ;)

Was für ein geiles Monster, haben will !

[ndrs]

Diesen IBM Chip sollten sie mal für Desktop und Konsolen rausbringen, 12 Kerne, 8 Threads pro Kern müsst ihr Progger halt auf 96 Kerne optimieren ;)

Was für ein geiles Monster, haben will !
Und x86 wird in Software emuliert, wa?

[2phil4u]

Wer braucht x86 ?

[seaFs]

Wer braucht x86 ?
Du erinnerst dich an das Itanium-Desaster?
Antwort auf deine Frage: Alle, die unoptimierten Code erzeugen.

[Skysnake]

Und alle, die bestehende x86 Software nutzen.

[ndrs]

Und alle, die bestehende x86 Software nutzen.
Eben jenes habe ich bei meinem Post vorrausgesetzt, als von phil das Stichwort "Desktop" kam.

[Skysnake]

Das sollte als Unterstützung gelten ;)

[Thunder99]

Es kommt auf die Verbreitung drauf an. Siehe was nun geproggt wird auf iOS und Android (ARM Basis)

[Skysnake]

Da gibt es aber keine Codebasis...

Daher ist die Ausgangsarchitektur auch fürn Arsch gewesen. Intel mit x86 tut sich da btw schon sehr schwer, weil man eben die ARM-Software NICHT! nutzen kann.

Im Desktop/Workstation/Server Umfeld sieht es da aber ganz ganz ganz! anders aus. Da gibt es UNMENGEN! an alter Software. Was glaubste, warum so manche Firma ihre asbach uralt MAinframes noch laufen lässt, oder komplett virtualisieren lässt? Ganz einfach, die Software neu zu entwickeln wäre ein zichfaches teurer als das Problem mit Hardware tot zu schlagen...

Softwaresupport ist ganz ganz ganz wichtig. Deswegen wird sich Power auch nicht im Desktop durchsetzen. Der Zug ist abgefahren.

[HOT]

Natürlich kommen die Chips aus USA, aber AMD hat zukünftigen 22nm SHP-Prozessen abgeschworen, die Entwicklungszahlungen haben sie an GF eingestellt. Wohl kein Geld dafür übrig. Das war letztes Jahr in der Presse.
Witzig wärs jetzt natürlich, wenn sie IBM direkt mit der Fertigung beauftragen würden, die haben ja nen Anteil an der Fab in NY.

Aber dafür müssten sie wieder extra fürs WSA an GF zahlen ... blöd.

Wobei .. wenn die WSA-Ausnahmezahlungen an GF billiger wären, als die Entwicklungszahlungen damals an GF .. hmhm :freak:

Es geistert ja auch immer wieder ein 28SHP Prozess herum ... könnte auch sein, dass der recht ähnlich zu dem 22nm SHP ist. Hab immer noch keine Daten gefunden, aber der 22nm Prozess hat auf alle Fälle größere Maße als der 20nm Prozess bei GF.

AMD hat ja seit 65nm keine eigene Fertigung mehr. Aber alle bisherigen High-End-Prozesse sind dennoch AMD-Entwicklungen, also 45nm und 32nm. Dann geisterten alle möglichen Prozesse auf GloFo-Folien durch die Landschaft und plötzlich Ende 2011 wollte AMD ab 2013 28nm Terramar und Sepang bringen - daraus wurde ja nichts. Aber ich denke schon, da der 28nm SHP ja wohl tatsächlich noch von AMD finanziert und entwickelt wurde, dass das dem ursprünglichen 22nm Prozess entspricht. Der Prozess muss ja seit spätestens 2008 auch in Entwicklung sein. Sowas dauert ja immer sehr lange. Die Koorperation mit IBM bestand meines Wissens auch die ganze Zeit. Es wär echt hilfreich, wenn man Daten hätte, mit denen man IBMs 22nm mit GloFos 28nm SHP vergleichen könnte. Sind die Daten gleich, ist der Fall klar. Der Verdacht liegt jedenfalls nahe, auch was die zeitliche Abfolge betrifft. AMD hat den Prozess seit 2013 am Laufen und IBM auch, wenn die in 2014 ihre Prozessoren bringen wollen.
Wirklich abgebrochen hat AMD die Entwicklung von 20nm SHP. Dieser ist ja lt. Rory Read komplett eingestellt worden. Das dürfte dann nach AMDs ursprünglicher Planung 16nm SOI sein. Nach 28nm SHP gibts nur noch Standardprozesse, ich vermute, dass man sich auch hier wieder an IBM ranhängen wird, die ja auch einen Nachfolgeprozess für 22nm SOI brauchen. Ich nehme an, IBM möchte 16nm ETSOI zum Nachfolgeprozess machen, der ja nahe an FDSOI dran ist (oder ist das sogar dasselbe?).

[Duplex]

Steht leider auf keiner Roadmap, neu ist nur Warsaw und der ist noch 32nm :(
Nachdem das Ding 12/16 Kerne bekommen wird, ist das ziemlich sicher nur wieder ein MCM aus 2 Quad-Dies.
Mit Glück werden es 20h Kerne oder der Stromverbrauch sinkt dankt RCM, mehr darf man nicht erwarten.
Die Roadmaps von AMD sollte man nicht ernst nehmen, wie oft wurde was angekündigt, verschoben oder gestrichen?

Ein dickes Riesendie mit 16 Kernen / 8 Modulen trau ich AMD nicht zu. AMD ist derzeit im Billigsparmodus und billig ist v.a. ne Orochi Rev. D.
Hat jemand tatsächlich geglaubt das man 8 Module auf einem DIE unterbringen kann? Würde nicht viel bringen weil der CPU Takt zu niedrig wäre, vor dem 14XM Prozess würde ich nicht auf solche Gedanken kommen, wenn man 16 Kerne haben will, dann auch mit moderaten Taktraten, damit man eine sehr gute skalierung erreichen kann.

In 28nm kann ich mir 10-12 Piledriver Kerne mit 3,5 Ghz Takt vorstellen, vorrausgesetzt der Prozess bringt ULK mit, was bei 32nm SOI nicht vorhanden sein soll, der Prozess muss überzeugen, ich denke nicht das man nur Kaveri Wafer in 28nm herstellen wird, möglich das man später größere DIEs entwicklen wird wenn man überzeugt ist das der Prozess Vorteile gegenüber 32nm SOI hat, man kann nicht ewig beim 32nm Prozess bleiben! IBM will nächstes Jahr die neuen Power Chips mit 22nm SOI Technik in Systemen einbauen, eig. müsste AMD schon längst 28nm PD Shrinks haben, was ist mit AMD nur los, der K8 wurde in 130, 90 & 65nm hergestellt?
Was sehen wir überhaupt noch für Fortschritte bei AMD? Ist AMD selber nicht zufrieden und wartet auf eine neue Fertigung in 2 Jahren und startet dann mit einer neuen Architektur? Eine neue Architektur soll doch langfristig nach oben skalieren, wenn ein neuer Prozess fertig steht, dann muss man doch das Design shrinken damit man mehr Kerne oder mehr Takt erreichen kann, die IPC selber wird AMD in den nächsten Jahren auf keinen fall mal eben 20, 30 oder 50% erhöhen können, Richland hat 20% mehr Takt als Deneb, ist aber nicht schneller.

[Knuddelbearli]

och 8 Modullerne auf einem DIE wären schon nett bei 2,5-3Ghz ist Bulldozer ja auch richtig schön effizient, aber für eine eigene Maske hat AMD im Serverbreich einfach zuwenig Marktanteile

[robbitop]

Bevor man so viele Module draufklatscht, sollten die Dinger per se erstmal etwas besser werden.

[StefanV]

Bevor man so viele Module draufklatscht, sollten die Dinger per se erstmal etwas besser werden.
So schlecht sind sie ja auch nun wieder nicht. Das Problem ist das enorme Delta zwischen Core und I/O Takt, der bei höheren Taktraten schon a bisserl am Bremsen ist...

Bei ~3GHz Core ist ja noch alles im Lot mit den 2GHz I/O (L3), bei 4GHz schauts aber schon etwas doof aus und bei 5GHz kann man den L3 auch schon fast abschalten...

AMD muss also 'nur' versuchen den L3 in Richtung Core Takt zu bringen, schon hat man teilweise 10-25% mehr Leistung...

[robbitop]

Naja verglichen mit den Intels ist man bei rund 50 % IPC Rückstand. Davon sollte man zunächst etwas aufholen.

[Knuddelbearli]

50%? Wo den bitte das?

mir fällt da eigentlich nur SC2 als Worstcase ein, und da scheint Blizzard allgemein was gegen AMD zu haben auch die GPUs haben da so ihre Probleme.
Aber dafür unterscheidet sich dort der Takt auch kaum, Intel bei dem 4770K bei 3,8-3,9Ghz, 8350 4,1-4,2GHz.
Dafür sind es bei zB BF3, als extrem in die andere Richtung, gerademal 15-20%

Das ist ja AMDs Problem obwohl sie eigentlich ein Design für höhere Taktraten haben sind ihre Frequenzen kaum über denen von Intel.

[robbitop]

Selbst schuld. Wer nach der P4 Geschichte noch an das Märchen der hohen Frequenzen geglaubt hat (als Designer!!) muss ziemlich naiv gewesen sein.
Wenn alle Kerne gut ausgelastet werden, geht es AMD etwas besser, weil man ja 8 Kerne hat (wenn auch nicht ganz 8 echte - aber schonmal "echter" als Intels 8 Threads). Aber pro Kern Leistung ist schon ziemlich übel. Leider. :(
Aber mal sehen, was Steamroller und Excavator bringen.

[Duplex]

50%? Wo den bitte das?
Dann vergleich mal ein i5-4670k (ohne Turbo) mit einem X4-965, merkste was?

[Ronny145]

50%? Wo den bitte das?



So ziemlich überall. In games sind 50% fast noch zu wenig.

[fondness]

Selbst schuld. Wer nach der P4 Geschichte noch an das Märchen der hohen Frequenzen geglaubt hat (als Designer!!) muss ziemlich naiv gewesen sein.


Der Fisch stinkt leider wie so oft vom Kopf her. Ruiz war gelinde gesagt eine Flasche der lange von den richtigen Entscheidungen Sanders profitiert hat.

[Duplex]

Und die Experten spekulieren bereits über einen Nachfolger mit 4 Integer Cluster pro Modul, Vorteil wäre das man Fläche sparen würde, aber das Singlethread Problem würde trotzdem nicht gelöst werden, mal sehen was in 2 Jahren kommen wird, das sind dann 4 Jahre nach BD, in der Zeit kann man auch eine neue Architektur entwickeln oder das Design radikal umbauen.
Intels Ansatz ist bisher die beste Lösung, sehr hohe IPC mit >4Ghz Turbo.
Ich bin mir sicher das Intel in 14nm 16 Kerne mit 4Ghz befeuern kann wenn man eine hohe TDP in kauf nimmt, das wäre für AMD das komplette ende was CPUs angeht!

[Locuza]

Selbst schuld. Wer nach der P4 Geschichte noch an das Märchen der hohen Frequenzen geglaubt hat (als Designer!!) muss ziemlich naiv gewesen sein.

Siehst du beim Bulldozer-Design einen irrhaften Glauben an "hohe Taktfrequenzen"?

Der Fisch stinkt leider wie so oft vom Kopf her. Ruiz war gelinde gesagt eine Flasche der lange von den richtigen Entscheidungen Sanders profitiert hat.
Sanders soll selber alles andere als finanziell richtige Entscheidungen getroffen haben.
Gut die Info stammt glaube ich auch von Ruiz Buch selber, aber ich denke einige Background Stories werden schon richtig gewesen sein.

[Badner1972]

Zeit wird es,auch wenn ich nicht wirklich daran glaube,das AMD einen performanten Nachfolger schon in der Schublade hat,der auf Augenhöhe mit den Topmodellen von Intel ist.Steamroller bzw. nachfolgend Excavator haben zudem ja noch den Fertigungsnachteil,da hat Intel einen signifikanten Vorteil,selbst wenn das Design an sich gut ist.
Ich würde auch zu nem AMD greifen,wenn der etwas langsamer ist,dafür aber P/L (wie üblich) stimmt.

[mironicus]

Intels Ansatz ist bisher die beste Lösung, sehr hohe IPC mit >4Ghz Turbo.
Ich bin mir sicher das Intel in 14nm 16 Kerne mit 4Ghz befeuern kann wenn man eine hohe TDP in kauf nimmt, das wäre für AMD das komplette ende was CPUs angeht!

Intel wird auch noch in 10 Jahren nur 4-Kerner für den (Mainstream) Desktop veröffentlichen, mit Die-Größen von 30-40 mm² und die TDP sinkt auf 15 Watt oder so. ;D

Mehr ist aufgrund der Konkurrenz-Situation nicht mehr notwendig. :freak:

[Knuddelbearli]

So ziemlich überall. In games sind 50% fast noch zu wenig.


dann zeig mal paar Beispiele bitte ...


In Spielen sind es -60% als absolutes Worstcase bei SC2 ( ok eventuell gibt es noch paar Indygames die das toppen ) bis -20% in BF3. Das meiste Bewegt sich bei -25 bis -40%.
-28% ist zB der Schnitt bei CB bei low Auflösung ( Ok deren Test ist Aufgrund 4:3 eigentlich fürn Arsch aber auf anderen Seiten sieht es nicht wirklich anders aus )

Klar ist imemr noch langsam aber man muss etwas nicht noch schlechter machen als es eh schon ist ^^

Nicht einfach nur daherlabern sondern auch mal nachrechnen bitte und Duplex was du auf einmal mit einem PhenomII willst weiß wohl nur du und Allah ...

[Ronny145]

dann zeig mal paar Beispiele bitte ...


http://www.forum-3dcenter.org/vbulletin/showthread.php?t=514281&page=3
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9810877&postcount=325
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9808411&postcount=310

Über 60%.

http://pclab.pl/art50000-20.html
http://pclab.pl/art50000-25.html
http://www.hardware.fr/medias/photos_news/00/42/IMG0042472.png
http://gamegpu.ru/images/stories/Test_GPU/Action/Saints%20Row%20IV/test/sr4%20proz.jpg


50% sind nichts besonderes. Die meisten testen nicht im CPU Limit inklusive CB.

[Duplex]

und Duplex was du auf einmal mit einem PhenomII willst weiß wohl nur du und Allah ...
Das heißt wenn man BD gegen Haswell vergleicht wird der IPC Abstand noch größer als Stars vs. Haswell, Intel hat locker 50-60% mehr IPC.
Ich schätze das AMD die IPC von Intel nicht erreichen kann, mit AMDs Ressourcen muss man mit ca. 8-10 Jahren entwicklungszeit rechnen.
AMD wird weiterhin auf Multicore Konzepte setzen, das heißt mehr Cluster, nur ist der Fertigungsprozess eine große Bremse für AMD, leider...

[Sonyfreak]

Gibt es eigentlich irgendwelche Prognosen, wann AMDs nächste Desktopgeneration auf den Markt kommen könnte? Ich hab irgendwo einmal Q1 2014 aufgeschnappt?

mfg.

Sonyfreak

[robbitop]

Der Fisch stinkt leider wie so oft vom Kopf her. Ruiz war gelinde gesagt eine Flasche der lange von den richtigen Entscheidungen Sanders profitiert hat.
Laut einer Story (RWT?? Anand?) war Sanders ebenfalls kein guter CEO. Da gibts ne schöne AMD Story. Der K7 saß halt gut und Intel war beim P4 anschließend schwach.

[fondness]

Laut einer Story (RWT?? Anand?) war Sanders ebenfalls kein guter CEO. Da gibts ne schöne AMD Story. Der K7 saß halt gut und Intel war beim P4 anschließend schwach.

Mag sein, dass es hierzu auch verschiedenen Meinungen gibt. Mit den Leuten mit denen Ich gesprochen habe sahen das halt so. Jedenfalls ging K7 und K8 ganz klar auf Sanders zurück.

[robbitop]

Sanders hat laut der Story die Kohle verhurt, wo es nur ging. Ob er technisch mit dem Design so viel zu tun hatte, wage ich zu bezweifeln. Damals waren Designs ungleich weniger komplex. Da konnte man schonmal etwas richtig gutes bringen, wie AMD den K7 und Intel den P6.

[HOT]

Bei Spielen (FPS-Messung) ist BD meist wirklich erheblich schlechter. Die IPC ist aber nicht 50% schlechter, das ist Blödsinn, sonst würden viele Renderprogramme usw. ebenfalls so stark hinterherhinken, das tun sie aber nicht. Ich denke ebenfalls, dass der Schuldige im I/O und L3$ zu finden ist bei Spielen (soviel zu IPC, Spiele profitieren kaum von der IPC) aber eben auch im fehlenden Trace-Cache und kleineren architektonischen Schwächen wie sie bei Version 1 eines Designs nunmal auftreten können. Es gibt aber kein Spiel (wird es auch in Zukunft nicht geben) wo ein 3 bis 4 Mobule BD zu langsam wäre. Von daher ist das Drama von Leuten, die die Hardware nicht in den Fingern hatten (z.B. Duplex) auch echt an den Haaren herbeigezogen.

[StefanV]

Das heißt wenn man BD gegen Haswell vergleicht wird der IPC Abstand noch größer als Stars vs. Haswell, Intel hat locker 50-60% mehr IPC.
Ich schätze das AMD die IPC von Intel nicht erreichen kann, mit AMDs Ressourcen muss man mit ca. 8-10 Jahren entwicklungszeit rechnen.
AMD wird weiterhin auf Multicore Konzepte setzen, das heißt mehr Cluster, nur ist der Fertigungsprozess eine große Bremse für AMD, leider...
Bist du dir sicher, dass es an der IPC liegt und nicht an der Cachearchitektur?

Lasst uns doch mal folgendes Versuchen: Wir nehmen 'nen Bulli, 'nen Haswell und 'nen Ivy Bridge, takten alle 3 schön brav auf 2GHz und schauen mal, wie wer abschneidet.

Ich würde drauf wetten, dass der Abstand vom Bulldozer zu den anderen deutlich geringer ist als bei 4GHz.

[Undertaker]

Bei Spielen (FPS-Messung) ist BD meist wirklich erheblich schlechter. Die IPC ist aber nicht 50% schlechter, das ist Blödsinn, sonst würden viele Renderprogramme usw. ebenfalls so stark hinterherhinken, das tun sie aber nicht.

Dafür braucht man sich nur einige Single-Thread-Benchmarks anzusehen oder SMT und CMT bei beiden Architekturen herauszurechnen. Das Bulldozer in gut parallelisierten Anwendungen besser als in Spielen mithält, liegt schlicht an der "Brute-Force" des Designs, dass heißt den 8 Integerkernen der Topmodelle. Die IPC, d.h. die Leistung pro Kern und Taktrate, ist bei Haswell dennoch rund 50-60 Prozent (http://www.computerbase.de/artikel/prozessoren/2013/sechs-haswell-mit-vier-kernen/12/) höher.


Ich denke ebenfalls, dass der Schuldige im I/O und L3$ zu finden ist bei Spielen (soviel zu IPC, Spiele profitieren kaum von der IPC) aber eben auch im fehlenden Trace-Cache und kleineren architektonischen Schwächen wie sie bei Version 1 eines Designs nunmal auftreten können.

Was soll das heißen, "kaum von der IPC profitieren"? IPC ist doch kein architektonisches Merkmal, sondern etwas, was sich in Summe aller Puzzleteilchen ergibt. Auch schnellere Caches können die IPC verbessern.

Bist du dir sicher, dass es an der IPC liegt und nicht an der Cachearchitektur?

Lasst uns doch mal folgendes Versuchen: Wir nehmen 'nen Bulli, 'nen Haswell und 'nen Ivy Bridge, takten alle 3 schön brav auf 2GHz und schauen mal, wie wer abschneidet.

Ich würde drauf wetten, dass der Abstand vom Bulldozer zu den anderen deutlich geringer ist als bei 4GHz.

Und was machst du mit den Caches, der Speicheranbindung usw.? Wenn du alles um 50 Prozent heruntertaktest, wird sich an den Relationen natürlich rein gar nichts ändern.

[Locuza]

Bei Spielen (FPS-Messung) ist BD meist wirklich erheblich schlechter. Die IPC ist aber nicht 50% schlechter, das ist Blödsinn, sonst würden viele Renderprogramme usw. ebenfalls so stark hinterherhinken, das tun sie aber nicht. Ich denke ebenfalls, dass der Schuldige im I/O und L3$ zu finden ist bei Spielen (soviel zu IPC, Spiele profitieren kaum von der IPC) aber eben auch im fehlenden Trace-Cache und kleineren architektonischen Schwächen wie sie bei Version 1 eines Designs nunmal auftreten können.
Nun was sagt IPC überhaupt aus? Instructions per Cycle.
Wenn ein Programm optimal auf die Architektur angepasst ist und eine passende Thread Anzahl generiert, dann ist für den ganzen Prozessor die IPC natürlich höher, als wenn ich ihm ein Single-Thread Programm vor die Füße werfe die üblen Programmcode verwendet.

Und wenn der schuldige der I/O und L3$ ist, dann wirkt sich das doch direkt auf die IPC aus, denn hier findet sich ein Flaschenhals der dazu führt, dass die CPU eben eine geringe IPC aufweist.

Die IPC ist doch eine grobe Zusammenfassung für den Durchsatz eines Prozessors, dass sieht von Anwendung zu Anwendung anders aus.
Ist doch ähnlich wie bei GPUs und Spielen, man kann einen Index erstellen, da hat man seinen Durchschnitt, aber gewisse Anwendungen und vor allem angepasste Anwendungen können dann völlig aus dem Rahmen fallen.

Aber das Intel bisher eine bis zu 50% höhere IPC hat oder gar mehr stimmt doch sogar, jedenfalls wenn man sich Spiele anschaut. Die IPC per Core kann man messen und da sieht es dann entsprechend schlecht aus für einen BD.
Spiele haben im Schnitt auch nur 2-4 Threads, entsprechend schwach steht BD insgesamt dar.

Bist du dir sicher, dass es an der IPC liegt und nicht an der Cachearchitektur?

Ist eine schlechte Cachearchitektur nicht Teil einer schwachen IPC?

Oder anders ausgedrückt, wenn jemand betrunken ist und ein Glas Bier, Wein und Vodka getrunken hat, bist du dir sicher das es nicht am Alkohol liegt, sondern am Wein?

[robbitop]

IPC ist doch, wie viele Instruktionen pro Takt rausgehauen werden können. Wenn bei Spielen dort Flaschenhälse wie Caches die IPC drücken, ist am Ende die IPC bei Spielen zu niedrig.

[Ronny145]

Bei Spielen (FPS-Messung) ist BD meist wirklich erheblich schlechter. Die IPC ist aber nicht 50% schlechter, das ist Blödsinn


Es ist die Realität. Haswell legt oft 15% drauf und dann ist es nur logisch, dass wir 50-60% sehen.


sonst würden viele Renderprogramme usw. ebenfalls so stark hinterherhinken, das tun sie aber nicht.

Wenn das Renderprogramm alle 8 kerne gut auslastet kann das IPC schwache Design ja noch halbwegs überdeckt werden. Wäre die IPC nicht derart schwach, würde der FX-8350 in den Programmen Kreise um Haswell ziehen. Das kann er nicht trotz höheren Takt und der doppelten Kernzahl.

[Knuddelbearli]

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=514281&page=3
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9810877&postcount=325
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9808411&postcount=310

Über 60%.

http://pclab.pl/art50000-20.html
http://pclab.pl/art50000-25.html
http://www.hardware.fr/medias/photos_news/00/42/IMG0042472.png
http://gamegpu.ru/images/stories/Test_GPU/Action/Saints%20Row%20IV/test/sr4%20proz.jpg


50% sind nichts besonderes. Die meisten testen nicht im CPU Limit inklusive CB.

ok Flight Simulator habe ich vergessen, ist ja bisl sehr exotisch lass das einfach mal darunter fallen was ich mit Indys meinte ^^
bei deinem pclab skyrim sind es nur knapp 50%

Wobei ich dem eh nicht traue 4770 gleich auf mit einem 4770k? und ebenso wie bei 4670 mit und ohne K auf den Komma genau die selben FPS? sieht eher nach Copy + Paste aus und beim 4770K haben sie vergessen das der 100Mhz mehr Takt als der ohne K hat ^^
Aber das mal außen vor.

Bei Anno sind es auch "nur" -40% und nicht 50%
Ebenso bei Saints Row da sind es auch -40% ( wobei es dort keinen 4770K gibt habe deshalb zwangsweise 2600K genommen )
( beide grob 66% der fps bei knapp 7% mehr Takt )

und CB ist wie gesagt 640*480 wenn das nicht cpu Limit sein soll was dann ...

Also fast nirgends -50% und das wo du dir überall die Worstcase rausgesucht hast in zig verschiedenen Sprachen ...
Das ist meilenweit weg von deinen behauptet fast überall ...


Wie gesagt einfach mal bitte selber Rechnen bevor man irgendwas behauptet ...

[Knuddelbearli]

Dafür braucht man sich nur einige Single-Thread-Benchmarks anzusehen oder SMT und CMT bei beiden Architekturen herauszurechnen. Das Bulldozer in gut parallelisierten Anwendungen besser als in Spielen mithält, liegt schlicht an der "Brute-Force" des Designs, dass heißt den 8 Integerkernen der Topmodelle. Die IPC, d.h. die Leistung pro Kern und Taktrate, ist bei Haswell dennoch rund 50-60 Prozent (http://www.computerbase.de/artikel/prozessoren/2013/sechs-haswell-mit-vier-kernen/12/) höher.


naja wenn man es bis zu Ende unterbricht ist es nichtmehr so bruteforce

AMD 8*2 ALUs
Haswell 4*4 ALUs

[boxleitnerb]

Ich glaube, normalerweise meint man "schneller als". 50% schneller als x ist natürlich was anderes als 50% langsamer als y. Bei Computerbase sind es taktbereinigt doch auch ungefähr 50%. Von dem her passen die Werte doch.

[Ronny145]

bei deinem pclab skyrim sind es nur knapp 50%


Es sind 62%. Dazu kommt noch der Taktunterschied, also eher so Richtung 70%.



Wobei ich dem eh nicht traue 4770 gleich auf mit einem 4770k? und ebenso wie bei 4670 mit und ohne K auf den Komma genau die selben FPS? sieht eher nach Copy + Paste aus und beim 4770K haben sie vergessen das der 100Mhz mehr Takt als der ohne K hat ^^
Aber das mal außen vor.

Bei gleichem Takt wenig überraschend.


Bei Anno sind es auch "nur" -40% und nicht 50%
Ebenso bei Saints Row da sind es auch -40% ( wobei es dort keinen 4770K gibt habe deshalb zwangsweise 2600K genommen )
( beide grob 66% der fps bei knapp 7% mehr Takt )

Anno2070= +51,5%
Saints Row= +50% (nur Sandy Bridge)

Dazu kommt ein 10-15% höherer Takt.


und CB ist wie gesagt 640*480 wenn das nicht cpu Limit sein soll was dann ...

4:3 Auflösungen reduzieren die CPU Last. 16:9 oder 16:10 sollte getestet werden.


Wie gesagt einfach mal bitte selber Rechnen bevor man irgendwas behauptet ...

Das habe ich getan und dich widerlegt. Deine Behauptung, dass SC2 der worst case wäre und nur dort 50% sichtbar wären, entspricht nicht der Wahrheit.

[Knuddelbearli]

hmm? Finde ich nicht, Basis ist ja Intel wenn man sagt 50% langsamer.

sonst müsste man sagen Intel ist 50% schneller. wurde aber von 50% Rückstand gesprochen. Zeigt aber auch das er sich mein Beispiel gar nicht angeguckt hat. Wiederspricht einem ohne mein beispiel überhaupt angeguckt zu haben das würde ich dann Fail / Troll nennen, und damit weiter Diskussion mit Ronny145 eh unsinnig.

Aber zumindest würde das es erklären. Würde mich trotzdem interessieren wie es richtig ist.

[Undertaker]

naja wenn man es bis zu Ende unterbricht ist es nichtmehr so bruteforce

AMD 8*2 ALUs
Haswell 4*4 ALUs

Brute Force bezogen auf die Kernzahl. Ein einzelner (Integer-) Kern ist für sich betrachtet natürlich weit weniger mächtig als bei Haswell. Darum ja auch der immense IPC-Unterschied und die viel kleineren Differenzen bei Multithreading. :)

[Ronny145]

hmm? Finde ich nicht, Basis ist ja Intel wenn man sagt 50% langsamer.


Deine Sichtweise dient eher der Schönrederei.



sonst müsste man sagen Intel ist 50% schneller.


Das sagt man auch. 50-60% höhere Taktleistung, 50% höhere IPC etc. hörst du zum ersten mal?

[Knuddelbearli]

Jup, aber man sollte das halt auch im Hinterkopf behalten. Deshalb ist es ihmo auch Bullshit³ zu sagen ein I7 ist ein 4 Kerner und der FX8 ein 8 Kerner und deshalb ist es nicht verwunderlich das bei Multithreaded der FX mithalten kann.
ist eben nicht die ganze Wahrheit, rein von der aller kleinsten Einheit unterscheidet sich haswell und Bulldozer nicht so. Nur irgenwie bekommt es AMD nicht hin die Leistung auf den Boden zu bekommen ( also Frond und backend )

[Knuddelbearli]

troll wo anders!
Es wurde gesagt:
verglichen mit den Intels ist man bei rund 50 % IPC Rückstand

und zumindest für mich ist da anzunehmen das Intel die Basis = 100% ist.
Habe auch gerade paar Leute gefragt die sehen das eigentlich alle so.
Intel 100% also AMD dann 50%.

Aber wie gesagt nicht mal meine Behauptung angucken sondern einfach nur aus Prinzip widersprechen ( sonst wäre es nie zu dem Missverständnis gekommen ) hat dich schon als Troll identifiziert

[Ronny145]

troll wo anders!
Es wurde gesagt:


und zumindest für mich ist da anzunehmen das Intel die Basis = 100% ist.
Habe auch gerade paar Leute gefragt die sehen das eigentlich alle so.
Intel 100% also AMD dann 50%.


50% Rückstand bedeutet es fehlen 50% an IPC auf Intel. Das hat er gesagt. Deine Schönrechner Sichtweise macht kein Sinn, denn dann müsste Bulldozer im Umkehrschluss 100% drauflegen um auf Gleichstand zu kommen. "Habe auch gerade paar Leute gefragt" klingt wenig vertrauenserweckend.

[Knuddelbearli]

und jetzt denk mal nach wieso ich dagegen Argumentiert habe? eben weill Bulldozer selbst im Worstcase nur sehr selten bis nie halb so langsam pro takt ist. Spezielle SC2 benchszenen sind da so ziemlich fast das einzige.

Aber du hast ja lieber ohne Sinn und Verstand dagegen gehalten ohne mein Argument ein einziges mal selber nachzurechnen den dann hättest es gesehn, Lieber wirfst du mir schönrechnerei usw vor ..

Troll bleibt Troll

[Duplex]

Du bist der Troll.
Viele AMDler wollen nicht wahr haben das der Rückstand zu Intel so groß ist.

[Knuddelbearli]

Ich bin nicht derjenige hier dem der andere ein Fehler unterstellen will ;-)
nach boxleitners Einwand war mir es ja klar das es vermutlich ein Missverständnis war, aber Ronny will mir ja umbeding Absicht unterstellen und Widerspricht mir ohne meine Aussage / Argument überhaupt angesehen zu haben
:facepalm:
Hauptsache er hat widersprochen
:freak:

Ach wie süß das Fanboy Argument nur doof das ich NV / Intel im System habe :P
Wird ja immer lustiger hier ;D

[Felixxz2]

Wenn Intel bei 100 und AMD bei 50 ist, ist doch Intel 100% schneller.....

AMD ist irgendwo bei 70 und dann ist Intel die passenden 50% schneller.

[Knuddelbearli]

jup
Versteh auch nicht wieso er das nicht einsehen will, ich sagte ja das AMD 66% der FPS hatte und er Argumentierte dann das Intel doch 50% schneller ist

Prozent rechnen ist eben eine Dirne ;-)


( beide grob 66% der fps bei knapp 7% mehr Takt )



Anno2070= +51,5%
Saints Row= +50% (nur Sandy Bridge)


und wenn man darauf Unterstellen will das man sich nur raus reden will, dann sollte man entweder Prozentrechnen lernen oder man trollt eben

[Ronny145]

Wenn Intel bei 100 und AMD bei 50 ist, ist doch Intel 100% schneller.....

AMD ist irgendwo bei 70 und dann ist Intel die passenden 50% schneller.


Genau deswegen, scheinbar kapiert er das nicht. Meine Links zeigen taktbereinigt überall 50+ IPC in games. Seine Argumentation ist total hinfällig.

[Knuddelbearli]

Einmal versuche ich es noch, dann darf es jemand anderes versuchen.

Basis = Intel = 100%
Intel ist 50 Prozentpunkte! schneller = doppelt soschnell da AMD dann bei 50%

Basis = AMD = 100%
Intel ist 50% schneller = 150%

Da im Satz mit den 50% nur Intel erwähnt wurde bin ich natürlich davon ausgegangen das ersteres gemeint ist da Intel dann die Basis = 100% darstellt

Wenn du nicht so zwanghaft versuchen würdest mir irgendwas zu unterstellen müsstest das doch selber sehen, habe es ja schon mal gequotet aber dann eben nochmal schön erklärt.

Ich sagte AMD hat 66% der Leistung Intel ist 35Prozenpunkte! dazu dann noch grob 300Mhz mehr ( 3,9 vs 4,2 GHz ) sind wir dabei das AMD 40% langsamer ist als Intel.

Du hast so gerechnet: Intel = 150% und AMD ist davon dann 50 Prozentpunkte = 33Prozent! ( wieder ohne Punkte ist wichtig! ) langsamer.

[Ronny145]

Von einer doppelten so hohen IPC war nie die Rede, sondern von 50%. Das kann doch echt nicht so schwer sein.



Du hast so gerechnet: Intel = 150% und AMD ist davon dann 50 Prozentpunkte = 33Prozent! ( wieder ohne Punkte ist wichtig! ) langsamer.


Nein das habe ich nicht. Richtig wäre AMD 100% und Intel 150%, ergo 50% mehr IPC. Beispiellinks wurden genannt, daraufhin wolltest du es schönrechnen.

[Knuddelbearli]

Wie kann man nur so engstirnig / verblendet sein? ...
deshalb ist ja mein SC2 Beispiel das vor deinem allerersten Post kam natürlich auch so wie alle meine danach gerechnet?

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9906177&postcount=1044
50%? Wo den bitte das?

mir fällt da eigentlich nur SC2 als Worstcase ein


http://www.pcgameshardware.de/Haswell-Codename-255592/Tests/Haswell-Test-Core-i7-4770K-Core-i5-4670K-Core-i5-4570-1071762/2/

32 vs 15 fps = mehr als doppelt soschnell

und inkl 3,9 vs 4,2 GHz kommt man dann auf -60% gegenüber Intel bei 100%
oder in deiner Sprechweise: Intel ist 150% schneller!

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9906288&postcount=1053
In Spielen sind es -60% als absolutes Worstcase bei SC2 ( ok eventuell gibt es noch paar Indygames die das toppen )


Jetzt unterstellst du mir als nächstes sicher das ich die Minus da reingeschummelt habe ^^ Mit deiner Rechenweise ( die nicht falsch ist aber eben anders ) ergibt das minus davor ja gar keinen Sinn.

Bleibt am Ende die selbe Aussage wie von Anfang an.
Wenn du nicht einfach um des Wiedersprechen willens widersprochen hättest, sondern zuerst mal geguckt hättest wie ich rechne bevor du behauptest ich erzähle quatsch, wäre das nicht passiert. Dank Boxleitnerb habe ich ja da schnell gesehen wieso wir da auf verschieden Ergebnisse kommen kA was du hast das du das nicht einsehen willst. vermutlich schlimmer Fall von Rechthaberei ...

[Ronny145]

Nochmals, von einer 100% beseren IPC war nie nie Rede.

[Knuddelbearli]

Tja nur doof das mein allererstes Beispiel sogar 150% schneller war. Wie gesagt hättest dir das mal angeschaut statt einfach zu widersprechen ...
und wie gesagt was für einen Sinn hättest sonst die Minus vor meine Prozentzahl gehabt?

und nach wie vor ist für mich ( und die paar Leute die ich gefragt habe ) das einleuchtenste das bei dieser Aussage
Naja verglichen mit den Intels ist man bei rund 50 % IPC Rückstand
Intel = 100% ist.
Wenn es 150% ist woher soll man wissen ob nicht 250% 300% usw gemeint ist? es wurde nur Intel erwähnt, also war für mich Intel natürlich 100%.
kann man natürlich anders sehen, deshalb habe ich danach in der Erklärung extra von Prozentpunkten geschrieben, darum geht es nicht sondern um deine lächerlichen Unterstellungen

[Ronny145]

Lustig wie du seine Aussage mit dem Weglassen eines Wortes entstellst.

Naja verglichen mit den Intels ist man bei rund 50 % IPC Rückstand.


Wenn Intel 50% höher liegt fehlen AMD die 50%. Wenn du einen 100% IPC Vorteil daraus ableitest, hast du das falsch verstanden.

[Knuddelbearli]

Ist absolut 0 Unterschied 50 auf 100% sind auch 50 Prozentpunkte. Und das Wort hat es nur beim kopieren abgeschnitten, war keine Absicht.

Wie gesagt guck bei Wiki einfach mal nach was der Unterschied zwischen Prozent und Prozentpunkt ist. Ist halt doof das für beide das Zeichen % steht.

Wenn jetzt Intel ( da nur die in dem Quote erwähnt ist ) nicht 100%, sondern 150%, ist wieso kann das nicht auch 200% 250% 300% usw sein?

Beide Sätze sind richtig wenn AMD die halbe IPC von Intel hat und Intel 100% ist:
Intel ist 50% schneller als AMD
Intel ist 100% schneller als AMD

ausgeschrieben ist es aber
Intel ist 50 Prozentpunkte schneller als AMD
Intel ist 100 Prozent schneller als AMD

oder wenn Intel 150% ist
AMD ist 50% langsamer als Intel
AMD ist 33% langsamer als Intel

AMD ist 50 Prozenpunkte langsamer als Intel
AMD ist 33 Prozent langsamer als Intel

[ndrs]

Leute, mittlerweile ist doch klar, wie es gemeint war. Wer irgendwann mal was gesagt hatte ist damit doch hinfällig. Könnt ihr diese elendige Rechthaberei nicht beenden/per PM weiterführen? Wir haben jetzt schon drei Seiten ohne relevanten Inhalt.

[robbitop]

Es ist schon traurig, wie rückständig das Verständnis einfacher Schulmathematik und das Aufnehmen einfacher Aussagen ist. Braucht man nichts weiter zu zu sagen.
Ich wollte eine Größenordnung darlegen und nicht in eine völlig sinnfreie OT Diskussion münden lassen. Sorry aber: :facepalm:

[Badner1972]

Schon lustig wie es hier zuweilen zugeht...seid doch friedlich,letztlich ist dieses rumreiten auf einigen % doch pille palle..wir wissen alle das Intel gerade in Spielen deutlich schneller ist,AMD mit Piledriver im vgl. zum Bulli etwas Leistung gewonnen hat. JE nach Workload ist AMD gar nicht so schlecht,je mehr (Integer)Kerne ausgelastet werden,desto besser.
Vom Stromhunger reden wir dabei besser nicht,wobei im Idle AMD gar nicht so übel ist.

Doch der eigentliche Grund dieses Threads..gibts was neues ?

[Duplex]

seid doch friedlich,letztlich ist dieses rumreiten auf einigen % doch pille palle..

JE nach Workload ist AMD gar nicht so schlecht,je mehr (Integer)Kerne ausgelastet werden,desto besser.

http://www.computerbase.de/artikel/prozessoren/2013/intel-core-i7-4960x-im-test/
http://abload.de/thumb/13jzhm.jpg (http://abload.de/image.php?img=13jzhm.jpg) http://abload.de/thumb/2caykv.jpg (http://abload.de/image.php?img=2caykv.jpg) http://abload.de/thumb/3abao4.jpg (http://abload.de/image.php?img=3abao4.jpg) http://abload.de/thumb/498l2w.jpg (http://abload.de/image.php?img=498l2w.jpg) http://abload.de/thumb/5f0ldw.jpg (http://abload.de/image.php?img=5f0ldw.jpg)

Intels Top Modell hat 2 Kerne weniger als AMD,
SMT bringt 20-25% Speedup.
Von daher ist es richtig wenn man sagt das Intel 50-60% mehr IPC als AMD hat.
Der AMD taktet sogar 400Mhz höher als Intels Top Modell in Multithreading.

Wenn AMD druck machen will, dann brauchen Sie 6 Module / 12 Kerne mit 4,5Ghz Takt + 20% mehr IPC, vielleicht schafft es der Excavator mit dem 14XM Prozess.

[robbitop]

Und was soll das bringen? Fast keine Consumeranwendung profitiert von so vielen Kernen. Die Kerne, die da sind, müssen effizienter werden.

[Thunder99]

Da helfen auch die neuen Konsolen wenig.

Siehe wie ein i3 mit SMT einen 2-4 Moduler in Spielen platt macht oder sehr nahe ran kommt :( AMD muss mehr IPC erreichen, da helfen auch nicht mehr Kerne

Quelle: http://www.computerbase.de/artikel/prozessoren/2013/haswell-als-dual-core-im-test/5/

[Duplex]

@robbitop
Und wie willst du die Kerne deutlich effizienter machen, z.b. 30-50%?
Was ist wenn Steamroller nur 15% mehr IPC als Piledriver hat und Excavator nur 10% auf Steamroller drauflegen wird? Dann hätten wir immer noch das gleiche Problem wie jetzt.
Die Architektur ist auf Multithreading und hohen Takt ausgelegt, mit Intels 22nm Prozess könnte AMD bei 125W bestimmt 6Ghz Takt erreichen, die Fertigung von Globalfoundries ist für AMD eine große Bremse.
AMD wird bestimmt gezwungen sein mehr Cluster im Modul einzubauen, das spart Fläche und wird die günstigste Möglichkeit sein die Skalierung nach oben auszubauen, nicht vergessen bei der Fertigung gibt es zwischen Intel & GF einen Riesen Abstand, Anfang nächsten Jahres läuft bereits die 14nm Massenfertigung für Broadwell bei Intel, in 1 Jahr sogar die Massenfertigung von Skylake damit man Anfang 2015 ausliefern kann.

[reaperrr]

Die Architektur ist auf Multithreading und hohen Takt ausgelegt, mit Intels 22nm Prozess könnte AMD bei 125W bestimmt 6Ghz Takt erreichen, die Fertigung von Globalfoundries ist für AMD eine große Bremse.
Jein.

Auch Intel's 22nm-Prozess braucht unverhältnismäßig viel Spannung um Taktraten oberhalb von 4,5 GHz zu erreichen.
Vishera in Intel's 22nm wäre sicherlich deutlich stromsparender bei gleichem Takt durch den kleineren Die, aber ein Plus von mehr als ~500 MHz in Massenproduktion würde es vermutlich hitzebedingt nicht geben (kleinere Fläche -> schlechtere Wärmeabfuhr, siehe auch SB->IB/HSW als Beispiel).

[Duplex]

Wenn ULK bei 28nm eingesetzt wird, dann rechne ich mit 5-6 Modulen.
In 45nm konnte man wegen ULK 50% mehr Kerne bei gleichem Takt einbauen, der 32nm Prozess soll kein ULK besitzen, da gibt es also noch Spielraum.

[fondness]

Auch Intel's 22nm-Prozess braucht unverhältnismäßig viel Spannung um Taktraten oberhalb von 4,5 GHz zu erreichen.


Bitte nicht alles in einen Topf werfen. Nicht der Prozess benötigt für einen bestimmten Takt viel oder wenig Spannung, das hängt immer auch vom Design an.
Von Haswell kann man bestimmt keine Rückschlüsse auf Bulldozer schließen.

[Schaffe89]

Nochmals, von einer 100% beseren IPC war nie nie Rede.

Es ist sowieso Käse von einer Spiele IPC zu reden. Warum Intel so flott ist liegt in SC2 an der Speicherbandbreite und am l3 und nicht an der IPC.

Mit Anwendungen kann man da schon eher was anfangen und da kommt AMD pro Takt teils sehr nahe ran, wenn die Bedingungen stimmen.

[Undertaker]

Es ist sowieso Käse von einer Spiele IPC zu reden. Warum Intel so flott ist liegt in SC2 an der Speicherbandbreite und am l3 und nicht an der IPC.

Ich stelle mal die gewagte Behauptung auf, dass die Speicherbandbreite so ziemlich egal ist. Ich denke nicht, dass Haswell mit Single-Channel großartig Leistung verlieren würde.

Natürlich ist die IPC der Grund für die gute Leistung in SC2. Anders als in sonstigen Spielen, die besser parallelisiert sind, kann hier der IPC-Nachteil der aktuellen AMD-Modelle nicht durch höhere Kernzahlen egalisiert werden -> ergo die großen Leistungsdifferenzen. OK, was auch noch hinzukommt, ist das SC2 Haswell augenscheinlich besonders gut liegt, weil es sehr stark von schnellen Caches profitiert. Und die Geschwindigkeit der Caches ist natürlich ein Faktor für die IPC, von Quatsch kann also keine Rede sein.

[reaperrr]

Bitte nicht alles in einen Topf werfen. Nicht der Prozess benötigt für einen bestimmten Takt viel oder wenig Spannung, das hängt immer auch vom Design an.
Von Haswell kann man bestimmt keine Rückschlüsse auf Bulldozer schließen.
Ich weiß, war falsch formuliert. Durchaus möglich, dass BD/PD im gleichen Prozess für den gleichen Takt weniger Spannung bräuchte.
An meiner Meinung, dass sich BD/PD in Intels Prozess nicht so viel höher als Intels eigene CPUs takten lassen würde, wie einige scheinbar glauben, halte ich aber fest. Es würde vielleicht reichen, um einen FX-9590 in der 125W-TDP eines normalen 8350 unterzubringen, viel mehr aber wohl nicht. 6 GHz halte ich für utopisch.

Genau genommen wollte ich ja gerade darauf hinaus, dass es meiner Meinung nach eben nicht am Prozess, sondern hauptsächlich am Design hängt. Ein Design auf hohen Takt bei eher schwacher IPC auszulegen war angesichts der zunehmenden Skalierungsprobleme bei neuen Prozessen einfach hochgradig unklug seitens der für BD zuständigen Lead-Designer.

BD/PD braucht einfach viel zu viel Takt und Fläche/Transistoren für seine Leistung, unabhängig vom Prozess. Und diese Mischung würde auch in jedem anderen Prozess zu vergleichsweise hohem Stromverbrauch führen.

GF's 32nm ist inzwischen sowieso längst nicht mehr so schlecht, wie er gern gemacht wird. Vergleicht mal Fläche, Taktraten und Stromverbrauch von einem A10-6700 mit einem SB i7-2600K.

[Skysnake]

Ich stelle mal die gewagte Behauptung auf, dass die Speicherbandbreite so ziemlich egal ist. Ich denke nicht, dass Haswell mit Single-Channel großartig Leistung verlieren würde.

Natürlich ist die IPC der Grund für die gute Leistung in SC2. Anders als in sonstigen Spielen, die besser parallelisiert sind, kann hier der IPC-Nachteil der aktuellen AMD-Modelle nicht durch höhere Kernzahlen egalisiert werden -> ergo die großen Leistungsdifferenzen. OK, was auch noch hinzukommt, ist das SC2 Haswell augenscheinlich besonders gut liegt, weil es sehr stark von schnellen Caches profitiert. Und die Geschwindigkeit der Caches ist natürlich ein Faktor für die IPC, von Quatsch kann also keine Rede sein.
Seh ich im Großen und Ganzen auch so, wobei ich mich immer frage, warum sich die Leute an SC2 so aufgeilen....

Das Game ist meiner Meinung nach einfach grottig programmiert bzgl der Engine. Wenn ich solche Dropdowns habe, das ich selbst auf High-Endhardware zu solch niedrigen FPS komme, dann muss ich mich schon fragen, ob ich nicht irgendwas falsch gemacht habe. Vor allem wenn ich Multicore offensichtlich nicht wirklich nutze... Activision-Blizzard macht da auf mich immer den Eindruck, als ob es ihnen darum geht, möglichst wenig Geld in die Entwicklung zu stecken. Hauptsache es läuft... Wie ist erstmal scheis egal. Wenns einem zu langsam ist, soll er sich halt nen neuen Rechner kaufen... :down:

[2phil4u]

Auf Computerbase gibt es Neuigkeiten zu AMDs Plänen für 2014.

http://www.computerbase.de/news/2013-09/amd-mit-steamroller-jaguar-plus-und-arm-fuer-embedded-systeme/

[Duplex]

Auf Computerbase gibt es Neuigkeiten zu AMDs Plänen für 2014.

http://www.computerbase.de/news/2013-09/amd-mit-steamroller-jaguar-plus-und-arm-fuer-embedded-systeme/
Nichts neues oder interessantes dabei, interessant wäre nur ne Server/Desktop Roadmap mit großen SR Modellen.

[Ronny145]

You know, I just saw an AMD roadmap today, and it's clear that they're giving up at the high end. 28nm Kaveri rolls out in 2014, 28nm Excavator in 2015.

No successor to Vishera on the roadmap that I saw. Just blank space for the ultra high end for 2015...
http://investorshub.advfn.com/boards/read_msg.aspx?message_id=91844647


AMD will doch nicht ernsthaft die 2015 Generation noch in 28nm bringen.

[maximus_hertus]

Wenn GF und Co. keinen 20nm Prozess anbieten können? Dann bleibt halt nur 28nm...

[Dunkeltier]

Intel rollt in 2015 voraussichtlich mit den Broadwell in 14nm an. Ist doch ein Witz, was AMD da zustande bringt. Also muss AMD massig Low-End und Mainstream verkaufen, um auf genügend Umsatz und auch Gewinn zu kommen. Wenn sie schon nicht mehr in margenträchtigen High-End Markt mitmischen können.

[Ronny145]

Wenn GF und Co. keinen 20nm Prozess anbieten können? Dann bleibt halt nur 28nm...


TSMC sollte spätestens ab H2 2014 20nm liefern können. Bei GF weiß ich es gerade die nicht, die kündigen immer viel an, wie die Realität bei denen aussieht ist schwer zu sagen.


Intel rollt in 2015 voraussichtlich mit den Broadwell in 14nm an.


Broadwell startet in H2 2014, mit Skylake sollte jedes Segment mit 14nm ausgestattet sein abgesehen vom Highend Server Bereich. Dazwischen liegt Airmont.

[Knuddelbearli]

Was sollen sie sonst tun wenn eben kein passender Prozess verfügbar ist? Darfst uns natürlich gerne erleuchten ^^

[Ronny145]

Was sollen sie sonst tun wenn eben kein passender Prozess verfügbar ist?


Wer sagt, dass kein passender Prozess verfügbar ist? Bei TSMC ist gar keine Frage, ob die 2015 20nm verfügbar haben.

[S940]

AMD will doch nicht ernsthaft die 2015 Generation noch in 28nm bringen.
Ich vermute schon länger, dass Excavator nur ein Steamroller-Aufguss a la Piledriver (von Bulldozer) ist, quasi nur ne neue Revision. Würde dann dazu passen.

Als der AMD-Chef damals beim SHP-Streichen von weniger Metall-Lagen sprach, dachte ich mir schon, ob er damit nicht meint, dass BD weg vom Fenster ist ...
Bekanntlich hat AMD auch den 20SHP-Prozess gestrichen. Entweder, da sie auf Bulk wechseln, oder weil sie die komplette Linie einstampfen.
Wenn GF und Co. keinen 20nm Prozess anbieten können? Dann bleibt halt nur 28nm...
Bulk gibts doch ... sogar in allen möglichen Varianten. Normal mit Finfets oder mit FDSOI. Die Auswahl ist breit genug ..

[HOT]

http://investorshub.advfn.com/boards/read_msg.aspx?message_id=91844647


AMD will doch nicht ernsthaft die 2015 Generation noch in 28nm bringen.
Klar kommt Carizo noch in 28"nm". Der Wechsel findet doch jetzt erst statt und ist ja offenbar ein zu groß geratener 22nm-Prozess aufgrund des physikalischen Grenznutzen von PDSOI. Das ist aber nicht so dramatisch wenn der Prozess wirklich leistungsfähig ist. Die Jaguars und ARMs werden sicherlich in 2015 auf 20nm geshrinkt, aber die großen garantiert nicht. Nach 28nm SHP wird man sicherlich den folgenden IBMs "FD"SOI-Prozess für große CPUs einfach kostenpflichtig mitnutzen, da IBM seine Prozesse ja eh nach GloFo bringt. AMD entwickelt nur keine eigenen Prozesse mehr, ist ja auch gar nicht nötig. Gibt also keinen Grund schwarz zu sehen, weder für Dickschiffe noch für die Leistungsfähigkeit der Prozesse.

[Knuddelbearli]

Wer sagt, dass kein passender Prozess verfügbar ist? Bei TSMC ist gar keine Frage, ob die 2015 20nm verfügbar haben.


Nur hat AMD leider Verträge mit GloFo

[Trap]

Was sollen sie sonst tun wenn eben kein passender Prozess verfügbar ist?
Vielleicht mal bei Intel fragen, ob die nicht einen guten Bulldozer für AMD produzieren können ;D

[S940]

Zwar schon erwartet gewesen, aber jetzt 100% sicher:
Excavator mit AVX2 | Planet 3DNow! (http://www.planet3dnow.de/cms/4471-excavator-mit-avx2/).

[fondness]

Ich halte es für einen gewaltigen Luxus, dass AMD diese großen Cores weiterhin weiterentwickelt, obwohl man offenbar die Server- und Enthusiasten-Schiene gestrichen hat. Wenn man die Cores schon hat, sollte es doch kaum mehr einen Aufwand darstellen entsprechende FX-CPUs zu bauen....

[S940]

Ich halte es für einen gewaltigen Luxus, dass AMD diese großen Cores weiterhin weiterentwickelt, obwohl man offenbar die Server- und Enthusiasten-Schiene gestrichen hat. Wenn man die Cores schon hat, sollte es doch kaum mehr einen Aufwand darstellen entsprechende FX-CPUs zu bauen....

Tja .. da hängt dann halt ein Rattenschwanz dran. Was natürlich ginge wär ein Upgrade für AM3+ und G34, aber mal ehrlich .. 2014 und kein Onboard-PCIe bzw. PCIe3?

Da bräuchte man dann ne neue Serverplattform, aber die hat AMD anscheinend schon 2x gestrichen. Ergo kommt da nix mehr.

Ein FX allein für FM2+ rentierte sich aber leider nicht, AMDs Marktanteil ist einfach zu klein, ohne Zweit- bzw. Erstverwertung in Servern kann mans vergessen.

Deswegen also keine FX.

So "neu" wird Excavator wahrscheinlich auch gar nicht sein. Das wird das gleiche Spielchen wie bei Bulldozer -> Piledriver. Neue Revision und fertig. Vermutlich hat Kaveri schon AVX2 implementiert, dass dann getestet und bei Corriza freigeschaltet wird. War mit FMA3 ja genauso.

[Locuza]

Neue Revision und fertig. Vermutlich hat Kaveri schon AVX2 implementiert, dass dann getestet und bei Corriza freigeschaltet wird. War mit FMA3 ja genauso.
Müsste AMD dann nicht am besten auch die Cache-Bandbreiten verdoppeln?

[Akkarin]

You know, I just saw an AMD roadmap today, and it's clear that they're giving up at the high end. 28nm Kaveri rolls out in 2014, 28nm Excavator in 2015.

No successor to Vishera on the roadmap that I saw. Just blank space for the ultra high end for 2015...

Das macht doch keinen sinn. Exavator ist doch wie Bulldozer/Piledriver und Steamroller name der arch. Ob man daraus jetzt visheras oder trinitys baut, bzw. die "neuen" Namen hat doch damit nichts zu tun.

[Locuza]

Das macht doch keinen sinn. Exavator ist doch wie Bulldozer/Piledriver und Steamroller name der arch. Ob man daraus jetzt visheras oder trinitys baut, bzw. die "neuen" Namen hat doch damit nichts zu tun.
Da steht doch das er meint, dass AMD das High-End Segment aufgibt.
Excavator soll mit 28nm daher kommen, was eben nicht aggressiv erscheint, wenn Intel während der Zeit schon mit 14nm antanzt.
Einen Vishera Nachfolger gibt es auch nicht, also baut AMD wohl auch keine CPUs mit mehr als 2 oder 3 Excavator Modulen.

[Duplex]

So "neu" wird Excavator wahrscheinlich auch gar nicht sein. Das wird das gleiche Spielchen wie bei Bulldozer -> Piledriver. Neue Revision und fertig.
Das wäre sehr langweilig und nicht gut für den Markt :(

Meine Vorstellung wäre sowas hier.

32KB L1D Cache (8-way, Load 64 Bytes+Store 64 Bytes)
4MB L2 Cache (included, 512k 8-way)
8MB L3 Cache (shared)
Uop Cache/Trache Cache
256 Bit FPU/ 2 FPUs pro Modul
30% mehr IPC als Piledriver

[S940]

Müsste AMD dann nicht am besten auch die Cache-Bandbreiten verdoppeln?
Nö, ist doch schon alles für 256bit FMA ausgelegt, das passt schon, AVX2 legt da nichts nach.

[AnarchX]

Carrizo mit Excavator-Kernen, weiterhin mit DDR3 im FM2+: http://semiaccurate.com/forums/showpost.php?p=201197&postcount=1856

[Duplex]

Total uninteressant, die Mehrheit kauft 2015 Skylake mit Gen9 GPU und wer Tablets braucht greift dann zu den Silvermont Nachfolger in 14nm.

[OBrian]

Carrizo mit Excavator-Kernen, weiterhin mit DDR3 im FM2+: http://semiaccurate.com/forums/showpost.php?p=201197&postcount=1856
wundert mich, daß da nichts von DDR4 steht, denn so langsam müßte das dann ja in den Markt kommen. 2014 mit Intel-Servern, dann 2015 sicher auch für normale Leute, und AMD sollte doch eigentlich möglichst zügig dabei sein, die APUs brauchen ja Bandbreite.

Aber kann auch einfach sein, daß das zeitlich noch nicht so klar ist und einfach auf der Folie hier weggelassen wird. DDR4 soll ja schon seit Jahren "bald" kommen. Jedenfalls werden sie einen neuen Sockel einführen müssen, der dann längere Zeit mit dem alten parallel laufen wird. Es kann also sein, daß FM2+ noch 2016 deutliche Umsätze generiert, obwohl dann z.B. Mitte 2015 bereits ein FM3 (oder wie auch immer) eingeführt wurde.

[HOT]

DDR4 gibts erst mit einer komplett neuen Plattform. Und die ist erst bei den in 14XM gefertigten CPUs (SoCs?) zu erwarten. Das wird dann auch das Ende von PGA-Sockeln sein bei AMD. Sieh es so: FM2+ und 28nm SHP sind die letzten Ausläufer vom alten Unternehmen AMD, alles danach kommt ist das neue Unternehmen AMD denn die ersten Entwicklungen aus der Read-Ära werden dann fertig, Carrizo ist die letzte CPU, deren Entwicklung noch in der Meyer-Ära entschieden wurde. Read hat den Sockel2012, der G34 ablösen sollte, damals abgebrochen und den Servermarkt auf APUs konzentriert. Die Ergebnisse dieser Entscheidung sieht man hier:
http://www.planet3dnow.de/cms/5433-apu13-amd-baut-software-oekosystem-fuer-opteron-zukunft-mit-apus-auf/
Was man jetzt noch braucht ist eine APU, die HPC-fähig ist, deren Entwicklung dauert aber seine Zeit. Sowas wird dann auch gleich auf FinFETs entwickelt, kann also erst mit 14XM auf den Markt kommen. Praktischerweise mit einem DDR4-Sockel (LGA), damit das auch möglichst lange hält.

[robbitop]

Mit Plattform meinst du Architektur? Eigentlich ist doch der Speichercontroller und die Art des Sockels unabhängig davon, oder?

[fondness]

Die Roadmap ist jedenfalls an Langeweile nicht zu überbieten. Im High-End auch 2015 nichts neues, es bleibt beim 32nm Vishera. Intel wird 2015 längst durchgehend in 14nm FinFET fertigen. Kaveri bekommt einen Nachfolger mit Excavator-Kernen und neuer Grafik klar, dazu etwas niedrigere TDP, weiterhin DDR3 - da wird nicht viel Leistung bei rum kommen. Höchstens auf bessere Perf/Watt kann man hoffen. Selbst Beema hat keinen Nachfolger 2015.

Interessant wird es bei AMD erst 2016. Dann kommt wohl die angekündige "neue" Architektur wo Jim Keller einen Angriff auf das High-End versprochen hat. Mal sehen. Schief gehen sollte das jedenfalls nicht. 2015 dürfte ein hartes Jahr für AMD werden, wenn nicht gerade die GPU-Sparte oder die Konsolen-Deals die Kohlen aus dem Feuer holen.

[HOT]

Mit Plattform meinst du Architektur? Eigentlich ist doch der Speichercontroller und die Art des Sockels unabhängig davon, oder?
:freak:
Natürlich ist die Plattform nicht unabhängig vom Speichertyp, es sei denn, man legt sie direkt als Kombiplattform aus... FM3+ ist aber eine reine DDR3-Plattform, also braucht man für DDR4 logischerweise eine neue...
Auch die Architektur muss DDR4 unterstützen. Da Carrizo aber einfach ein Kaveri (GCN1.1) mit Excavator-Modulen sein wird, bleibt also auch DDR3. In 2015/16 braucht man alles neu.
Also:
- Neuer LGA-Sockel für Desktop und Server (wird nur noch einen einzigen geben mMn)
- Plattform und APU mit reinem DDR4-Controller (keine DDR3-Unterstützung aber mit Reg/ECC-Support)
- gefertigt in "14nm FinFETs" bei GloFo (20nm GateFirst FinFET-Prozess, dank GF nicht so viel größer als Intels 14nm GL)
- neue µArchitektur, x86-kompatibel aber auf HSA-Basis, Post-BD-Ära bricht an

Das war garantiert eine der ersten Entscheidungen, die Rory Read bei Amtsantritt gefällt hat. Aber bis es soweit ist, muss man auf GCN setzen und CPU-technisch mit der alten Scheisse leben...

[Undertaker]

Selbst Beema hat keinen Nachfolger 2015.

Was nicht auf der Roadmap steht, muss ja nicht zwangsläufig nicht existent sein... ;) Gerade bei Beema könnte ich mir sehr gut einen 20nm-Nachfolger für Anfang/Mitte 2015 vorstellen.

[OBrian]

Da Carrizo aber einfach ein Kaveri (GCN1.1) mit Excavator-Modulen sein wird, bleibt also auch DDR3.Das kann so sein (nehme ich auch an), aber die logische Folgerung in dem Satz stimmt nicht. CPU und GPU sind doch unabhängig vom verbauten Speichercontroller, das sind alles austauschbare Bauteile ohne Abhängigkeiten. Sie könnten also auch, falls gewünscht, nur den Speichercontroller tauschen gegen einen für DDR4 oder sonstwas und den Rest gleich lassen. Nur da ja von Excavator geredet wird, wird an dem CPU-Teil sicher was gemacht - was sie aber sonst noch ändern, ist unklar. Kann durchaus sein, daß sie einen Kombicontroller einbauen (falls möglich), um dann flexibler zu sein (d.h. gleiches Die in unterschiedliche Packages bauen und fertig).

[HOT]

Was nicht auf der Roadmap steht, muss ja nicht zwangsläufig nicht existent sein... ;) Gerade bei Beema könnte ich mir sehr gut einen 20nm-Nachfolger für Anfang/Mitte 2015 vorstellen.
Jo das denke ich auch. Entweder in 20nm oder sogar schon in 20nm FinFET. Ob TSMC oder GloFo hier das Rennen macht wird davon abhängen wer als erster soweit ist und wer den besseren Prozess hat.
Das kann so sein (nehme ich auch an), aber die logische Folgerung in dem Satz stimmt nicht. CPU und GPU sind doch unabhängig vom verbauten Speichercontroller, das sind alles austauschbare Bauteile ohne Abhängigkeiten. Sie könnten also auch, falls gewünscht, nur den Speichercontroller tauschen gegen einen für DDR4 oder sonstwas und den Rest gleich lassen. Nur da ja von Excavator geredet wird, wird an dem CPU-Teil sicher was gemacht - was sie aber sonst noch ändern, ist unklar. Kann durchaus sein, daß sie einen Kombicontroller einbauen (falls möglich), um dann flexibler zu sein (d.h. gleiches Die in unterschiedliche Packages bauen und fertig).
Da das modular ist, gibt es einen Uncore-Teil, einen GPU-Teil und einen CPU-Teil. Siehe beispielsweise Vishera. das ist Uncore ein Orochi Rev.C, daher musste man bei den Piledriver-Modulen Kompromisse eingehen, beispielsweise keine RCM-Unterstützlung. Man wird extra für Carrizo nicht einen komplett neuen Uncore-Teil entwickeln, der auch DDR4 kann, weil das den Kostenrahmen sprengen wurde, zumal danach ja eh was ganz Neues kommen muss. Carrizo ist wieder so ein Komromiss, man entwickelt effizentere CPU-Module und nutzt die alte Infrastruktur (auf dem Die) um die Kosten so niedrig wie möglich zu halten. Das ist ja nur ein Provisorium bis die neue Produktpalette soweit ist.

[Skysnake]

Mit DDR4 wird das aber sehr schwierig!

DDR2->DDR3 ging das "leicht", da sich die Pinbelegung ja nicht ändern musste. Man taktet ja "nur" höher und hat einige Änderungen intern, aber das wars ja.

Bei DDR4 brüchtest du komplett neue Pins. Ich bezweifle sehr stark, das wir das sehen werden. Pinlimitation und so.

[Duplex]

Bis AMD eine DDR4 Plattform hat gibt es bereits 10nm Chips von Intel im Handel, 2016 kommt der Skylake Shrink auf 10nm!!!

[robbitop]

:freak:
Natürlich ist die Plattform nicht unabhängig vom Speichertyp, es sei denn, man legt sie direkt als Kombiplattform aus... FM3+ ist aber eine reine DDR3-Plattform, also braucht man für DDR4 logischerweise eine neue...
Auch die Architektur muss DDR4 unterstützen. Da Carrizo aber einfach ein Kaveri (GCN1.1) mit Excavator-Modulen sein wird, bleibt also auch DDR3. In 2015/16 braucht man alles neu.
Also:

Du hast mich missverstanden. Dass die Speicherunterstützung vom Sockel abhängig ist, ist klar. Ich fragte, ob du mit Plattform eine neue micro-Arch meinst...

Der Speichercontroller und Sockel sind mMn relativ unabhängig von der micro arch. Die CPU und GPU sind doch eh über ein Kommunikationssystem (Ringbus/Crossbar) an den ganzen IO Kram angesetzt. Das müsste doch (mit gewissem Aufwand) austauschbar sein.

[Knuddelbearli]

Mit DDR4 wird das aber sehr schwierig!

DDR2->DDR3 ging das "leicht", da sich die Pinbelegung ja nicht ändern musste. Man taktet ja "nur" höher und hat einige Änderungen intern, aber das wars ja.

Bei DDR4 brüchtest du komplett neue Pins. Ich bezweifle sehr stark, das wir das sehen werden. Pinlimitation und so.


auch wenn ich annehmen das du das eh weisst

bei ddr2 --> ddr3 wurden NICHT die Taktraten geändert sondern das prefetching. Erst jetzt mit DDR4 wird das erste mal seit langem an der Taktschraube gedreht.

SDRAM 66-133MHz kein Prefetching deshalb SDRAM
DDR1 100-266MHz 2 fach Prefetching
DDR2 100-266MHz 4 fach Prefetching
DDR3 100-266MHz 8 fach Prefetching
DDR4 200-400MHz 8 fach Prefetching

[Undertaker]

Jo das denke ich auch. Entweder in 20nm oder sogar schon in 20nm FinFET. Ob TSMC oder GloFo hier das Rennen macht wird davon abhängen wer als erster soweit ist und wer den besseren Prozess hat.

Gerade auf der Low-Power-Schiene halte ich es für sehr wahrscheinlich, dass man auch den Zwischenschritt 20nm (ohne FinFET) mitnimmt. Zum einen lässt sich ein Design a'la Kabini oder Beema sicher schneller auf einen neuen Prozess umsetzen, als dies bei einem größeren Chip der Fall ist. Zum anderen ist Perf/Watt hier noch wichtiger als ohnehin schon, sodass auch ein eher kleiner Zwischenschritt lohnt. Und schlussendlich ist noch die Frage, ob 14XM & Co. gerade zu Anfang nicht sehr teuer werden und damit zumindest für diese Preisklasse nicht sofort attraktiv.

[HOT]

Andereseits ist auf der neuen Roadmap aber nichts verzeichnet, außer die wahrscheinliche GloFo-28nm-SHP-Variante Beema (für den großen BGA-Markt) und die TSMC-HPM-Variante Kabini (für einen kleinen "Sockel"-Markt) bis Ende 2015... das spricht eher gegen die 20nm. Heißt zwar nicht unbedingt was, da Roadmaps ja gerne mal geändert werden, aber nach einem 2. Blick wird AMD 20nm mMn maximal für Grafikchips nutzen. Nach der Roadmap gibts (muss) 2016 einen Haufen echter Neuigkeiten in 20nm FinFETs.
Fraglich hierbei ist nur, ob es eine neue µArch wirklich auch 2016 gibt oder ob Excavator-B einfach geshrinkt wird. Wenn man die Entwicklung in 2011 begonnen hat, passt 2016 für eine neue µArch auch ganz gut, 5 Jahre braucht man. Kann natürlich auch 2017 werden, dann gäbs übergangsweise noch einen 14XM-Excavator.

Nö, ist doch schon alles für 256bit FMA ausgelegt, das passt schon, AVX2 legt da nichts nach.

Spricht einiges für die Theorie. Dagegen spricht aber die Leistungsexplosion auf den älteren Roadmaps. Das würde für effizientere Ausführungseinheiten sprechen.

[Duplex]

Fraglich hierbei ist nur, ob es eine neue µArch wirklich auch 2016 gibt oder ob Excavator-B einfach geshrinkt wird. Wenn man die Entwicklung in 2011 begonnen hat, passt 2016 für eine neue µArch auch ganz gut, 5 Jahre braucht man. Kann natürlich auch 2017 werden, dann gäbs übergangsweise noch einen 14XM-Excavator.

Excavator B ist vermutlich noch 28nm, der 28nm Prozess von GF sollte bis dahin denke ich nochmal verbessert worden sein, mit einem neuem Stepping & optimierten Prozess kann man mehr CPU & GPU Takt erwarten und etwas mehr IPC, erst der Nachfolger von Excavator wird dann auf einem neuen Prozess setzen, vielleicht bereits mit einer neuen Architektur (Modul mit 4 Integer, Trace Cache, 512 Bit FPU & AVX3 ?), so oder so braucht man 2016 einen neuen Prozess weil Intel dann mit 10nm beginnen wird.

[AnarchX]

AMDs nativer 16 Core?
http://i.imgur.com/9D90N6x.png
http://support.amd.com/TechDocs/47414_15h_sw_opt_guide.pdf S. 197
http://semiaccurate.com/forums/showpost.php?p=205573&postcount=344

[mironicus]

Will AMD eigentlich die Schiene beibehalten, dass sie in Zukunft zwei Sockel anbieten? Also FMx und AM3/4?

Ich wäre immer noch dafür, dass man reine CPUs ohne GPU-Kerne anbietet. Der gesamte Platz nur für CPU-Kerne, Cache etc...

[disap.ed]

Ich denke nicht dass noch wirklich neue CPUs ohne GPU kommen, damit würde man HSA - welches ja momentan die heilige Kuh von AMD zu sein scheint - unnötig schwächen. Sie dürfen aber auch von mir aus gerne die GPU 1-2 Jahre nicht mehr größer werden lassen (also bei 512 Einheiten belassen), ist jetzt schon an der Speicheranbindung limitiert.

[Knuddelbearli]

ach 1-2 CUs ( Kaveri hat 8 ) brauchen nicht wirklich viel Platz und helfen HSA auch schon weiter. Wäre ihmo der sinnvollste Kompromiss

[Thunder99]

Neue FX könnte es schon geben wenn AMD seine Server Sparte mit neuen Produkten erzeugt. Wann das sein wird weiß nur AMD selber. Evt machen sie es aus gutem Grund erst mit Excavator

[Nakai]

AMD muss eine neue Architektur liefern. Ich bleibe dabei, man wird sich an den Wildkatzen orientieren. Jaguar und Co. ist eine wirklich gute und ausgeglichene Architektur. 4 statt 2fach Skalar, besseres Branching, bessere Caches und allgemein mehr Ports, wären toll.

Was viele vergessen, ist, dass man warscheinlich niemals mit Intel gleichziehen wird, jedenfalls IPC-mäßig. Aber das muss nicht sein. Wenn man ne ähnliche Pro-Mhz-Leistung hat, reicht das doch schonmal...


mfg

[Duplex]

AMD muss eine neue Architektur liefern. Ich bleibe dabei, man wird sich an den Wildkatzen orientieren. Jaguar und Co. ist eine wirklich gute und ausgeglichene Architektur. 4 statt 2fach Skalar, besseres Branching, bessere Caches und allgemein mehr Ports, wären toll.

Was viele vergessen, ist, dass man warscheinlich niemals mit Intel gleichziehen wird, jedenfalls IPC-mäßig. Aber das muss nicht sein. Wenn man ne ähnliche Pro-Mhz-Leistung hat, reicht das doch schonmal...
Für eine neue Architektur braucht man 4-5 Jahre Entwicklungszeit.

Bulldozer sollte 2009 in 45nm HKMG kommen und wurde auf 2011 verschoben, damals haben einige gedacht das man mit Nehalem IPC + Turbo auf Sandy Bridge Regionen kommen kann, aber das war nur Wunschdenken. Bei gleichem Takt langsamer als K10, nur mit neuen Befehlssätzen die der K10 nicht hat konnte Bulldozer glänzen.

Eine neue Architektur ist nur dann sinnvoll wenn man damit auch überzeugen kann, Interlagos ist mit 16 Threads im Server Markt ein Verlierer.

Warum sollte AMD jetzt wieder eine neue Architektur entwickeln, damit man beim nächsten mal wieder den CEO entlassen muss, so einfach ist das nicht.

Nicht vegessen, der Nachteil mit der Fertigung besteht weiterhin, die Effizienz der Core CPUs wird AMD mit einer neuen Architektur vermutlich nicht erreichen können, Intel hat 4-5 Jahre Vorsprung.

[robbitop]

AMD muss eine neue Architektur liefern. Ich bleibe dabei, man wird sich an den Wildkatzen orientieren. Jaguar und Co. ist eine wirklich gute und ausgeglichene Architektur. 4 statt 2fach Skalar, besseres Branching, bessere Caches und allgemein mehr Ports, wären toll.


Das klingt, als ob man einfach nur irgendwas verdoppeln müsste. Je höher die IPC sein soll, desto komplizierter wird es. Und zwar expotenzial. Jaguar ist gut für sein Segment. Ein BD Nachfolger muss idealerweise eine doppelt so hohe IPC aufweisen und zwischen ~10...100 W skalieren.

Eine Daumenregel besagt, dass CPU Designs innerhalb einer Größenordnung halbwegs anständig skalieren.

Jaguar ist leider auch nicht so richtig Fisch oder Fleisch. Er skaliert zwischen 2...20 W. Zu viel Verbrauch für einen SFF SoC (2W - unteres Ende) und zu wenig Leistung im Ultrabook Segment (20 W - oberes Ende).

Das hat Intel seit der neusten Architektur besser platziert.

Ideal wäre es zukünftig also so:

-Große Architektur zwischen ~ 100...10 W (Desktop bis runter zum Ultrabook) -> vielleicht auch eher zwischen 70 und 7 W??

-Kleine Architektur zwischen 10...1 W.

So wie Intel das jetzt macht.


Ich vermute allerdings, dass man mittelfristig die Wildkatzen gegen ARM Lizenzen ersetzt (SFF, Mikroserver - da ist ARM sowieso König). Besser wären natürlich ARM Custom Cores - aber AMD hat gerade kein Geld für solche Spielereien.

Für eine neue Architektur braucht man 4-5 Jahre Entwicklungszeit.

Bulldozer sollte 2009 in 45nm HKMG kommen und wurde auf 2011 verschoben, damals haben einige gedacht das man mit Nehalem IPC + Turbo auf Sandy Bridge Regionen kommen kann, aber das war nur Wunschdenken. Bei gleichem Takt langsamer als K10, nur mit neuen Befehlssätzen die der K10 nicht hat konnte Bulldozer glänzen.

Eine neue Architektur ist nur dann sinnvoll wenn man damit auch überzeugen kann, Interlagos ist mit 16 Threads im Server Markt ein Verlierer.

Warum sollte AMD jetzt wieder eine neue Architektur entwickeln, damit man beim nächsten mal wieder den CEO entlassen muss, so einfach ist das nicht.

Nicht vegessen, der Nachteil mit der Fertigung besteht weiterhin, die Effizienz der Core CPUs wird AMD mit einer neuen Architektur vermutlich nicht erreichen können, Intel hat 4-5 Jahre Vorsprung.

Eine neue Architektur macht schon Sinn. Aus den Baggern holt man augenscheinlich nicht mehr viel raus. Diese können Zeit schinden, bis die Nachfolge Arch draußen ist - mehr aber auch nicht. Im Gegenteil - man braucht eine neue Architektur.

AMD sollte das Know How dazu da haben. Man hat viel aus K7-10 aber auch aus BD gelernt. BD wendet viele modernen Tricks, die auch bei Intel Cores enthalten sind, die BD etwas anhieven.

Ich glaube, die Designprämissen stimmten für BD ganz einfach nicht. Man hat sich da in Annahmen verrannt, die ganz einfach so nicht auftraten:

- Erwartungen an Taktbarkeit
- Erwartungen an die Entwicklung von massiv verbreiteten Multiprozessorsupport (und seiner Skalierung)

BD ist AMDs P4. Daraus muss man lernen.

Ohne den P4 hätte es die Cores bei Intel auch nicht gegeben. Da hat man ebenfalls eine Menge gelernt.

[HOT]

Neue FX könnte es schon geben wenn AMD seine Server Sparte mit neuen Produkten erzeugt. Wann das sein wird weiß nur AMD selber. Evt machen sie es aus gutem Grund erst mit Excavator
Eigentlich ist 40h ja SteamrollerB, aber AMD nennt das Excavator. Carrizo dürfte die selben Module mit 256Bit FPU (und AVX2) abbekommen. Der ursprüngliche Excavator war ja erst für 16nm SOI und dann für 20nm SHP geplant und dürfte mit dem Prozess gestorben sein (20nm SHP wurde ja offiziell gecancelt). Danach kommt was Neues im FinFET-Prozess. ich hab ja von Anfang an vermutet, dass es einen großen 28nm SHP Excavator geben wird, ich hätt nur nicht mit 8 Modulen gerechnet ;). Gibt aber sicherlich auch ein 4-Modul-Die.

[...]


Ich vermute allerdings, dass man mittelfristig die Wildkatzen gegen ARM Lizenzen ersetzt (SFF, Mikroserver - da ist ARM sowieso König). Besser wären natürlich ARM Custom Cores - aber AMD hat gerade kein Geld für solche Spielereien.
[...]

Das Geld ist hierbei kein Problem, die Zeit ist das Problem. Geld ist generell kein Problem, Geld gibts theoretisch unendlich, vor allem in Zeiten, wo Profis kaum noch wissen, wohin mit den ganzen Vermögen, was dazu führt, dass die Allianz beispielsweise Parkuhren in London aufkauft... Der Denkansatz ist völlig falsch. Geld war in der Wirtschaft nie ein limitierender Faktor, sondern ein reines Machtinstrument. Das ganze Spiel startet doch jetzt wieder, es werden wieder Kredite außer Rand und Band vergeben (mittlerweile, nach langer Durststrecke), was die Schulden/Vermögensblase letztmalig richtig befeuern wird.
AMD wird sicher ARM-Custom-Cores anbieten, aber sowas muss erst mal entwickelt werden. Mit den ersten Custom-Cores kann man frühestens Ende 2015 rechnen. Damit kann man dann auch wieder Custom-Deisgns verkaufen.

[robbitop]

Der 28 nm Excavator hat also mit dem ursprünglichen Excavator nichts mehr zu tun? Welcher von beiden ist denn von der µ-Arch weiter entwickelt? Eigentlich doch dann der 28 nm Excavator (weil er zusätzliche Entwicklungszeit hatte)?

[fondness]

Auch schon der ursprüngliche Streamroller hat nichts mehr mit den aktuellen Streamroller zu tun, zumindest was den Fertigungsprozess betrifft. AMD nennt das Ding ja auch nicht ohne Grund SteamrollerB.

AMD konnte oder je mehr man Internas hört wohl eher wollte die IBM SHP Prozesse nicht mehr haben. Von Excavator erwarte ich nicht mehr viel, das ist ein Lückenfüller bis man mit der neuen Strategie so weit ist. AMD ist sich durchaus bewusst dass das Bulldozer design ein fail war, das hat man ja sogar bereits öffentlich geäußert. Ein 8 Modul Design auf dessen Basis kann ich mir auch schwer vorstellen, dafür fehlt der Fertigungsprozess. Die große Unbekannte ist was AMD ab 2015 macht, das werden die ersten Chips sein die um den neuen CEO und Jim Keller designt wurden - dieser verspracht immerhin Vollmundig eine Rückkehr ins High-End.

[robbitop]

8 Module mit beschränktem Takt sind sicher nicht unmöglich in 28 nm SHP. Mit 125 W TDP wäre da sicher etwas mit knapp ~ 3 GHz drin. Die Frage ist nur: wer kauft sowas? Da sind Intelprozessoren immernoch besser.

[fondness]

Das Ding hätte auf jeden Fall >400mm² und wie du schon sagst den Sinn dahinter sehe ich auch nicht. 8 Threads sind genug solange Intel weiter 4 Kern Chips zu Mondpreisen verkauft. Die wenigste Software skaliert darüber hinaus, noch dazu widerspricht das klar dem HSA-Konzept für massives Multi-Threading auf die GPU zu setzen. Ich erwarte überhaupt keinen non-APU-Chip von AMD mehr.

[HOT]

Man las von nur 8MB L3-Cache, was übersichtlich scheint. Man wird da schon recht sparsam vorgehen. Wie gesagt, ist da sicherlich auch noch ein kleinere Die mit nur 4 Modulen möglich.
Das Ding hätte auf jeden Fall >400mm² und wie du schon sagst den Sinn dahinter sehe ich auch nicht. 8 Threads sind genug solange Intel weiter 4 Kern Chips zu Mondpreisen verkauft. Die wenigste Software skaliert darüber hinaus, noch dazu widerspricht das klar dem HSA-Konzept für massives Multi-Threading auf die GPU zu setzen. Ich erwarte überhaupt keinen non-APU-Chip von AMD mehr.
Der 40h programming Guide ist offiziell. Es ist extrem wahrscheinlich, dass man auch einen entsprechenden Prozessor bringt. Bis man im Serverbereich auf APUs setzt braucht man eine Übergangslösung.

[StefanV]

dass das Bulldozer design ein fail war
Naja, die Architektur ist eigentlich OK, es scheitert allerdigns an viel zu vielen Ecken und Enden, wo man einfach ganze Berge an Leistung liegen lässt. Zum Beispiel eben auch den L3 Cache. Wenn der mit vollem Coretakt laufen würde und ordentlich angebunden wäre, hätte man hier auch noch einiges rausholen können - kann man aber nicht. Dazu die relativ kleinen L1 Data Caches von nur 16KiB...

[Twodee]

Naja, die Architektur ist eigentlich OK, es scheitert allerdigns an viel zu vielen Ecken und Enden, wo man einfach ganze Berge an Leistung liegen lässt. Zum Beispiel eben auch den L3 Cache. Wenn der mit vollem Coretakt laufen würde und ordentlich angebunden wäre, hätte man hier auch noch einiges rausholen können - kann man aber nicht. Dazu die relativ kleinen L1 Data Caches von nur 16KiB...
So etwas ähnliches hat man damals auch über den P4 gesagt :biggrin:

[fondness]

Der 40h programming Guide ist offiziell. Es ist extrem wahrscheinlich, dass man auch einen entsprechenden Prozessor bringt. Bis man im Serverbereich auf APUs setzt braucht man eine Übergangslösung.

APUs im Serverbereich werden bereits dieses Jahr mit Kaveri eingeführt. Zumal GPUs im Serverbereich längst keine Nischenlösung mehr sind. Und nur für den Serverbereich macht für mich ein solcher Prozessor wenig Sinn, schon gar nicht erst irgendwann 2015 oder später. Was für mich Sinn machen würde wäre eine größere APU, also 4 Module, 1024 SPs mit ordentlich Speicherbandbreite.

[robbitop]

Naja, die Architektur ist eigentlich OK, es scheitert allerdigns an viel zu vielen Ecken und Enden, wo man einfach ganze Berge an Leistung liegen lässt. Zum Beispiel eben auch den L3 Cache. Wenn der mit vollem Coretakt laufen würde und ordentlich angebunden wäre, hätte man hier auch noch einiges rausholen können - kann man aber nicht. Dazu die relativ kleinen L1 Data Caches von nur 16KiB...
Es gibt einfach zu viele Ecken und Enden, die tief im Design verankert sind. Das waren bewußte Designentscheidungen. Des Design passt eben nicht zu den Anwendungen. Da hat man sich eben verschätzt. Das Design auf High-IPC umzustricken, macht wenig Sinn. Dann lieber ein neues aufsetzen mit anderen Prämissen.
Und dabei muss CMT nicht zwangsweise wegfallen. CMT kann auch in einem anderen Design angewendet werden. Ich würde eher auf SMT + breites Design plädieren. Aber damit ist sehr viel Validierungsaufwand verbunden. Das könnte eine Nummer zu viel werden. Aber wenn es ein Nachfolgedesign geben wird, wird es breit.

[fondness]

Bulldozer war ein Zugeständnis an die vorhandenen IBM Prozesse. Es ist kein Zufall das es parallelen zum Power-Design und ähnlich hohe Taktraten gibt. AMD braucht dringend andere Fertigungsprozesse mit andern Prioritäten. Die IBM Fertigungsallianz ist ja auch weitgehend auseinander-gebrochen und GF zieht ihre eigene Forschungsabteilung in New York hoch, auch Samsung hat sich zurück gezogen. Der IBM Prozess ist viel zu sehr auf Nischenmärkte ausgelegt.

[robbitop]

Ich denke, dass ein neues AMD Design dem Core Design sehr ähneln wird (von der Philosophie). (vermutlich aber nicht mit SMT)

[StefanV]

Es gibt einfach zu viele Ecken und Enden, die tief im Design verankert sind. Das waren bewußte Designentscheidungen.
Zum Teil ja, zum Teil wohl eher nicht (NB Taktfrequenzen)...

Die Ausführungseinheiten sollten eigentlich auch weniger das Problem sein, prinzipiell. Der Rest ist es.

[robbitop]

Naja mich wundert, dass der Takt des Speichercontrollers ein Problem ist. Ansonsten sollten die Bereiche alle eigene Taktdomänen haben, so dass solche Situationen nicht auftreten können.

Bulldozer ist an allen Fronten geplagt. Die Ausführungseinheiten, das Front End, die Caches. Da ist einfach zu viel auf andere Prämissen getrimmt. Da hilft nur die Abrissbirne. ;)

[mrt]

Der NB-Takt ist doch nicht der Takt des Speichercontrollers per se (der hat zwei), denk mal an zB Crossbar.

[disap.ed]

Wie groß wäre denn ungefähr ein 4-Moduler mit GCN-Grafik und 8MB L3-Cache auf 28nm SHP? Der Cache (bzw. dessen Größe) sollte doch sehr stark von der höheren Packdichte profitieren, oder? Würde die GPU den Cache mitnutzen können mit HSA? Die GPU bräuchte gar nicht so groß sein wie bei Kaveri, eventuell könnte man es auch bei 4 oder 6 compute cores belassen um Platz zu sparen.

Ginge sich das im Bulldozer die size Budget (315mm²) aus?

[robbitop]

Wie auch immer. Der I/O Teil sollte schon so ausgelegt werden, dass er nicht zum Flaschenhals wird. Ansonsten verpufft die aufwändige Arbeit am Design, um jedes Quäntchen IPC herauszupressen (und es am Ende durch profanes I/O blockiert wird).

Ich schätze aber mal, dass der Test bei Golem eher Spezialfälle sind.

[Exxtreme]

Bulldozer ist an allen Fronten geplagt. Die Ausführungseinheiten, das Front End, die Caches. Da ist einfach zu viel auf andere Prämissen getrimmt. Da hilft nur die Abrissbirne. ;)
Und ich glaube immer noch, dass das pure Absicht ist damit die CPU nicht hinterher 300 W frisst.

[HOT]

Ich denke, dass ein neues AMD Design dem Core Design sehr ähneln wird (von der Philosophie). (vermutlich aber nicht mit SMT)
Nein, werden sie nicht. Sie können in der Form mit Intel nicht konkurrieren, man braucht was effizienteres als Intels Brute-Force-Taktik. AMD wird den HSA-Ansatz konsequenter verfolgen. Wenn die Server-CPU in der Form kommt, wird das sicherlich die letzte ihrer Art.

[robbitop]

Und ich glaube immer noch, dass das pure Absicht ist damit die CPU nicht hinterher 300 W frisst.
So oder so: leider daneben. Intel zeigt ja wie es geht. Breites Design mit hohem ILP und hoher IPC mit niedriger Verlustleistung. In die Richtung muss man ebenfalls gehen.

Nein, werden sie nicht. Sie können in der Form mit Intel nicht konkurrieren, man braucht was effizienteres als Intels Brute-Force-Taktik.
Erstmal sollte man den CPU Kern und HSA in der Diskussion trennen. HSA ist unabhängig vom CPU Kern einsetzbar.
Außerdem ist Intels CPU Kern super effizient. Natürlich wird man mangels Ressourcen und Fertigungsnachteil nie besser sein als Intel. Aber: besser als jetzt allemale.

Der "anders" Ansatz ist voll nach hinten losgegangen. Mit "anders" sind leider keine Blumentöpfe zu gewinnen. Mit HSA und anderen Anwendungsgebieten kann man sicher Marktfelder ausdehnen. Dennoch braucht man gute CPU Kerne dafür. Intel verfolgt im CPU Design die richtige Richtung. Ich sehe da keinen besseren Ansatz. Einen, den Intel übersehen hat. (so wie den "Speed Demon") Dann lieber auch diesen Weg gehen und ein wenig schlechter als Intel sein als (wie jetzt) viel schlechter.


AMD wird den HSA-Ansatz konsequenter verfolgen. Wenn die Server-CPU in der Form kommt, wird das sicherlich die letzte ihrer Art.
HSA ist aber längst nicht überall anwendbar. Das sind Spezialfälle. Wald-und-Wiesen-Code wird die Oberhand haben. Außerdem spricht auch bei einem Intel-artigen Design nichts gegen HSA.
Außerdem hat Intel auch SoCs. Also mit IGP. Die wird auch immer besser. Und irgendwann macht Intel etwas ähnliches wie HSA (oder tritt HSA bei). Das ist keine Zauberei.

[Gipsel]

So oder so: leider daneben. Intel zeigt ja wie es geht. Breites Design mit hohem ILP und hoher IPC mit niedriger Verlustleistung. In die Richtung muss man ebenfalls gehen.ILP ist ein Merkmal des Codes, nicht einer CPU. ;)
Außerdem bezweifle ich jetzt einfach mal, daß wenn man das gleiche Konzept mit vielleicht 10% der Resourcen auf einem 2+ Jahre hinterherhängendem Prozeß implementiert, da was wirklich Konkurrenzfähiges herauskommt, wenn intel nicht pennt.

[robbitop]

AMD hat ja nun Jahre lange Erfahrungen gesammelt und ist aus BD sicherlich nicht dümmer geworden. Und wer weiß, wie lange sie schon daran arbeiten und bis wann es dauert?
Eventuell arbeitet man bereits seit BD Launch daran und es kommt 2015...2016. Also ~ 1/2 Jahrzehnt an Entwicklung. Warum sollte da nicht etwas brauchbares bei rauskommen. Mit AMDs Erfahrung.

Was soll man denn sonst machen? Die Flinte in's Korn werfen? BD ist schonmal nicht die Lösung.

Wer sagt denn auch, dass die Nachfolge-µ-Arch genauso gut wie Intels Kern ist? Im Moment hat Intel einen ~50 % Vorsprung in Punkto IPC. Da sollte sich schon etwas dran machen lassen. Und wenn es am Ende nur noch 10..20 % sind, ist das ein Fortschritt.

[grobi]

Ist es nicht sogar noch mehr wie 50%, eher so 60-70%?

[sklave_gottes]

Ich frage mich sowieso warum die BD Module mit allem drum und dran so Riesig sind. Das verhältnis Leistung zur DIE-Fläche stimmt Vorne und Hinten nicht! Der größte Vorteil vom Modul design (2-4 Module), ist doch die einsparung von Fläche gegenüber einem echten 4-8 Kerner? Aber es ist doch genau das gegenteil eingetroffen.
Alles was auf BD basiert ist quasie Riesig.

Ich bin echt gespannt auf den vergleich uralter FX 8150@4Threads vs A10-7850K, beide mit dem selben Takt und ohne Turbo. Aber so wie es aussieht, hat der FX in Anwendungen die alle 4 Threads voll auslasten dann immer noch die höhere Leistung :-(. Danke an die Module.....

[StefanV]

Warum sollte da nicht etwas brauchbares bei rauskommen. Mit AMDs Erfahrung.
...mit AMDs Budget...
...am BD siehst ja, dass es daran recht deutlich gescheitert ist...

[ndrs]

Ist es nicht sogar noch mehr wie 50%, eher so 60-70%?
Bitte nicht schon wieder diese Diskussion, wo jeder anfängt mit Benchmarks um sich zu werfen. IPC ist IMMER von der Anwendung abhängig. Such dir einen konkreten Benchmarkt raus, dann kannst du an diesem die IPC vergleichen. Durchschnitte wichtet eh jeder, wie es ihm passt.
Danke an die Module.....
Ein ursprüngliches BD-Modul lag meines Wissens inkl L2-Cache bei 30mm^2. Die Module sind nicht groß. Das liegt an was anderem. Und was die Effizienz bei höherer Auslastung angeht: Ich finde die Mehrleistung bei 2 Threads in anbetracht dessen, dass ein Modul 25% größer als ein hypotetischer Einzelkern ist, vollkommen in Ordnung. In Mehrleistung pro Mehrfläche ist ein Modul nicht (wesentlich) schlechter als Intels SMT.
Das Modulkonzept selber ist vollkommen in Ordnung. Daran hapert es nicht. Es fehlt an allgemeiner Leistung.

[sklave_gottes]

Ein ursprüngliches BD-Modul lag meines Wissens inkl L2-Cache bei 30mm^2. Die Module sind nicht groß. Das liegt an was anderem. Und was die Effizienz bei höherer Auslastung angeht: Ich finde die Mehrleistung bei 2 Threads in anbetracht dessen, dass ein Modul 25% größer als ein hypotetischer Einzelkern ist, vollkommen in Ordnung. In Mehrleistung pro Mehrfläche ist ein Modul nicht (wesentlich) schlechter als Intels SMT.
Das Modulkonzept selber ist vollkommen in Ordnung. Daran hapert es nicht. Es fehlt an allgemeiner Leistung.

Doch, denn nach letzten informationen benötigt Intel für SMT weniger als 5% mehr Schaltungen/Fläche. Es ist doch letzten endes egal wodurch die BD so groß sind. Sie sind einfach Gigantisch, selbst ein Liano@10Kerne ist ja bald kleiner:freak:. Es macht einfach keinen Sin, krampfhaft jeden Millimeter IPC rauszuholen um ihn dann wieder mit dem Modulen zu vernichten.
Nicht ohne grund ist ein uralter phenom x4 980 immer noch auf Augenhöhe mit allen 2 Modulern die AMD bis jetzt rausgebracht hat und dazu auch noch viel kleiner......Das darf einfach nicht sein. Das ist schon der 3te Anlauf. So schlecht war nichtmal der Pentium4:frown:.

Wenn man schon Probleme hat die IPC auf ein vernünftiges Mass zu bringen, dann soll man doch bitte nicht alles wieder durch die Module verlangsamen. Vorallem rudern sie ja schon zurück mit Kaveri.
Lieber kleinere Kerne und dafür dann "Richtige" 4,6 oder sogar 8. Genügend Platz hat man ja jetzt dank der 28nm fertigung. Zumal die 512er GPU auch viel zu Dick geworden ist dank mangelner Speicherbandbreite. Auch hier wären erstmal 384 völlig ausreichend.

[ndrs]

Ok, ich hätte schreiben sollen Leistung/Fläche statt Mehrleistung/Fläche. Dann kämen wir auf 125% Fläche für 180% Leistung (oder was geben hier gängige Reviews raus?) gegen 105% Fläche für 125% Leistung. Sieht doch ganz brauchbar aus, oder?

Du hättest also lieber 5 Kerne anstatt 4 Module? Genau das würde nämlich die gleiche Die-Fläche brauchen.

So wie du über die Module herziehst müsste man ja meinen, dass AMDs SingleThread-Leistung konkurennzfähig ist.

[grobi]

Ok, ich hätte schreiben sollen Leistung/Fläche statt Mehrleistung/Fläche. Dann kämen wir auf 125% Fläche für 180% Leistung (oder was geben hier gängige Reviews raus?) gegen 105% Fläche für 125% Leistung. Sieht doch ganz brauchbar aus, oder?

Du hättest also lieber 5 Kerne anstatt 4 Module? Genau das würde nämlich die gleiche Die-Fläche brauchen.

So wie du über die Module herziehst müsste man ja meinen, dass AMDs SingleThread-Leistung konkurennzfähig ist.


Am besten du hörst auf Dinge zu schreiben die du selber nur gelesen hast. Es ist nur Marketing blabla von AMD gewesen. Oder wo hast du dein Wissen her?

[reaperrr]

Doch, denn nach letzten informationen benötigt Intel für SMT weniger als 5% mehr Schaltungen/Fläche. Es ist doch letzten endes egal wodurch die BD so groß sind. Sie sind einfach Gigantisch, selbst ein Liano@10Kerne ist ja bald kleiner:freak:
Der zusätzliche Integer-Kern kostet laut AMD auch nur 10% zusätzliche Fläche und bringt prozentual im Durchschnitt deutlich mehr als SMT.

2 Llano-Kerne sind meines Wissens zusammen etwa 4-5mm² größer als ein BD-Modul. Außerdem fehlt ihnen die Unterstützung für diverse zusätzliche Befehle (SSE4.1+4.2, AVX, FMA3+4 u.a.).

Das Hauptproblem ist nicht das Modulkonzept, sondern dass BD den P4-Ansatz verfolgt: Niedrige IPC pro Kern, lange Pipeline und hohe Latenzen sowie relativ niedrige Packdichte um hohe Taktraten erreichen zu können, großer L2 um diese hohen Latenzen einigermaßen "verstecken" zu können.

Ich meine mal in einem Artikel gelesen zu haben, dass einer der führenden AMD-Köpfe hinter dem BD-Konzept - Achtung, jetzt wird's interessant - auch der Kopf hinter Intel's P4-"wird bis 10 GHz skalieren"-Konzept war. Dem wäre doch nichts hinzuzufügen...

BD und was darauf basiert ist einfach noch ein Server-CPU-Konzept der alten Sorte, welches einfach von der Zeit und dem sich verändernden Markt überholt wurde und zudem noch an seinen diversen, durch zu viele Kompromisse und Detail-Fehlentscheidungen entstandenen Flaschenhälsen krankt, sowie zur Krönung des Ganzen nicht so richtig APU-kompatibel ist, weil das Hochtakt-Konzept eher einen guten, reinen, voll auf CPU-Takt optimierten CPU-Prozess bräuchte, was sich AMD aber in Hinblick auf seine APUs nicht leisten konnte.

[Duplex]

Das Hauptproblem ist nicht das Modulkonzept, sondern dass BD den P4-Ansatz verfolgt: Niedrige IPC pro Kern, lange Pipeline und hohe Latenzen sowie relativ niedrige Packdichte um hohe Taktraten erreichen zu können, großer L2 um diese hohen Latenzen einigermaßen "verstecken" zu können.

Ich meine mal in einem Artikel gelesen zu haben, dass einer der führenden AMD-Köpfe hinter dem BD-Konzept - Achtung, jetzt wird's interessant - auch der Kopf hinter Intel's P4-"wird bis 10 GHz skalieren"-Konzept war. Dem wäre doch nichts hinzuzufügen...

BD und was darauf basiert ist einfach noch ein Server-CPU-Konzept der alten Sorte, welches einfach von der Zeit und dem sich verändernden Markt überholt wurde und zudem noch an seinen diversen, durch zu viele Kompromisse und Detail-Fehlentscheidungen entstandenen Flaschenhälsen krankt, sowie zur Krönung des Ganzen nicht so richtig APU-kompatibel ist, weil das Hochtakt-Konzept eher einen guten, reinen, voll auf CPU-Takt optimierten CPU-Prozess bräuchte, was sich AMD aber in Hinblick auf seine APUs nicht leisten konnte.
Exakt!

[S940]

Bulldozer ist an allen Fronten geplagt. Die Ausführungseinheiten, das Front End, die Caches. Da ist einfach zu viel auf andere Prämissen getrimmt. Da hilft nur die Abrissbirne. ;)
ICh find Steamroller mittlerweile recht passabel. IPC ist ok, Write-Performance ist endlich da, wo sie hingehört, 4,5 Ghz++ OC ist aber trotzdem noch drin, Verbrauch ist auch gesunken ...

Was jetzt noch für Spiele fehlt ist mMn nur der L3-Cache und 1 Modul mehr.

Dann wär das ganze schon ne einigermaßen runde Sache, der FX6350 war auch schon nicht so schlecht, hatte aber halt nur die alte Plattform.

[ndrs]

Am besten du hörst auf Dinge zu schreiben die du selber nur gelesen hast. Es ist nur Marketing blabla von AMD gewesen. Oder wo hast du dein Wissen her?
Natürlich habe ich das mit der Fläche nur gelesen. Das ich mich nicht ans Reißbrett setze und ein Modul mit nur einem Kern nachbaue um das zu messen, sollte relativ einleuchtend sein.
Aber gut. Ich kann mir natürlich auch von jedem dahergelaufenen das Wort verbieten lassen...

[Locuza]

ICh find Steamroller mittlerweile recht passabel. IPC ist ok, Write-Performance ist endlich da, wo sie hingehört, 4,5 Ghz++ OC ist aber trotzdem noch drin, Verbrauch ist auch gesunken ...
[...]
Dann wär das ganze schon ne einigermaßen runde Sache, der FX6350 war auch schon nicht so schlecht, hatte aber halt nur die alte Plattform.
Nach oben hin herrscht leider praktisch Stillstand, auch wenn man sich unten stark verbessert hat und hoffentlich das auch im mobile OEM Bereich sich durchschlägt, aber AMD hat gerade kein gutes Angebot ohne zu viele Kompromisse einzugehen.

Natürlich warte ich erst einmal ab, wie OC Ergebnisse ausfallen und ob man Steamroller mit etwas tuning nicht auch im oberen Bereich Feuer unterm Hinter machen kann, aber die Leistung bisher ist sehr ernüchternd.
Wo es mehr Leistung gibt, ist auf einer toten Plattform mit altem Chipsatz und saufenden CPUs.

[robbitop]

...mit AMDs Budget...
...am BD siehst ja, dass es daran recht deutlich gescheitert ist...
Das lag IMO nicht am Budget. Das lag an den falschen Designprämissen. AMD dachte, man muss es anders als Intel machen, da man mit dem gleichen Weg nicht gewinnen kann. Also baute man einen Speed-Demon.

Aber leider trafen 2x Voraussetzungen für den gewünschten Erfolg nicht ein:

- Taktbarkeit/Leistungsaufnahme
- die Multiprozessorskalierung der Software

AMDs BD ist analog zum P4 keine einfache oder blöde Architektur. Da steckt eine Menge Erfahrung und eine Menge Tricks und Kniffe drin. Aber das nützt einem alles nichts, wenn die Designprämissen wegen obigen Punkten scheitern.

Ich habe keinen Zweifel daran, dass AMD eine bessere µ-Arch entwicklen kann als BD. Sie wird vermutlich nicht an Intels Cores herankommen - aber besser als BD alle Male.

Reines Gedankenspiel (dass das so einfach nicht geht - ist klar):

Stelle dir mal einen K10 mit Husky Core als Ausgangsbasis vor. Und jetzt baust du die ganzen guten Tricks aus dem BD ein (die K10 noch nicht hat). Und machst die Caches schneller. Am Ende dürftest du relativ nahe am Core von Intel liegen.

Ein ursprüngliches BD-Modul lag meines Wissens inkl L2-Cache bei 30mm^2. Die Module sind nicht groß. Das liegt an was anderem. Und was die Effizienz bei höherer Auslastung angeht: Ich finde die Mehrleistung bei 2 Threads in anbetracht dessen, dass ein Modul 25% größer als ein hypotetischer Einzelkern ist, vollkommen in Ordnung. In Mehrleistung pro Mehrfläche ist ein Modul nicht (wesentlich) schlechter als Intels SMT.
Das Modulkonzept selber ist vollkommen in Ordnung. Daran hapert es nicht. Es fehlt an allgemeiner Leistung.
This! Viele vermischen CMT und µ-Arch und schließen vom einen auf das andere.
Analog dazu müßte SMT nach dem Pentium 4 ja auch ziemlich schlecht sein, oder? Nein! Natürlich nicht. ;)

ICh find Steamroller mittlerweile recht passabel. IPC ist ok, Write-Performance ist endlich da, wo sie hingehört, 4,5 Ghz++ OC ist aber trotzdem noch drin, Verbrauch ist auch gesunken ...

Was jetzt noch für Spiele fehlt ist mMn nur der L3-Cache und 1 Modul mehr.

Dann wär das ganze schon ne einigermaßen runde Sache, der FX6350 war auch schon nicht so schlecht, hatte aber halt nur die alte Plattform.
Du findest eine IPC, die 50 % geringer ist als die des Mitberwerbers "ok"? Deine Ansprüche möchte ich haben. :D

[Pirx]

Die Zweimoduler liegen doch auch relativ nahe am am Core von Intel, mindestens am i3.;)

[robbitop]

Aber nur, wenn die Applikation 4 Threads nutzt. Wenn du dann einen Core i5 (4c/4t) einem 2 Moduler gegenüberstellst, dreht sich die Situation drastisch. Kern für Kern sieht es eben anders aus.

[Locuza]

Reines Gedankenspiel (dass das so einfach nicht geht - ist klar):

Stelle dir mal einen K10 mit Husky Core als Ausgangsbasis vor. Und jetzt baust du die ganzen guten Tricks aus dem BD ein (die K10 noch nicht hat). Und machst die Caches schneller. Am Ende dürftest du relativ nahe am Core von Intel liegen.

Ich glaube man würde dann so etwas ähnliches wie Jaguar heraus bekommen ;)

Aber nur, wenn die Applikation 4 Threads nutzt. Wenn du dann einen Core i5 (4c/4t) einem 2 Moduler gegenüberstellst, dreht sich die Situation drastisch. Kern für Kern sieht es eben anders aus.
Ein Haswell Kern hat ja auch grob die Ressourcen von einem ganzen BD Modul.

[robbitop]

Ich glaube man würde dann so etwas ähnliches wie Jaguar heraus bekommen ;)
Eher nicht. Jaguar ist eher für 2-20 W optimiert. Sehr balanciert - aber schmal, sparsam aber auch geringe IPC.
Da dürfte eher etwas breiteres, schnelleres bei rumkommen. Etwas, was den Cores ähnelt (von der reinen Philosophie).


Ein Haswell Kern hat ja auch grob die Ressourcen von einem ganzen BD Modul.
Eben.

[fondness]

Ein ursprüngliches BD-Modul lag meines Wissens inkl L2-Cache bei 30mm^2. Die Module sind nicht groß. Das liegt an was anderem. Und was die Effizienz bei höherer Auslastung angeht: Ich finde die Mehrleistung bei 2 Threads in anbetracht dessen, dass ein Modul 25% größer als ein hypotetischer Einzelkern ist, vollkommen in Ordnung. In Mehrleistung pro Mehrfläche ist ein Modul nicht (wesentlich) schlechter als Intels SMT.
Das Modulkonzept selber ist vollkommen in Ordnung. Daran hapert es nicht. Es fehlt an allgemeiner Leistung.

Es sind laut AMD 12% mehr Transistoren für das Modul wie für einen hypothetischen Einzelkern. Das Modul-Konzept also äußerst effizient, da man im wesentlichen nur die INT-Einheiten und die Registersätze duplizieren muss. Das Modul-Konzept ist im Grunde eine Weiterentwicklung von SMT, wo nur die Registersätze dupliziert werden.

Und die 30mm² inkl 2 MB L2-Cache pro Modul sind in 32nm - das sollte man nicht vergessen.

[Locuza]

Eher nicht. Jaguar ist eher für 2-20 W optimiert. Sehr balanciert - aber schmal, sparsam aber auch geringe IPC.
Da dürfte eher etwas breiteres, schnelleres bei rumkommen. Etwas, was den Cores ähnelt (von der reinen Philosophie).

Du meintest einen K10 als Basis mit den neusten Entwicklungen die in Bulldozer eingeflossenen sind.

Aus meiner groben Sicht würde da so etwas ähnliches wie Jaguar herausspringen.
Write-Back Cache-Design, PRFs, resizable L2-Cache, AVX usw.
Aber natürlich mehr im Sinne von "klassisch gewohnter" Architektur mit neuen Features ausgestattet.

[robbitop]

Jaguar? Ernsthaft? Das Ding ist einfach zu schmal für den Bereich 10-100 W. Breitere Execution (dicke FPUs, doppelt so viele ALUs), mehr Decoder, superschneller mittelgroßer L1 (~64 kiB), schneller kleiner L2 (~256...512 kiB), immernoch recht schneller aber großer L3.
Dazu Loop stream detector, µ Op instruction Cache, mächtige OoO Execution, so gut wie mögliche Sprungvorhersage, genug Load/Store Units etc.

[Locuza]

Jaguar als schmale Verwirklichung von deiner "Idee".
Deshalb das ähnlich.
Am Ende halt ein Jaguar in fett.

[robbitop]

Jaguar hat aber auch IIRC keine besonders schnellen Caches, kein LSD und IIRC keinen µ-op Instruction Cache. Alles Dinge, die Core so schnell machen.

[Locuza]

Jaguar hat so einen kleinen loop-buffer, Steamroller soll eine micro-op queue besitzen.
http://www.anandtech.com/show/6201/amd-details-its-3rd-gen-steamroller-architecture/2

Aber generell, solche Kniffe führt ja Intel schon seit längerem.
Das sind dann eher Sachen die nicht im ursprünglichem K10/BD Design zu finden waren.

Wäre der Vorschlag nicht naheliegend, nicht gleich das Core Design weitgehend zu kopieren?

[robbitop]

Naja nur weil die Flussdiagramme und Features sich ähneln, heíßt es nicht, dass man eine Architektur kopiert. Es sind am Ende nur Ähnlichkeiten in der Philosophie. Genauso wie Jaguar nicht auf K8 basiert oder Nehalem nicht auf dem P6. Auch GPUs nähern sich von der Philosophie (und somit vom Flow Chart) aneinander an. Auf Architektur Ebene hingegen sind sie anders gelöst.

Long Story short: ja man sollte zumindest die gleiche Philosophie verfolgen. Kopieren hingegen kann AMD die Architektur mangels genauer Kenntnis gar nicht.

[Duplex]

Das Risiko bei einer neuen Architektur ist zu hoch, K10 kam zu spät, BD kam auch zu spät, Marktanteile werden immer geringer, ich sehe in den Märkten keine AMD Produkte, sondern nur Intel & ARM...

Was will AMD mit einer neuen Architektur wenn Intel alles in der Hand hat?

Selbst wenn AMD die IPC verdoppeln könnte und der Takt weiterhin zwischen 3-4 Ghz liegen würde, kann AMD ernsthaft noch den Marktanteil deutlich steigern?

Mit Bulldozer wollte AMD primär im Server Bereich Boden gewinnen, das ist gescheitert, Interlagos ist der größte Verlierer...

Für APUs braucht man keine Bulldozer Kerne!

[robbitop]

Welche Alternative hat AMD? Aufgeben? Natürlich müssen sie etwas tun. Und es ist offensichtlich, dass BD nur noch inkremental kleine IPC Gewinne bringt. Das ist eine Einbahnstraße. Mich würde es nicht überraschen, wenn bereits seit 2010/2011 ein Team mit dem Entwurf einer neuen Architektur beschäftigt ist.
Selbst wenn BD ein guter Wurf gewesen wäre. Weiterentwicklung ist immer nötig. Ggf. setzen sie ja auf bekannte Paradigmen. Immerhin hat man aus K10, BD und Bobcat/Jaguar ja schon vieles gelernt. Bei 0 muss man sicher nicht anfangen.

[Locuza]

Darauf wollte ich hinaus.
Die frage ist, soll man sich das Konzept abschauen und damit praktisch immer die zweite Geige spielen oder ein eigenständiges ausarbeiten, mit einigen Schwächen, dafür aber auch Vorteilen gegenüber dem Konkurrenten?
Viel Spielraum hat AMD so oder so nicht.
Das Geld ist beschränkt und der Marktanteil auch, zu revolutionär kann man nicht sein und bei allem was spezielle Software-Anpassungen braucht, sollte AMD einen Bogen machen.

[mboeller]

Eher nicht. Jaguar ist eher für 2-20 W optimiert. Sehr balanciert - aber schmal, sparsam aber auch geringe IPC.


geringe IPC? Wie kommst du darauf? Hast du die IPC mal mit Bulldozer verglichen?

[Duplex]

AMD spart gewaltig Geld, warum sollen Sie weiterhin unnötig investieren wenn sich damit kaum Geld verdien lässt, die OEMs sind von nichts beeindruckt was AMD liefert, weil Intel der Geldgeber ist...

Eine neue Maske mit 3 Module / 6 Threads + 12 CUs mit 768 Shader in 28nm @300mm² kann ich mir noch vorstellen (Aber nur wenn Sie den Stromverbrauch optimieren können). Alles andere ist reines Wunschdenken, vor 2016 wird da sowieso nichts mehr neues kommen.

[robbitop]

geringe IPC? Wie kommst du darauf? Hast du die IPC mal mit Bulldozer verglichen?
Wenn dann mit Steamroller. Wir sind ja nicht mehr im Jahre 2011. Das letzte Mal, als ich nachgeschaut habe, war Piledriver aktuell. Und dieser hatte eine höhere IPC.
Ich sehe auch keine Gründe, warum Jaguar eine höhere IPC haben sollte.

Die IPC von Jaguar ist für den Formfaktor schon OK. Aber für 10-100 W ist sie niedrig. Die von Kaveri ist es ebenfalls. Viel zu niedrig. Da müssen ~50 % oben drauf kommen.

Außerdem ist Jaguar durch und durch für niedrige Leistungsaufnahme ausgelegt. Das kann man nicht mal eben aufblasen.

AMD spart gewaltig Geld, warum sollen Sie weiterhin unnötig investieren wenn sich damit kaum Geld verdien lässt, die OEMs sind von nichts beeindruckt was AMD liefert, weil Intel der Geldgeber ist...
Mit Nichtstun verdient man jedoch noch weniger Geld. Entwicklung von CPUs (jetzt im Umfeld von APUs) ist AMDs Kerngeschäft. Ein Stopp von Weiterentwicklungen wäre der Todesstoße und käme dem Werfen der Flinte in's Korn gleich.

Zu K10 Zeiten hatte AMD auch den schlechteren Kern. Aber nicht so viel schlechter als jetzt. Damals hat man doch noch etwas mehr verdient.

[Duplex]

Es hat ja niemand gesagt das alles gestoppt wird ;)

In 14XM wird AMD vermutlich bei den APUs 4 Module / 8 Kerne mit 1024 GPU Shader anbieten.
Zusätzlich wird man dann von Architektur Verbesserungen sprechen, z.b. doppelter FPU Durchsatz und doppelte GPU Performance...

Was anderes kann ich mir nicht vorstellen.

[Ravenhearth]

Große Probleme liegen auch beim Uncore-Teil sowie den Caches (wobei der L3 afaik ja zum Uncore gehört). Der NB-Takt ist einfach viel zu niedrig, wie Messungen mit FX-CPUs sowie APUs zeigen. Das dürfte den CPU-Part deutlich bremsen, hier wären vielleicht 10-20% mehr Leistung drin. Und die L2- sowie L3-Caches sind auch saulahm, was Latenzen angeht. Würde AMD diese Sachen angehen (neuer Uncore?), sähe es wohl teilweise deutlich besser aus. Insgesamt wären vielleicht 20-30% mehr Leistung drin, und das ist eine ganze Menge für solch "einfache" Optimierungen.

[robbitop]

Nicht schon wieder... Das ist noch gar nicht vernünftig erwiesen. Kaveri profitierte in wenigen gemessenen synthetischen Spezialfällen davon. Es gab ganze 4 synthetische Messungen durch eine einzige Person.

IIRC profitierte der FX Bulldozer/Vishera sogar in Spielen - das lag allerdings an der L3 Anbindung. Die großen Sprünge waren dort aber auch nicht durchgehend vorhanden, sondern auch nur in einigen Spielen.

[HOT]

Na ja, bei einem neuen FX, bei dem die XBar 8 Module, 8MB L3-Cache, 3x 16Lanes PCIe3+2HTc-Links und 256Bit DDR4-Speicher verwalten muss, wird man schon darauf achten, dass der Durchsatz entsprechend ist... Takt und Design werden da schon passen, das ist was ganz neues. Da kann man keine bisher verwendete Technik für nutzen, das ist unzureichend.

Den 32nm BDs fehlt mMn ULK, was zu sehr niedrigen L3-Takten führt. Der I/O-Kram war ursprünglich sicherlich nicht für nur 2,2GHz geplant.

[Thunder99]

Eine 2.A64 Ära wird es wohl nicht mehr geben. Da ist Intel mittlerweile zu gut aufgestellt :(

Server Geschäft ist noch nicht Tod aber ihre Produkte performen zu schlecht für die meisten Kunden :(

[robbitop]

Na ja, bei einem neuen FX, bei dem die XBar 8 Module, 8MB L3-Cache, 3x 16Lanes PCIe3+2HTc-Links und 256Bit DDR4-Speicher verwalten muss, wird man schon darauf achten, dass der Durchsatz entsprechend ist... Takt und Design werden da schon passen, das ist was ganz neues. Da kann man keine bisher verwendete Technik für nutzen, das ist unzureichend.

Den 32nm BDs fehlt mMn ULK, was zu sehr niedrigen L3-Takten führt. Der I/O-Kram war ursprünglich sicherlich nicht für nur 2,2GHz geplant.


Wenn man ihn neu designt. Ist denn davon schon was absehbar. Warsaw könnte ja auch einfach nur ein Vishera mit erhöhten Taktraten sein. 32 nm SOI, Piledriverkerne...klingt nach Vishera.
Ist IMO fraglich, ob AMD nochmal einen neuen FX bringt. Wer soll den schon kaufen? Selbst der wäre nicht wirklich konkurrenzfähig. Die Bewegung mit den Kaveri APUs in den mobilen Sektor ergibt Sinn. Dort ist mehr Geld zu verdienen und gerade da gab es bei Kaveri gute Verbesserungen.

Eine 2.A64 Ära wird es wohl nicht mehr geben. Da ist Intel mittlerweile zu gut aufgestellt :(



Zustimmung. Die gab es ja nur, weil Intel mal ein paar Jahre gepennt hat. Intel ist aber jetzt einfach zu gut in der Execution und bringt ihren Ressourcen- und Fertigungsvorsprung nun pünktlich wie ein Uhrwerk jedes Jahr auf die Straße. Außerdem ist Intel schon ziemlich weit am oberen Ende des Machbaren was Singlethread IPC angeht. Was soll da noch deutlich drüber kommen?

AMD hat aber zumindest eines: viel Raum zur Verbesserung. :D

[HOT]

Klar muss man den Uncore neu designen. Wie soll man bisherige Uncore-Technik mit 8 Modulen und PCIe betreiben? Das geht nicht.
Warsaw ist sicherlich ein ULK-Vishera, damit man die Spannung senken kann und den Takt bei den 16-Thread-CPUs auf über 3GHz bekommt, darum wirds bei Warsaw letztendlich gehen. Vielleicht fällt da noch eine mehr oder weniger komplette FX9-Serie ab.

Von der Singlethread-IPC würd ich mich bei BD-Derivaten verabschieden. Das wird nichts mehr, es wird aber auch immer irrelevanter. Als BD-Nachfolger wird man sicherlich ganz andere Wege beschreiten. Natürlich kann es einen "2.Frühlung" geben, aber dafür ist Kreativität gefragt. Das Potenzial ist da.

[mboeller]

Wenn dann mit Steamroller. Wir sind ja nicht mehr im Jahre 2011. Das letzte Mal, als ich nachgeschaut habe, war Piledriver aktuell. Und dieser hatte eine höhere IPC.
Ich sehe auch keine Gründe, warum Jaguar eine höhere IPC haben sollte.

Hast du schon mal CB 11.5 64bit Multi zw. einem A6-5200 und einem A10-5750M verglichen? Ich weiß CB ist nicht gerade die Paradedisziplin vom Bulldozer + Derivaten wegen dem Modulkonzept. Aber trotzdem erstaunlich was so ein kleiner 3mm² "großer" Kern alles leisten kann.

...und Beema legt noch einiges drauf, nicht nur bei der Leistung pro Watt sondern auch bei der allgemeinen Leistung.

Ein Highend Jaguar od. Beema Kern wäre natürlich größer. Aber selbst wenn du die Größe verdoppelst und den Cache ein wenig größer auslegst damit er Leistungsfähiger ist könntest du ein 4-core-Modul mit max. 3 - 3,5GHz wahrscheinlich immer noch in ~40mm² unterbringen (ist beim Jaguar so 25 od. 26mm² groß).

[Duplex]

Die NB von Bulldozer stammt ursprünglich vom K10 ab, da wurde lediglich ein Redesign durchgeführt.

[robbitop]

Hast du schon mal CB 11.5 64bit Multi zw. einem A6-5200 und einem A10-5750M verglichen? Ich weiß CB ist nicht gerade die Paradedisziplin vom Bulldozer + Derivaten wegen dem Modulkonzept. Aber trotzdem erstaunlich was so ein kleiner 3mm² "großer" Kern alles leisten kann.

...und Beema legt noch einiges drauf, nicht nur bei der Leistung pro Watt sondern auch bei der allgemeinen Leistung.


Cinebench ist ein Synthie, der einfach SIMD Code durch die FPU bläßt. Je breiter die FPU, desto besser ist das Ergebnis. Das hat IMO mit genereller IPC nichts zu tun.

BD hat pro Modul nur 1x FPU. Man müsste eher eine Wald und Wiesen Applikation, die nur einen Kern nutzt, testen.

Beema soll ja angeblich nur ein Jaguar Respin auf dem GF Prozess sein. Also keinerlei IPC Steigerungen.

Ein Highend Jaguar od. Beema Kern wäre natürlich größer. Aber selbst wenn du die Größe verdoppelst und den Cache ein wenig größer auslegst damit er Leistungsfähiger ist könntest du ein 4-core-Modul mit max. 33,5GHz wahrscheinlich immer noch in ~40mm² unterbringen (ist beim Jaguar so 25 od. 26mm² groß).

Als wenn das so einfach gehen würde. Jaguar ist konsequent auf Low Power und geringe Größe optimiert. Das kannst du nicht hochskalieren. Da musst du alles neu machen. Gehst du auf höhere Taktraten und höhere IPC explodiert die Kerngröße und die Leistungsaufnahme. Das ist nunmal so.

[Duplex]

In 16FineFET könnte ich mir 8 Jaguar Kerne mit 256 Bit FPU & Dual Channel DDR4 vorstellen.

[mboeller]

BD hat pro Modul nur 1x FPU. Man müsste eher eine Wald und Wiesen Applikation, die nur einen Kern nutzt, testen.


1 256bit FPU mit FMA (also 4-8 DP-FLOPs pro cycle pro Modul). Jaguar kann nur 2x ADD + 1x MUL bei 64bit (also nur 3 DP-FLOPs pro cycle). Deshalb ja der Vergleich bei 64bit und nicht bei 32bit. ...und trotzdem ist der Kabini pro Takt um einiges schneller.

[robbitop]

Unterstützt Cinebench denn FMA? Wenn nicht, ist die FPU halt einfach nur doppelt so breit.

Cinebench ist IMO kein sinnvoller Vergleich für IPC. Das misst einfach nur den Durchsatz der FPU. Das ist nicht sehr praxisrelevant.

[sklave_gottes]

Unterstützt Cinebench denn FMA? Wenn nicht, ist die FPU halt einfach nur doppelt so breit.

Cinebench ist IMO kein sinnvoller Vergleich für IPC. Das misst einfach nur den Durchsatz der FPU. Das ist nicht sehr praxisrelevant.

Theoretisch gesehen hast du recht, aber in der Praxis sieht es leider etwas anders aus. Meisten kommt die Faustformel hin, das die Cinebench Leistung, etwa dem Durchschnitt der Spieleperformants entspricht. So wie es aussieht hat ein Jaguar 4 core Prozessor etwa tatsächlich mindestens die Leistung zweier Steamroller Module pro Takt!

[Gipsel]

Breitere Execution (dicke FPUs, doppelt so viele ALUs), mehr Decoder, superschneller mittelgroßer L1 (~64 kiB), schneller kleiner L2 (~256...512 kiB), immernoch recht schneller aber großer L3.
Dazu Loop stream detector, µ Op instruction Cache, mächtige OoO Execution, so gut wie mögliche Sprungvorhersage, genug Load/Store Units etc.Du weißt schon, daß mit mehr Einheiten bzw. Issue-Ports die Scheduling-Komplexität eponentiell zunimmt und man mehr Ports an den Registerfiles benötigt, was entweder den Stromverbrauch exorbitant steigen läßt oder die möglichen Taktraten massiv einschränkt?
Es hatte schon einen Grund, warum AMD bei K7/8/10 auf getrennte reservation stations für jede ALU/AGU-Pipeline gesetzt hat. Das verschlechtert zwar die Scheduling-Effizienz, war aber offenbar der einzige Weg, wie AMD mit der Anzahl an Einheiten auf den Takt gekommen ist. BD/PD/SR und Jaguar haben ein unified Scheduling wie Intel (bis auf FP), aber beide auch weniger Einheiten. Ich vermute da einfach mal einen Zusammenhang. Ein sehr breiter unified Scheduler für Alles, der sehr viele Instruktionen in flight hält und jeden Takt somit mehr als 100 Instruktionen auf gegenseitige Abhängigkeiten prüfen kann und dabei immer noch mit ~4 GHz taktbar ist, schüttelt man nicht mal so eben aus dem Ärmel. Im Prinzip gibt es nur eine Firma, die das geschafft hat: intel. Noch nicht mal IBM mit seinem stromfressenden Monster namens Power7 geht im Prinzip so weit (der hat von der Zahl der Einheiten eher gutes P6-Level, Anzahl der Ports ist ähnlich zu Haswell und er hat 4 Threads [was die Tests der Abhängigkeiten tendentiell einfacher macht] und anders verteilte Schwerpunkte [4 FPUs, aber auch nur 2 ALUs und 2 AGUs]).

[robbitop]

Theoretisch gesehen hast du recht, aber in der Praxis sieht es leider etwas anders aus. Meisten kommt die Faustformel hin, das die Cinebench Leistung, etwa dem Durchschnitt der Spieleperformants entspricht. So wie es aussieht hat ein Jaguar 4 core Prozessor etwa tatsächlich mindestens die Leistung zweier Steamroller Module pro Takt!
Eigentlich widerlegt spätestens Jaguar dies. Die Spieleleistung stiegt um ein paar Prozent, die Cinebenchleistung dramatisch. FPU doppelt so breit wie bei Bobcat. Würde ich also nicht mehr so unterschreiben wollen.

Du weißt schon, daß mit mehr Einheiten bzw. Issue-Ports die Scheduling-Komplexität eponentiell zunimmt und man mehr Ports an den Registerfiles benötigt, was entweder den Stromverbrauch exorbitant steigen läßt oder die möglichen Taktraten massiv einschränkt. Es hatte schon einen Grund, warum AMD bei K7/8/10 auf getrennte reservation stations für jede ALU/AGU-Pipeline gesetzt hat. Das verschlechtert zwar die Scheduling-Effizienz, war aber offenbar der einzige Weg, wie AMD mit der Anzahl an Einheiten auf den Takt gekommen ist. BD/PD/SR und Jaguar haben ein unified Scheduling wie Intel (bis auf FP), aber beide auch weniger Einheiten. Ich vermute da einfach mal einen Zusammenhang. Ein sehr breiter unified Scheduler für Alles, der sehr viele Instruktionen in flight hält und jeden Takt somit mehr als 100 Instruktionen auf gegenseitige Abhängigkeiten prüfen kann und dabei immer noch mit ~4 GHz taktbar ist, schüttelt man nicht mal so eben aus dem Ärmel. Im Prinzip gibt es nur eine Firma, die das geschafft hat: intel. Noch nicht mal IBM mit seinem stromfressenden Monster namens Power7 geht im Prinzip so weit (der hat von der Zahl der Einheiten eher gutes P6-Level, Anzahl der Ports ist ähnlich zu Haswell und er hat 4 Threads [was die Tests der Abhängigkeiten tendentiell einfacher macht] und anders verteilte Schwerpunkte [4 FPUs, aber auch nur 2 ALUs und 2 AGUs]).
Denver sieht auch ziemlich breit aus und passt sogar in den SFF. IIRC ist Power 8 sogar noch massiv breiter als Haswell.
K7 ist schon ein uraltes Design - und bis zum K10 basierte man ja praktisch noch auf dem K7 Design. Und schleppt dementsprechend Altlasten mit herum.

[Gipsel]

Denver sieht auch ziemlich breit aus und passt sogar in den SFF.Wie sieht Denver denn aus?
K7 ist schon ein uraltes Design - und bis zum K10 basierte man ja praktisch noch auf dem K7 Design. Und schleppt dementsprechend Altlasten mit herum.Tja, und dann schmeißt man mit BD einen halbwegs unified Scheduler in den Mix und schon muß man die Anzahl der Einheiten deutlich einschränken, damit man das Taktziel erreicht. Offenbar ist es nicht so einfach.

Edit:
Etwas überspitzt gesagt, kommt es mir immer ein wenig so vor, als wenn Laien einem Architekten was über die Statik einer Brücke erklären wollen und versuchen ihm zu erklären, wie man eine zugleich tragfähige aber dabei auch leichte Konstruktion hinbekommt ("Aber es müssen da und da noch Streben dazugefügt werden und die Stützen da müssen dünner werden und sowieso macht das andere Architektenbüro [mit 10fachen Resourcen und einem Rechenzentrum zur FE-Simulation des Ganzen] das sowieso viel besser"), ohne sich über den vollen Umfang der Auswirkungen ihrer Vorschläge bewußt zu sein.

[fondness]

Denver ist maximal kreatives zählen mit der 8x(?) superskalaren Architektur.

[robbitop]

Wie sieht Denver denn aus?
IIRC 7 issue. Also sehr breit. Details sind ja noch nicht bekannt. Aber 7 issue schmeist du nicht in den Raum, wenn nicht etwas breites dabei herumkommt.


Tja, und dann schmeißt man mit BD einen halbwegs unified Scheduler in den Mix und schon muß man die Anzahl der Einheiten deutlich einschränken, damit man das Taktziel erreicht. Offenbar ist es nicht so einfach.
Das ist Spekulation. Eine andere Möglichkeit ist, dass AMD schlichtweg eine andere Philosophie mit dem Ansatz "Bulldozer" verfolgt hat.

Edit:
Etwas überspitzt gesagt, kommt es mir immer ein wenig so vor, als wenn Laien einem Architekten was über die Statik einer Brücke erklären wollen und versuchen ihm zu erklären, wie man eine zugleich tragfähige aber dabei auch leichte Konstruktion hinbekommt ("Aber es müssen da und da noch Streben dazugefügt werden und die Stützen da müssen dünner werden und sowieso macht das andere Architektenbüro [mit 10fachen Resourcen und einem Rechenzentrum zur FE-Simulation des Ganzen] das sowieso viel besser"), ohne sich über den vollen Umfang der Auswirkungen ihrer Vorschläge bewußt zu sein.
Dass das nicht so einfach ist, ist mir klar. Deshalb habe ich das ein paar Posts vorher ja bereits dargestellt. Deine latente Überheblichkeit kannst du also stecken lassen.

Es gibt ein paar Indizien, dass AMD ein IPC stärkeres Design schaffen müsste. Bspw. ist man mit einem mittlerweile (schaut man auf die K7 Wurzeln zurück) 14 Jahre alten Design bei Wald und Wiesen Code nicht langsamer als mit BD. Und BD verwendet eben schon einige der neusten Tricks, um nochmal einiges an IPC herauszuholen. Es muss also besser gehen bei AMD.
Dass es nicht vergleichbar ist mit einem Intel Core, ist klar.

Intels Core ist ja seit Nehalem auch schon wieder einige Iterationen gereift. Ggf. kann man immerhin Nehalem IPC schaffen. Das wäre doch schonmal was.

[sklave_gottes]

Ein schöner Test von Kabini vs Zacate vs Richland:
http://adrenaline.uol.com.br/biblioteca/analise/784/amd-a6-5200-kabini.html?pg=1

Hier wurde auch mal mit einer externen Grafikarte(GeForce GTX 680) getestet.
Leider mit zu hohem GPU Limit.

Aber man kann durchaus schon erahnen wie stark die Jaguar IPC wirklich ist im vergleich zu BD und das selbst mit nur einem Riegel.

mfg Martin

[robbitop]

Guter Fund!

http://adrenaline.uol.com.br/biblioteca/analise/784/amd-a6-5200-kabini.html?&pg=4

Taktnormiert 1,3 fache Spieleleistung für Richlamd ggü Jaguar. Kaveri ist nochmal 6-7 % schneller. Ich wüsste auch nicht, warum Jaguar eine höhere Spiele IPC haben sollte.

[AnarchX]

Auf Seite 4 sind Tests der iGPUs. Die Ergebnisse auf Seite 5 sind relevant, da dort alle CPU die GTX 680 verwenden. Wobei Zacate wohl zusätzlich durch das Threading-Problem des NV-Treibers (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=548782) eingebremst wird.

[Gipsel]

IIRC 7 issue. Also sehr breit. Details sind ja noch nicht bekannt. Aber 7 issue schmeist du nicht in den Raum, wenn nicht etwas breites dabei herumkommt.Qualcomms Krait hat auch 7-issue Ports und ist leicht langsamer als ein A15 pro MHz. Ein K7 ist 9-issue und definitiv langsamer als ein 5-issue Nehalem oder Sandy-Bridge. Und den intern im Prinzip 8-issue Transmeta Efficeon erwähne ich auch mal (wegen des Codemorphing-Ursprungs des Denver, sowohl der Efficeon als auch Denver haben übrigens 128kB L1-I-Cache, Zufall oder nur so groß, weil VLIW-Instruktionen generell eine schlechtere Codedichte aufweisen?). Das alleine sagt erstmal gar nichts. Ich habe nicht umsonst auf das Problem eines guten und breiten Schedulers hingewiesen. ;)
Das ist Spekulation.Die mit der beobachteten Realität konsistent ist. Deine Vorstellung ist dagegen Wunschdenken. Und sorry, wenn Du das als Überheblichkeit ansiehst, in meinen Augen ist es Realismus.

Sicher kann AMD mit ein paar Jahren Vorlaufzeit ein Design mit höherer IPC als mit BD/PD/SR schaffen (dazwischen gibt es ja auch doch signifikante Steigerungen, man kann also zum einen einen weiteren Fortschritt mit Excavator als auch mit späteren Designs erwarten). Aber jetzt irgendwie Reden zu schwingen, AMD hätte das und das machen sollen, das ist auf eine gewisse Weise überheblich ;).
Wenn man die Grundlagen für ein Design festzurrt (sagen wir mal 5 Jahre, bevor es auf den Markt kommt), muß man zwingend bestimmte Annahmen über zukünftige Entwicklungen machen. Die können sich im Nachhinein immer als besser oder schlechter zutreffend herausstellen ("hindsight is 20/20" aka hinterher ist man immer klüger). Und bei seinen Planungen, muß man auch immer im Kopf behalten, was man mit den verfügbaren Resourcen überhaupt schaffen kann.

AMD war ganz offenbar der Überzeugung, mit dem K7-Design langsam am Ende angelangt zu sein, hat ja auch lange genug durchgehalten. Sie waren willens, einen moderneren Ansatz zu verfolgen (unified scheduler, PRF), haben dafür aber ganz offensichtlich Kompromisse machen müssen, wodurch das Design zwingend schmaler wurde. Auch die physische Trennung der beiden Integer-Kerne (im Gegensatz zu intels SMT) führt ja letztendlich dazu, daß für vergleichbare pro-Thread-Performance, schmalere Scheduler/weniger Einheiten pro Kern ausreichen. Diese Entscheidung wurde vermutlich schon vom Bewußtsein mitgetragen, daß man auf dem Gebiet mit Intel schwer konkurrieren kann. Es wäre AMD ja nicht geholfen gewesen, wenn Sie ein 8 issue-Design hinknallen, was mit sagen wir mal maximal 2,5 GHz läuft, 100W zieht und trotzdem größer ist als jetzt ein BD-Modul, was bei 4GHz die gleiche ST-Performance schafft und MT schneller ist. Und in genau diese Abwägungen hat keiner von uns hier einen Einblick. Sicher kann man bestimmte Dinge zumindest ansatzweise erahnen/erfassen, aber ich maße mir nicht an, inquisitorisch darüber zu urteilen.

[sklave_gottes]

Guter Fund!

http://adrenaline.uol.com.br/biblioteca/analise/784/amd-a6-5200-kabini.html?&pg=4

Taktnormiert 1,3 fache Spieleleistung für Richlamd ggü Jaguar. Kaveri ist nochmal 6-7 % schneller. Ich wüsste auch nicht, warum Jaguar eine höhere Spiele IPC haben sollte.

Das liegt doch nur an der IGPU, eine Seite weiter sind test mit der GTX und dort liegt Jaguar quasi Gleichauf. Wobei hier wahrscheinlich die GPU limitiert. Schade das keine low qualiti Test gemacht wurden.

[robbitop]

Auf Seite 4 sind Tests der iGPUs. Die Ergebnisse auf Seite 5 sind relevant, da dort alle CPU die GTX 680 verwenden. Wobei Zacate wohl zusätzlich durch das Threading-Problem des NV-Treibers (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=548782) eingebremst wird.

Super Test. Die Dinger laufen im GPU Limit. Also nichtssagend. :(

Das liegt doch nur an der IGPU, eine Seite weiter sind test mit der GTX und dort liegt Jaguar quasi Gleichauf. Wobei hier wahrscheinlich die GPU limitiert. Schade das keine low qualiti Test gemacht wurden.

Ja habe ich übersehen. Die Sprache des Artikels ist mir leider völlig fremd.

[samm]

Das liegt doch nur an der IGPU, eine Seite weiter sind test mit der GTX und dort liegt Jaguar quasi Gleichauf. Wobei hier wahrscheinlich die GPU limitiert. Schade das keine low qualiti Test gemacht wurden.Zeigt jedenfalls, dass es je nach Spiel auch bei "nur" 1080p mit einer potenten Karte wie der GTX 680 bereits dazu kommt, dass ein absoluter Low-Cost-Prozessor mit Jaguar-Kernen nicht mehr hauptsächlich limitiert.

[Skysnake]

Tja und da schreien die Leute immer nach absoluten Lowres CPU Benches, weil man ja nur da sehen kann, wie schnell die CPU ist :rolleyes:

Klar kann man das, aber wie stark man die CPU überhaupt auslastet sieht man halt nicht, und so einfach hochskalieren wie das immer gesagt wird, kann man auch nicht immer. Hängt ja immer ganz davon ab, was denn nu am Ende wirklich jeweils limitiert.

Unterstützt Cinebench denn FMA? Wenn nicht, ist die FPU halt einfach nur doppelt so breit.

Cinebench ist IMO kein sinnvoller Vergleich für IPC. Das misst einfach nur den Durchsatz der FPU. Das ist nicht sehr praxisrelevant.
Für HPC wäre ne doppelt so breite FPU aber richtig geil, wenn man sie denn füttern könnte.

Ich seh AMDs FPU eher als zu schwach an in BD. Im Prinzip haben sie mit der Flex-FPU ja das Potenzial Intel nass zu machen, wenn man sehr assymmetrische FPU-Lasten hat. Intel ist da mit seinem Design etwas unflexibler als AMD in meinen Augen.

Gerade wenn die FPU doppelt so breit wäre, würde sich das noch massiv ausbauen, und die ISA ist ja wirklich was ganz ganz feines! AMD hat wirklich so manche sinnvolle Sache mit drin, die Intel erst jetzt gebracht hat.

Die aktuelle FPU macht diesen Vorteil am Ende dann aber doch wieder kaputt :( AMD ist pro Modul nicht stärker bei AVX als Intel. Wirklich schade eigentlich. Hier hätte man echt potenzial gehabt.

[N0Thing]

Tja und da schreien die Leute immer nach absoluten Lowres CPU Benches, weil man ja nur da sehen kann, wie schnell die CPU ist :rolleyes:

Klar kann man das, aber wie stark man die CPU überhaupt auslastet sieht man halt nicht, und so einfach hochskalieren wie das immer gesagt wird, kann man auch nicht immer. Hängt ja immer ganz davon ab, was denn nu am Ende wirklich jeweils limitiert.

Macht schon Sinn. 1080p ist ja keine niedrige Auflösung. Andersherum testet ja auch niemand eine R290x oder GTX 780Ti mit einem Intel Atom, nur um dann festzustellen, daß die genauso flott sind wie eine 8800gt. Bei einem CPU-Test ist das dann aber realistisch. :freak:

[robbitop]

Die Benchmarks sind jedenfalls nutzlos.

[Skysnake]

Macht schon Sinn. 1080p ist ja keine niedrige Auflösung. Andersherum testet ja auch niemand eine R290x oder GTX 780Ti mit einem Intel Atom, nur um dann festzustellen, daß die genauso flott sind wie eine 8800gt. Bei einem CPU-Test ist das dann aber realistisch. :freak:
Das Problem ist halt, dass diese Benches fern ab der Realität immer schwer zu deuten sind.

Die Gewichtungen können sich halt arg verschieben. Wenn z.B. einfach gewisse Latenzen nicht erreicht werden, und man nicht schafft die Pipeline zu füllen oder beim einen der Cache nicht mehr überläuft, beim anderen aber schon, dann verzerrt das ganz schnell extrem, und man kann halt auch nur schwer sagen, wie das ganze dann abläuft, wenn man wirklich mehr Leistung braucht.

Klar, es ist ein Fingerzeig, welche Architektur an sich wohl leistungsfähiger ist, in eben dieser Situation, aber ob man dann wirklich am Ende auch genau das zu sehen bekommt ist halt die Frage.

[HOT]

Macht schon Sinn. 1080p ist ja keine niedrige Auflösung. Andersherum testet ja auch niemand eine R290x oder GTX 780Ti mit einem Intel Atom, nur um dann festzustellen, daß die genauso flott sind wie eine 8800gt. Bei einem CPU-Test ist das dann aber realistisch. :freak:

Der Treiber könnte bei einer 780Ti einen Atom überlasten, das darf man nicht außer Acht lassen. Wenn man sowas testet, muss der Grafikchip im Rahmen bleiben.


Diese Jaguar-Diskussion ist schon wieder unsäglich "einen 8 Kern Jaguar mit doppelt so vielen Einheiten blablabla"... Das geht einfach nicht. AMD hat nicht umsonst einen Steamroller und Excavator entwickelt. Wenn man einfach Jaguar als Basis nehmen könnte hätte man es sicherlich getan. Das passt aber nicht. 40h (Excavator) wird sicherlich eine doppelt so breite FPU haben, AVX2 beherrschen und vllt. gibts endlich den Trace-Cache. Damit wäre er ziemlich akzeptabel, auch ohne tolle IPC.
Bei der nächsten Architektur wird man sich sicherlich die Int-Cluster vornehmen und das Frontend für die GPU öffnen.

[robbitop]

IMO muss AMD an die Caches ran. (was sie ja z.T. getan haben)
Die Zugriffszeiten müssen einfach nochmal deutlich sinken. Das bringt bei Wald und Wiesen Code aus Erfahrung immer eine ganze Menge.

[Undertaker]

Diese Jaguar-Diskussion ist schon wieder unsäglich "einen 8 Kern Jaguar mit doppelt so vielen Einheiten blablabla"... Das geht einfach nicht. AMD hat nicht umsonst einen Steamroller und Excavator entwickelt. Wenn man einfach Jaguar als Basis nehmen könnte hätte man es sicherlich getan. Das passt aber nicht.

Allein schon, weil die Taktbarkeit bei Jaguar nicht gegeben ist. Die gute IPC nützt nix, wenn man nicht nennenswert über 2 GHz hinauskommt.

[sklave_gottes]

@robbitop

Ja so leider schon, ich werde mal versuchen einen Jaguar x4 zu besorgen um den dann mit einem BD bei "Wald und Wiese" zu vergleichen. Natürlich bei möglichst hohem CPU limit ;-) .

Allein schon, weil die Taktbarkeit bei Jaguar nicht gegeben ist. Die gute IPC nützt nix, wenn man nicht nennenswert über 2 GHz hinauskommt.

Du sagst es so, als ob es eine Tatsache wäre. Dabei ist es nur Spekulation oder? Es liegt vieleicht nahe das Jaguar keine hohen Takte schaft, trotzdem sollten wir bedenken das die 2Ghz@25Watt sind. Bis 95Watt ist es noch ein weiter Weg.....

[HOT]

Jaguar wird ein Niedrigtaktdesign sein, also wenig Pipelinestufen mit geringen Latenzen. Auf 3GHz+ bekommt man die (normal) nicht. Das ist übrigens mit ein Grund für die "gute" IPC. IPC ist aber eben einfach nicht alles.

[S940]

Jaguar wird ein Niedrigtaktdesign sein, also wenig Pipelinestufen mit geringen Latenzen. Auf 3GHz+ bekommt man die (normal) nicht. Das ist übrigens mit ein Grund für die "gute" IPC. IPC ist aber eben einfach nicht alles.
Rein von der Stufenanzahl ist Jaguar schon ziemlich lang, 13-14 Takte (für INT) sind nicht gerade low-clock:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1346188254

Das Design an sich sollte also nicht soo schlecht skalieren. 4 GHz ganz sicher nicht, aber so 3++ sollten mit nem (S)HP Prozess schon machbar sein.

[reaperrr]

Jaguar wird ein Niedrigtaktdesign sein, also wenig Pipelinestufen mit geringen Latenzen.
Das traf auf K8 (vor Brisbane...) ebenfalls zu. Hat trotzdem am Ende immerhin 3,2 GHz erreicht.

[S940]

Du findest eine IPC, die 50 % geringer ist als die des Mitberwerbers "ok"? Deine Ansprüche möchte ich haben. :D
Sehs mal in Relation zu den Gewinnen der beiden Unternehmen, dann siehst Dus auch so ;-)

Das ist so ungefähr wie Fan eines schwerreichen Scheich-Fussballclubs zu sein. Geht auch, aber wenn die gut spielen erfüllen sie nur ihr Soll, bei dem Geld wundert sich keiner über die Leistung. Wenn dagegen ein Hungertuchverein wie AMD was Brauchbares auf die Beine stellt, muss man das schon mal anerkennen :)

Schon mit nem Richland@4,5 GHz konnte man mit ner dezidierten GraKa brauchbare FPS erzeugen, das wurde jetzt garantiert nicht schlechter und Mantle kommt auch noch.

[Undertaker]

Das Design an sich sollte also nicht soo schlecht skalieren. 4 GHz ganz sicher nicht, aber so 3++ sollten mit nem (S)HP Prozess schon machbar sein.

Ohne tiefgreifende Änderungen imo sehr unwahrscheinlich. Das geht doch schon bei den Cache-Latenzen los... Oder anders gesagt: Wenn AMD ein low-power- und low-cost-Design (-> Die-Size) so auslegt, dass auch weitaus höhere Frequenzen möglich sind, wäre der Chip ziemlich wiederum schlecht auf seinen eigentlichen Arbeitspunkt um 1,0-1,5 GHz optimiert.

[N0Thing]

Das Problem ist halt, dass diese Benches fern ab der Realität immer schwer zu deuten sind.

Ne, eigentlich sind die am einfachsten zu deuten, weil man genau sehen kann wann und worin eine CPU gut ist.
Schwierig wird es, wenn man externe limitierende Faktoren wie eine zu langsame Grafikkarte oder hohe Grafikeinstellungen hinzu fügt und die CPU die halbe Zeit nur Däumchen dreht.

Daß ein wenig Hirnschmalz notwendig ist, um die Ergebnisse mit niedriger Auflösung auf reale Situationen zu übertragen ist klar. Anders herum ist es aber gar nicht möglich.
Wie gesagt, es interessiert sich ja auch niemand für GPU-Tests im CPU-Limit, nur weil es eine realistischere Situation darstellt. ;)

[Skysnake]

Und wer sagt dir, dass der TLB nicht ungeschickt ist, oder dir die leer laufende Pipeline voll rein haut, oder dir halt der Threadwechsel ungemach macht usw usw.

Ne CPU läuft halt nicht mehr straight forward. Du hast echte Parallelität. Wenn die FPS hoch gehen, werden Latenzen wichtiger im Vergleich zum Durchsatz.

Es verschieben sich halt die Grenzen. Auch der API-Overhead killt dich eher. Vor allem wenn du blockierende Aufrufe drin hast.

Wenn was bei 60 FPS gut geht, muss das bei >>100 FPS nicht noch immer richtig gut gehen.

Caches sind doch das beste Beispiel. Bei höheren FPS wird der Cache schneller getrashed. Je nachdem halt zu schnell um die Daten noch drin zu haben die nen anderer Thread braucht. Dann musste es erneut laden usw.

Wenn alle Befehle die gleiche Latenz hätten, immer alles genau nach der gleichen Anzahl an Takten gesheduld werden würde, man immer die gleiche Anzahl an sinnfreien Takten hätte usw usw. Ja dann könnte man das einfach interpolieren, aber allein nen Thread der bussy waiting macht hat dir halt schon alles kaputt.

Wenn das immer alles so einfach wäre, wie es dargestellt wird, dann hätten wir heutzutage schon viel mehr viel besser skalierende Software ;)

[Knuddelbearli]

oder der eDRAm ( bei Intel ) bei höheren Auflösungen dann nicht zu klein ist und massiv einbricht

[Skysnake]

Kann auch passieren, darum gehts aber gar nicht.

Spiele sind nen ziemlich komplexes Stück Software, das sowohl I/O, Memory als auch ALUs sehr unterschiedlich auslasten. Da irgendwas interpolieren zu wollen für die Zukunft ist halt schon gewagt.

Klar, es ist ne Tendenz/Fingerzeig, aber wie was dann am Ende wirklich performt, muss man sich einfach wirklich genau den Settings anschauen, die man fahren will. Alles andere ist halt nur PimalDaumen.

[S940]

Doch nichts mehr (zumindest 2019):
AMD: 2019 dominieren kleine, sparsame X86-Kerne: Das Ende von Bulldozer? | Planet 3DNow! (http://www.planet3dnow.de/cms/7741-amd-2019-dominieren-kleine-sparsame-x86-kerne-das-ende-von-bulldozer/).

[Tobalt]

Naja, in der gleichen Folie steht immerhin in der Überschrift:

One size fits all computing is dead

Könnte auch heißen, dass man wie schon auch jetzt einfach weiterhin verschiedene Chips für verschiedene Anwendungen liefert.

[HOT]

Also daraus das Ende für BD abzuleiten ist gewagt.
BD ist ja sowieso schon eher ein Schritt in Richtung dieses Minimalsmus. Die Recheneinheiten sind eher begrenzt designt, nur das Frontend+Caches sind wirklich fett. Da kann man auch hineininterpretieren, dass die CPUs nicht viel dicker werden, nur kleiner. Das zeichnet sich bei Intel ja auch ab. Ich glaub da wird einfach zu viel reininterpretiert in die Folie. Die sagt ja eigentlich nur aus, dass man keinen "Super-Kern" designt. Das war vorher schon klar.
Ich glaube auch, dass Jaguar usw. nur eine Episode sind, bis die "echten" x86er klein und sparsam genug sind. Ich mein, das passiert ja eh zwangsläufig durch Verkleinerung, Optimierung und neue Fertigungstechniken.

[Zero-11]

Nach Steamroller hat man ja gesehen was aus der Bulldozer Architektur rauszuholen ist da wird Excavator genau 0% höhere IPC bringen. AMD konzentriert sich eh nicht mehr auf den x86 Teil.

[robbitop]

Abwarten. Steamroller wird offenbar durch den Uncore zurückgehalten. y33h@ (Golem Redakteur) hat ein paar Messungen bei 2 GHz durchgeführt (um diese Limitierung aufzuheben) und da ergab sich ein deutlich anderes Bild. Steamroller ist offenbar doch ein ganzes Stück schneller als BD/PD und sogar als K10 Husky Cores (bei gleichem Takt).
Excavator wird vermutlich die FPU verdoppeln und den Uncore Bereich neu designen. Da könnte am Ende doch schon etwas bei rumkommen...

[Knuddelbearli]

Link zum Test?

[Locuza]

http://www.golem.de/news/test-amd-kaveri-a8-7600-die-45-watt-wohnzimmer-apu-1401-103846-3.html

Bei Excavator steht greater performance und die FPU wird auf 256-Bit Pipes aufgebohrt.
Mehr ist wohl auch nicht gesichert.
AMD wird wohl seinen Grund haben die Northbridge weniger hoch zu takten.
Ich persönlich würde da keine große Veränderung erwarten.

[Gipsel]

Doch nichts mehr (zumindest 2019):
AMD: 2019 dominieren kleine, sparsame X86-Kerne (http://www.planet3dnow.de/cms/7741-amd-2019-dominieren-kleine-sparsame-x86-kerne-das-ende-von-bulldozer/)Im Server-Bereich. Darüber sprach die Präsentation.