AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

[Schaffe89]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Ohje, das ist ja noch Richland. Na dann nehm ich meine Aussage von vorher zurück.
Kann sich AMD in die Haare schmieren.

Was die Gerüchte nährt, dass Kaveri noch gar nicht richtig läuft, bzw die fertigung recht schlecht geht.
Kaveri ist jetzt 2 Monate da und ich sehe keine 65 Watt TDp Variante die kaufbar ist, noch sehe ich irgendwelche Ankündigungen für Notebooks.

 

[Homerclon]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Da soll mal einer durchsteigen.. Kaveri, Kabini, Steamroller, Vishera, Piledriver.. Dafuq?

Hat jemand mal n netten Link für mich, wo man das übersichtlich mal präsentiert bekommt, sodass ich das verstehen kann?

Naja, solange es Intel gibt, bleibe ich eh da

Kaveri, Kabini und Vishera sind Codenamen für Prozessor-Reihen einer Generation. (Kaveri sind Ax-7000 (APUs für FM2+), Kabini sind die neuen Low-End-APUs (als SoC(?) und für AM1), Vishera sind die FX-x300 (CPUs für AM3+)) Die gerade jeweils aktuellsten ihrer Produktklasse.
Steamroller und Piledriver sind Architekturbezeichnungen der aktuellen Modul-Architektur von AMD. Angefangen hat es mit Bulldozer, gefolgt von Piledriver und aktuell ist Steamroller die neuste Variante.

Was bei AMD Piledriver und Steamroller sind, sind bei Intel Ivy Bridge und Haswell. (Um mal nur die letzten beiden Generationen zu nennen.)

 

[Deathseal]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Das scheint als hätte AMD das High End Segment für Gamer fallen gelassen. Ich glaube dann wird Intel noch länger warten mit der neuen CPU Generation. Und wird das Monopol hier weiter ausbauen. Schade ich hatte gehofft AMD Lässt endlich den Hammer fallen. Am besten AM3+ mit 4/8 Jaguar Modulen @ 4GHz oder mehr. Ich wünsche mir echt ein COMEBACK von AMD in diesen Bereich.

 

[M4xw0lf]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Tja, in dem man diesem Prozessor das FX-Attribut verpasst, suggeriert man aus Marketing-Gründen hohe Leistung, dafür wird der Ruf der wahren Piledriver-FX Prozessoren gemindert.

Damit das funktioniert, müsste es erstmal irgendwelche FXe mit hoher Leistung geben...

 

[Oromis16]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Von welchem Geld? AMD hat im Prozessorengeschäft kaum eine Wahl. Kein Geld == Keine großartige Entwicklung. Immerhin hat das letzte Quartal 80 Millionen Gewinn gebracht. Ich hoffe, dass jeweils 26 davon ins Marketing, in Excavator und in Pirate Islands geflossen sind^^
AMD hat auch viele Zwickmühlen offen. AMD muss einerseits mit den Prozessoren wieder richtig Geld verdienen. Andererseits darf AMD die Grafikkarten nicht vernachlässigen. Und GloFo sitzt im Nacken und sagt: "Kauf oder du zahlst extra".
Und mit "High End" Chips verdient man kaum Kohle, sofern man nicht den Sprung auf die "Oberste Serverebene schafft". Und das kostet dann noch mehr.

Achtung, das folgende ist nur MEINE Meinung, und dementsprechend sehr subjektiv:
AMD hat diesbezüglich einen in meinen Augen genialen Versuch gestartet. AMD holt den Prügel raus und sagt das, was gesagt werden muss: Grafikkarten können mehr. AMD versucht sozusagen den "High End" Prozessor in den Hintergrund zu schieben. Man muss sich zum Beispiel mal Raytracing anschauen. Da fahren Grafikkarten im Standgas und überholen doppelt so teure Prozessoren ohne zu überlegen.

 

[Palmdale]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Das scheint als hätte AMD das High End Segment für Gamer fallen gelassen. Ich glaube dann wird Intel noch länger warten mit der neuen CPU Generation. Und wird das Monopol hier weiter ausbauen. Schade ich hatte gehofft AMD Lässt endlich den Hammer fallen. Am besten AM3+ mit 4/8 Jaguar Modulen @ 4GHz oder mehr. Ich wünsche mir echt ein COMEBACK von AMD in diesen Bereich.

quoted for truth. Wie schon thehate91 schrieb:

Schade das AMD kein richtigen FX rausbringt. 6 bis 8 Steamroller-Kerne inkl L3 Chace (und kleiner igpu) sollte doch möglich sein. Ich glaube nämlich das sich das einige wünschen würden.

Genau das wünsche ich als Konkurrenzprodukt zu Intel. Wayne iGPU auf unnützem Mittelmaß, schmeißt das Ding raus, reine CPU und gut is! Bis dahin genügt auch die HD4xxx von Intel fürs Office...

Leider hab ich keinen Einblick darin, ob sich dieser Markt für Gamer mit dedizierten Grafikkarten und entsprechendem Bedarf an hoher Prozessorleistung überhaupt rentiert? Denn AMD entwickelt ja zunehmend für Mainstream, sprich allinone Geschichten, wo man zwar Marge hat, mir aber am Allerwertesten vorbeigeht -.-

 

[Oromis16]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Der Markt mit den aktuellen APUs rentiert sich auf jeden Fall, sofern die Speicherlimitierung wegfällt. Die GPU von Kaveri entspricht doch einer 7770 wenn ich mich recht erinnere (Wenn ich mich irre: Bitte korrigiert mich!). Im "Normalmarkt" ist ne 650Ti schon sozusagen "High End", und die 7770 ohne Speicherlimitierung liegt nur ~10% hinter dieser. Und mit Carrizo wird das nochmal schöner, da wird dann Pirate Islands integriert, und der 28nm Prozess sollte ausgereifter sein.
Also bekommt man als Kunde einen "Uno Normalnutzer High End Chip", für ~150€, der so viel leistet wie ein Prozessor für 100€ und eine Grafikkarte für 100€.

High End Chips sind halt in 1. Linie Vorzeigeprodukte, damit die Firmen sagen können "wir haben den schnelleren" (auch wenn kaum ein Mann das sagen würde ^^ )

 

[efdev]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

finde ich gut fm2+ ist sowieso der modernere sockel, dann kann am3+ gerne sterbern und alles auf einen sockel.
außerdem kann dann auch keiner mehr wegen "sockel chaos" jammern.

 

[S754]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Mäh. Uninteressant. Ich warte immer noch auf einen 28nm FX als Ablöse für meinen 6800k.

 

[ruyven_macaran]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Ob Designfrage oder sonstwas, Spekulationsraum ist offen (Außer natürlich ein ausgewählter Moderator weiß mehr, aber wenn er mehr wüsste dürfte er es sowieso nicht sagen^^)

Moderatoren wissen, dass die fröhlich brodelnde (und oftmals blödelnde) Gerüchteküche rund um AMD für mehr Moderationsaufwand sorgt, als so ziemlich jede andere Forums-Aktivität (außer vielleicht dem Marktplatz), vermutlich sogar mehr als die 50-75% moderations-freundlichsten Aktivitäten zusammgenommen. Aber sonst wissen wir gar nichts, mit der Redaktionsarbeit haben wir als Moderatoren rein gar nichts zu tun

Schon. Aber ein kleinerer L2 lässt sich in der Regel auch besser auf Bandbreite und Latenzen hin optimieren als ein großer L2 - und da ist aus mehreren Gründen Arbeit nötig:

Stellt sich die Frage, ob es allein die Größe ist, die AMD da bremst. Was ich so an Tests findet, spricht von 18-20 Takten Latenz für die 2 MiB L2. Zum Vergleich: Intel hat zu Penryn Zeiten fette 6 MiB mit 15 Zyklen Latenz gehabt. AMD hat noch irgendwelche weiteren Probleme - und sei es nur Personalmangel, den kompexere Designs mit mehr Cachestufen nicht lindern würden.

- Und noch was: Cache braucht Strom ohne Ende. Es ist zwar nett, dass Teile vom L2 dynamisch abgeschaltet werden können, a) bringt das unter Last herzlich wenig, b) macht es den Cache auch nicht unbedingt schneller, zusätzliche Verwaltungslogik usw.

Im Idle macht sich Cache sicherlich bemerkbar, aber auf dem mobilen Markt hat AMD ohne bessere Fertigung eh keine guten Chancen. Unter Last, wo AMDs Taktraten TDP-limitiert werden, spielt Cache eine sehr kleine Rolle und selbst übergroße Caches können die Effizienz noch steigern. (Klassiker ist und bleibt Galatin vs. Northwood: Einen L3 Cache drangehängt, der doppelt so groß war, wie der gesamte bisherige Chip - und ein Endergebnis abgeliefert, das rundum besser war. Naja - außer man musste das Monstrum herstellen/bezahlen )

Cache-Größe allein ist ja nicht alles, und wenn man mit Köpfchen programmiert, dann baut man seine Working Sets auch so, dass sie in den jeweils sinnvollsten Cache passen - in den meisten Fällen also L1 oder L2.
Intel kommt ja auch irgendwie mit 256kB+shared inclusive L3 aus. (AMDs L3 ist afaik auch bei den FX nicht inclusive, aber da kann ich mich jetzt irren)

Bei K10 war er noch exklusive, aber ich glaube mich zu erinnern, dass das geändert wurde (kann mich aber ebenfalls irren).
Und bezgl. Intel:
Iirc war die L3 latency von Sandy Bridge nicht wesentlich schlechter, als die L2 latency von Zamebezi...
Wieso mit kleinen Caches auskommen, wenn er große doch so nahe liegt?

Achtung, das folgende ist nur MEINE Meinung, und dementsprechend sehr subjektiv:
AMD hat diesbezüglich einen in meinen Augen genialen Versuch gestartet. AMD holt den Prügel raus und sagt das, was gesagt werden muss: Grafikkarten können mehr. AMD versucht sozusagen den "High End" Prozessor in den Hintergrund zu schieben. Man muss sich zum Beispiel mal Raytracing anschauen. Da fahren Grafikkarten im Standgas und überholen doppelt so teure Prozessoren ohne zu überlegen.

Diese deine Meinung wurde von AMD vor 1-2 Jahren offiziell als Produktpolitik bekannt gegeben: Kein Leistungsrennen mehr mit Intel, andere Dinge (read: iGPU) sind heutzutage wichtiger.

Trotzdem warten sehr viele Leute auf einen High-End-Angriff von AMD

 

[Oromis16]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Danke erstmal für die Aufklärung der Moderationsrolle bei PCGH (dann muss ich wohl nen Redakteur in ner dunklen Ecke übefallen... )

Der "High End Angriff" kommt ja, nur auf sozusagen anderer Ebene. Nämlich indem Intels High End Sparte schön säuberlich nutzlos gemacht wird. Ich hab grad Luxmark durchlaufen lassen. I7 920 @ 4 Ocken vs 7850 @ Stock (1Gb). Die 7850 ist knapp 3 mal so schnell. Eine 290x fast 7 mal so schnell. Von AMD ist aktuell nur eine 240 langsamer als mein Prozessor (und ich mein: Hallo? Das Ding kostet 50 Tacken^^). Da hilft dann auch das Effizienzargument nix mehr. GPUs rechnen bei vielen Aufgaben viel effizienter und schneller. Hoffen wir also, dass bald nicht mehr nur Java/C/C++ in den Fachinformatikkursen drankommt, sondern auch OpenCl^^

 

[Cinnayum]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Diese deine Meinung wurde von AMD vor 1-2 Jahren offiziell als Produktpolitik bekannt gegeben: Kein Leistungsrennen mehr mit Intel, andere Dinge (read: iGPU) sind heutzutage wichtiger.

Trotzdem warten sehr viele Leute auf einen High-End-Angriff von AMD

Es ist nur so, dass AMD die Strahlwirkung eines Top-Modells verkennt.
Wer würde schon mit einem mini BMW/Mercedes etc. liebäugeln, wenn da nicht das Prestige der großen Kisten wäre.

Für sich genommen sind deren kleine Modelle allesamt schlechter als die etablierter Marken im kleineren Preissegment...

 

[Oromis16]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Da hat AMD natürlich den Vorteil (der sonst oft Nachteil ist), dass sie an 2 Fronten kämpfen. Wenn ein starkes GPU Flaggschiff dasteht, wird sich das wohl auch auf die CPUs auswirken. Ist schließlich das gleiche Logo drauf

 

[VikingGe]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Stellt sich die Frage, ob es allein die Größe ist, die AMD da bremst. Was ich so an Tests findet, spricht von 18-20 Takten Latenz für die 2 MiB L2. Zum Vergleich: Intel hat zu Penryn Zeiten fette 6 MiB mit 15 Zyklen Latenz gehabt.

K10 hat irgendwas mit 15 Takten für 512KB. Auch das ist, gemessen ander Größe, schon nicht wirklich wenig (Core 2 hat ja nette Werte, dafür war da glaube ich die Bandbreite ziemlich unterirdisch). Umso mehr wundert es mich ja, dass man sich bei Bulldozer für noch mehr KB auf Kosten von noch mehr Takten entschieden hat - gerade bei nicht-sequenziellen Zugriffen schlägt die hohe Latenz im negativen Sinne auch oft genug voll durch, und da sind die ≥20 Takte schon so enorm, dass da auch die beste Out of Order-Engine irgendwo nichts mehr kompensieren kann. Besonders heftig kommt sowas beim Iterieren über größere Binärbäume zum Tragen, als Beispiel - da hat Bulldozer erst einen potentiellen Vorteil, wenn die Struktur so riesig ist, dass sie auch den L2 auch wirklich füllt. Passieren kann das hier und da mal, ist aber sicherlich nicht die Regel.

Im Idle macht sich Cache sicherlich bemerkbar, aber auf dem mobilen Markt hat AMD ohne bessere Fertigung eh keine guten Chancen. Unter Last, wo AMDs Taktraten TDP-limitiert werden, spielt Cache eine sehr kleine Rolle

Im Idle profitiert zumindest Steamroller wie gesagt davon, Teile des L2 einfach abschalten zu können (dachte, Piledriver könnte das auch schon, ist aber wohl nicht der Fall). Aber wenn die Taktraten TDP-limitiert werden und der Cache bei aktiver Verwendung viel Energie nuckelt, limitiert der Cache dann ja auch letztenendes den Takt, bzw. verhindert, dass der Turbo-Modus vernünftig anspringt.

Andere Sache: Mich würde an der Stelle mal interessieren, inwieweit der große Cache wohl die Taktbarkeit von der Architektur beeinflusst. Finde es schon erstaunlich, dass das Ding mal eben 4.x-5 GHz schafft.
Vielleicht wurde der auch absichtlich so designed, um eben hohe Taktraten zu ermöglichen? Ich weiß es nicht.

Bei K10 war er noch exklusive, aber ich glaube mich zu erinnern, dass das geändert wurde (kann mich aber ebenfalls irren).

Ich hab gerade mal im AMD Software Optimization Guide für Bulldozer (Seite 213) nachgesehen, der L3 ist wohl exclusive.

 

[ruyven_macaran]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Es ist nur so, dass AMD die Strahlwirkung eines Top-Modells verkennt.
Wer würde schon mit einem mini BMW/Mercedes etc. liebäugeln, wenn da nicht das Prestige der großen Kisten wäre.

AMDs Problem mit "Strahlwirkung" ist, dass 90% der 08/15 Kunden mit "AMD? Kann man das essen? Oder heilen?" reagieren. Da hilft auch ein Topmodel nichts, das in Tests gut abschneidet - denn wer die liest, der kennt AMD auch so. Wenn dann müsste man, wie z.B. die genannten Automarken mit Qualität und Zuverlässigkeit punkten um z.B. Systemadmins überzeugen. Aber da alte Vorurteile abzubauen ist zum einen schwierig und langwierig - und zum anderen hat es rein gar nichts mit der Leistung zu tun. Erst recht nicht mit "Leistung um jeden Preis".

K10 hat irgendwas mit 15 Takten für 512KB. Auch das ist, gemessen ander Größe, schon nicht wirklich wenig (Core 2 hat ja nette Werte, dafür war da glaube ich die Bandbreite ziemlich unterirdisch).

Core2 hatte iirc 128 Bit bei vollem CPU-Takt - das war noch lange Zeit danach Standard und iirc sogar einige Zeit davor. (Ich glaube mich dunkel zu erinnern, dass schon Northwood 128 Bit hat und ich bin mir ziemlich sicher, dass es K10 noch hatte - und bin mir nicht sicher, dass Bulldozer auf 256 Bit aufgebohrt hat)

Umso mehr wundert es mich ja, dass man sich bei Bulldozer für noch mehr KB auf Kosten von noch mehr Takten entschieden hat - gerade bei nicht-sequenziellen Zugriffen schlägt die hohe Latenz im negativen Sinne auch oft genug voll durch, und da sind die ≥20 Takte schon so enorm, dass da auch die beste Out of Order-Engine irgendwo nichts mehr kompensieren kann. Besonders heftig kommt sowas beim Iterieren über größere Binärbäume zum Tragen, als Beispiel - da hat Bulldozer erst einen potentiellen Vorteil, wenn die Struktur so riesig ist, dass sie auch den L2 auch wirklich füllt. Passieren kann das hier und da mal, ist aber sicherlich nicht die Regel.

Ich fürchte, dass ist nur eine weitere Seite der kompletten Fehlkalkulation des Modulkonzeptes. Vergleicht man Bulldozer mit Core2, dann ist das Verhältnis aus L2 Größe und CPU-Leistung durchaus vergleichbar. Man hat also einen Cluster aus Dualcores, die eigentlich gar nicht auf den L3 angewiesen sein sollen, der seinerzeit "nur" den Speichercontroller vorm Massenansturm der vielen Cores schützt.
In so einem Konzept sind die hohen Latenzen zwar immer noch schmerzhaft - aber ggf. die Option, die zumindest zu Beginn der Entwicklung als die bessere erschien. Ich könnte mir auch gut vorstellen, dass man wesentlich niedrigere Latenzen im Lastenheft hatte, diese aber einfach nicht mehr realisieren konnte. Nachträglich auf eine andere L2/L3 Nutzung umzustellen, hätte aber ein Redesign der kompletten Architektur erfordert. Einen Aufwand, den AMD einfach nicht stemmen kann - weswegen es ja bis heute überhaupt nur ein einziges Silizium mit Modul-Architektur und L3 gab, auch wenn AMD dieses eine Layout mittlerweile unter der dritten Codename-Generation verkauft.

Andere Sache: Mich würde an der Stelle mal interessieren, inwieweit der große Cache wohl die Taktbarkeit von der Architektur beeinflusst. Finde es schon erstaunlich, dass das Ding mal eben 4.x-5 GHz schafft.
Vielleicht wurde der auch absichtlich so designed, um eben hohe Taktraten zu ermöglichen? Ich weiß es nicht.

Hoher Takt stand jedenfalls mal im Leistungsheft (Bulldozer ist schließlich AMDs "10 GHz"-Architektur). Wenn man die Latenzen mit Netburst vergleicht (27 für die 2 MiB L2 Caches), steht Bulldozer jedenfalls wieder ganz gut da.

 

[TechDragon]

AMD FX-670K

Der Hintergrund im Video könnte auch mein Keller sein

 

[VikingGe]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Core2 hatte iirc 128 Bit bei vollem CPU-Takt - das war noch lange Zeit danach Standard und iirc sogar einige Zeit davor. (Ich glaube mich dunkel zu erinnern, dass schon Northwood 128 Bit hat und ich bin mir ziemlich sicher, dass es K10 noch hatte - und bin mir nicht sicher, dass Bulldozer auf 256 Bit aufgebohrt hat)

Ich meinte eigentlich die L2-Bandbreite, das sind niemals 128 Bit pro Takt - die fände man eher beim L1 wieder (oder ich verstehe dich gerade einfach nur falsch).
Wobei K10 pro Takt 2x128 Bit aus dem L1 lesen oder 2x64 Bit bzw. 1x128 Bit schreiben kann. Wie Intel da genau organisiert ist, weiß ich jetzt nicht, aber zumindest rein lesend ist da glaube ich erst Sandy Bridge auf demselben Niveau. Und Bulldozer hat eben das Problem mit der extrem niedrigen Schreibrate vom L1.

Wenn man die Latenzen mit Netburst vergleicht (27 für die 2 MiB L2 Caches), steht Bulldozer jedenfalls wieder ganz gut da.

Hallo - es ist Netburst, da würde es mich auch nicht wundern, wenn eine Floating Point-Addition 27 Takte braucht

Ich könnte mir auch gut vorstellen, dass man wesentlich niedrigere Latenzen im Lastenheft hatte, diese aber einfach nicht mehr realisieren konnte. Nachträglich auf eine andere L2/L3 Nutzung umzustellen, hätte aber ein Redesign der kompletten Architektur erfordert.

Das wird wohl so sein. Ich meine, wenn man sich mal ansieht, dass der FX-8150 seinerzeit Mühe hatte, einen Phenom II X6 zu schlagen, wird eigentlich klar, dass AMD da nicht ganz das geschafft hat, was sie wollten - allerdings kennt AMD die Probleme der Architektur mit Sicherheit schon länger als wir. Naja, mal sehen, was Excavator außer 256bit-Pipes so bringt.

 

[ruyven_macaran]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Ich meinte eigentlich die L2-Bandbreite, das sind niemals 128 Bit pro Takt - die fände man eher beim L1 wieder (oder ich verstehe dich gerade einfach nur falsch).
Wobei K10 pro Takt 2x128 Bit aus dem L1 lesen oder 2x64 Bit bzw. 1x128 Bit schreiben kann. Wie Intel da genau organisiert ist, weiß ich jetzt nicht, aber zumindest rein lesend ist da glaube ich erst Sandy Bridge auf demselben Niveau. Und Bulldozer hat eben das Problem mit der extrem niedrigen Schreibrate vom L1.

Wie schnell der Cache selbst ist und wieviel Overhead noch anfällt, weiß ich nicht - aber die Anbindung zum Cache war meiner Erinnerung nach so breit und es wurden effektiv >8 Byte/cycle gemessen, was mit einem 64 Bit Interface schlichtweg unmöglich wäre.

Naja, mal sehen, was Excavator außer 256bit-Pipes so bringt.

Ich vermute mal: Keine Umstellung der Cache-Architektur. AMD hat einfach zu lange gewartet und dann zu hart gegensteuern müssen - jetzt haben sie nicht mehr die Kapazitäten um mehr als 2 Produktfamilien zu betreuen. Und der Markt, den Kabini und Kaveri derzeit bedienen, ist einfach viel lukrativer, als die Klassen, in denen L3 sinnvoll wäre. Da eine Abkehr von Taktbarkeit hin zu IPC eine Überarbeitung aller Elemente erfordern würde, glaube ich auch nicht, dass AMD bei Excavator etwaige Fortschritte im Aufbau der Caches selbst in geringe Latenzen investiert - sondern wenn dann in höhere Frequenzen. Alles andere ist ein Thema für eine Bulldozer-Nachfolgearchitektur, ggf. für einen Kabini-Nachfolger.

 

[VikingGe]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

aber die Anbindung zum Cache war meiner Erinnerung nach so breit und es wurden effektiv >8 Byte/cycle gemessen, was mit einem 64 Bit Interface schlichtweg unmöglich wäre.

Interessant. Zumal die 8.5 mir irgendwie zu klein vorkommen und auch irgendwie die Werte alle zu konstant scheinen, um es auf ein Interface zu schieben, das nicht vernünftig ausgelastet wird, aber doch irgendwie zu groß, um damit zu argumentieren, dass einige Daten gegebenenfalls nie den L1 verlassen (obwohl der Effekt da sicherlich existiert).

Allerdings lässt sich das auf K10 absolut nicht reproduzieren:

Spoiler

Sequential read (128-bit), size = 128 B, loops = 4128768000, 100789.7 MB/s
Sequential read (128-bit), size = 256 B, loops = 2103705600, 102714.3 MB/s
Sequential read (128-bit), size = 384 B, loops = 1502778438, 110059.9 MB/s
Sequential read (128-bit), size = 512 B, loops = 1168769024, 114126.6 MB/s
Sequential read (128-bit), size = 640 B, loops = 914667611, 111646.9 MB/s
Sequential read (128-bit), size = 768 B, loops = 809148060, 118524.0 MB/s
Sequential read (128-bit), size = 896 B, loops = 678650778, 115977.1 MB/s
Sequential read (128-bit), size = 1024 B, loops = 618725376, 120837.9 MB/s
Sequential read (128-bit), size = 1280 B, loops = 500949540, 122297.2 MB/s
Sequential read (128-bit), size = 2 kB, loops = 318734336, 124503.8 MB/s
Sequential read (128-bit), size = 3 kB, loops = 214670815, 125782.5 MB/s
Sequential read (128-bit), size = 4 kB, loops = 145768448, 113874.4 MB/s
Sequential read (128-bit), size = 6 kB, loops = 100897436, 118228.0 MB/s
Sequential read (128-bit), size = 8 kB, loops = 77135872, 120520.5 MB/s
Sequential read (128-bit), size = 12 kB, loops = 52420139, 122855.2 MB/s
Sequential read (128-bit), size = 16 kB, loops = 39788544, 124329.0 MB/s
Sequential read (128-bit), size = 20 kB, loops = 31996692, 124981.7 MB/s
Sequential read (128-bit), size = 24 kB, loops = 26764920, 125451.0 MB/s
Sequential read (128-bit), size = 28 kB, loops = 23020920, 125885.0 MB/s
Sequential read (128-bit), size = 32 kB, loops = 20180992, 126122.6 MB/s
Sequential read (128-bit), size = 34 kB, loops = 19017563, 126281.7 MB/s
Sequential read (128-bit), size = 36 kB, loops = 17983420, 126435.9 MB/s
Sequential read (128-bit), size = 40 kB, loops = 16185078, 126433.3 MB/s
Sequential read (128-bit), size = 48 kB, loops = 13523055, 126771.9 MB/s
Sequential read (128-bit), size = 64 kB, loops = 9776128, 122199.0 MB/s

Sequential read (128-bit), size = 128 kB, loops = 1276928, 31918.1 MB/s
Sequential read (128-bit), size = 192 kB, loops = 851477, 31928.8 MB/s
Sequential read (128-bit), size = 256 kB, loops = 638976, 31940.2 MB/s
Sequential read (128-bit), size = 320 kB, loops = 511020, 31936.0 MB/s
Sequential read (128-bit), size = 384 kB, loops = 418200, 31356.2 MB/s
Sequential read (128-bit), size = 512 kB, loops = 173824, 17377.1 MB/s

Sequential read (128-bit), size = 768 kB, loops = 77435, 11605.0 MB/s
Sequential read (128-bit), size = 1 MB, loops = 60224, 12036.5 MB/s
Sequential read (128-bit), size = 1.25 MB, loops = 45645, 11404.1 MB/s
Sequential read (128-bit), size = 1.5 MB, loops = 37338, 11192.5 MB/s
Sequential read (128-bit), size = 1.75 MB, loops = 32004, 11191.1 MB/s
Sequential read (128-bit), size = 2 MB, loops = 27968, 11185.2 MB/s
Sequential read (128-bit), size = 2.25 MB, loops = 24836, 11163.7 MB/s
Sequential read (128-bit), size = 2.5 MB, loops = 22325, 11153.4 MB/s
Sequential read (128-bit), size = 2.75 MB, loops = 20240, 11132.0 MB/s
Sequential read (128-bit), size = 3 MB, loops = 18564, 11126.9 MB/s
Sequential read (128-bit), size = 3.25 MB, loops = 17119, 11120.5 MB/s
Sequential read (128-bit), size = 3.5 MB, loops = 15894, 11118.7 MB/s
Sequential read (128-bit), size = 4 MB, loops = 13904, 11116.1 MB/s
Sequential read (128-bit), size = 5 MB, loops = 10680, 10669.6 MB/s
Sequential read (128-bit), size = 6 MB, loops = 8070, 9674.9 MB/s

Sequential read (128-bit), size = 7 MB, loops = 6318, 8833.6 MB/s
Sequential read (128-bit), size = 8 MB, loops = 5464, 8740.0 MB/s
Sequential read (128-bit), size = 9 MB, loops = 4788, 8606.0 MB/s
Sequential read (128-bit), size = 10 MB, loops = 4152, 8294.2 MB/s
Sequential read (128-bit), size = 12 MB, loops = 3360, 8061.6 MB/s
Sequential read (128-bit), size = 14 MB, loops = 2856, 7989.8 MB/s
Sequential read (128-bit), size = 15 MB, loops = 2660, 7973.1 MB/s
Sequential read (128-bit), size = 16 MB, loops = 2496, 7986.3 MB/s
Sequential read (128-bit), size = 20 MB, loops = 1995, 7977.8 MB/s
Sequential read (128-bit), size = 21 MB, loops = 1902, 7976.2 MB/s
Sequential read (128-bit), size = 32 MB, loops = 1248, 7975.0 MB/s
Sequential read (128-bit), size = 48 MB, loops = 831, 7974.1 MB/s
Sequential read (128-bit), size = 64 MB, loops = 623, 7964.9 MB/s
Sequential read (128-bit), size = 72 MB, loops = 555, 7990.1 MB/s
Sequential read (128-bit), size = 96 MB, loops = 416, 7982.8 MB/s
Sequential read (128-bit), size = 128 MB, loops = 313, 7993.6 MB/s

Eigentlich ein nahezu perfektes 4:1-Verhältnis von L1 zu L2. Die Werte sind jeweils natürlich ein wenig vom theoretischen Maximum entfernt, den 33.4 GB/s für 8 Bytes pro Takt kommt der L2 allerdings auch nicht wirklich nahe.

Edit: Ich meine, gut, kann natürlich sein, dass da nach einer Operation erstmal ein Takt Pause ist, das dann aber wirklich mit 128bit-Interface. Ähnliches gibts z.B. auch bei Jumps und Integer-Multiplikationen auf K10, ein Jump hat zwar nur einen Takt Latenz, aber man kann nur alle zwei Takte einen Jump ausführen.

Übrigens auch geil, dass Prescott bei einem Thread nicht viel weniger RAM-Bandbreite liefert als K10, trotz deutlich schlechterer Voraussetzungen aber den Speichercontroller haben sie ja glücklicherweise schon ordentlich überarbeitet.

Ich vermute mal: Keine Umstellung der Cache-Architektur.

Naja, gibt ja auch noch andere Flaschenhälse in der Architektur. Mit Steamroller hat man ja immerhin einen davon ausgemerzt und ein paar mehr Decoder verbaut.

Alles andere ist ein Thema für eine Bulldozer-Nachfolgearchitektur, ggf. für einen Kabini-Nachfolger.

Aber von irgendeiner Basis muss der ja auch entwickelt werden und angesichts der Tatsache, dass es AMD ja nun wirklich nicht gerade rosig geht, bezweifle ich mal, dass da ne komplette Neuentwicklung kommt. Jaguar ist zu schwach für eine High Performance-Architektur, K10 müsste massiv umgebaut werden und bräuchte eine von Grund auf neu entwickelte FPU. Ich denke mal, dass uns die Modularchitektur doch noch ein Weilchen erhalten bleibt.

Was Taktbarkeit von Excavator angeht: Angeblich soll da ja ganz massiv am Layout gebastelt werden, um Strom zu sparen. Würde sich aber wohl mit dem maximalen Takt eher beißen als ihm dienen. Dazu kommt, dass ja schon GloFos aktueller 28nm-Prozess nicht wirklich hoch taktet. Auf der anderen Seite steht Centurion mit seinen 220W TDP.

 

[PCGH_Carsten]

AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte

Wie schnell der Cache selbst ist und wieviel Overhead noch anfällt, weiß ich nicht - aber die Anbindung zum Cache war meiner Erinnerung nach so breit und es wurden effektiv >8 Byte/cycle gemessen, was mit einem 64 Bit Interface schlichtweg unmöglich wäre.

Da geht's doch um den P4, oder?