Online-Abo
  • Login
  • Registrieren
Games World
      • Von Coeckchen Komplett-PC-Aufrüster(in)
        AMD sollte lieber mal an der IPC arbeiten als permanent i-welche Single Thread krücken zu produzieren.
      • Von ruyven_macaran Trockeneisprofi (m/w)
        Zitat von VikingGe
        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.
        Ggf. ist es bei den Netburst-Tests sogar noch mehr, das würde jedenfalls gut den Unterschied zwischen SSE und anderen Daten erklären: Die Anbindung ist zwar schön breit, aber die Ansteuerung arsch langsam und eine Auslastung deswegen nur bei großen Paketen halbwegs möglich.

        Zitat
        Übrigens auch geil, dass Prescott bei einem Thread nicht viel weniger RAM-Bandbreite liefert als K10, trotz deutlich schlechterer Voraussetzungen
        Das ist in der Tat merkwürdig, schließlich ist Prescott ja auf die 6,4 GB/s des FSB limitiert.

        Zitat
        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.

        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.
        Ich gehe auch davon auf, dass sie sehr viel von Excavator übernehmen werden. Wir haben jetzt brauchbare Decoder, mit der nächsten Runde kommen state-of-the-art SIMDs dazu, an den Integereinheiten gibt es afaik auch nichts auszusetzen. Der große Schwachpunkt (neben den Caches, die aber auch Teil dieses Problems sind) ist und bleibt das Modulkonzept. Das wird mit Excavator nicht angegangen, aber danach würde ich mit einer Reorganisation der bekannten Einheiten rechnen. Im Idealfall schmeißt AMD einfach die beiden Integerkerne zusammen (Haswell i5 führt ja vor, dass 4 Pipes pro Thread durchaus funktionieren), führt wieder einen großen Scheduler ein und sieht zu, was sich beim Cache machen lässt.

        Zitat von PCGH_Carsten
        Da geht's doch um den P4, oder?

        Jup, Core2 Benchmarks habe ich so schnell nicht wiedergefunden. Aber ich denke, es ist sicher, für neuere Intel-Architekturen eine mindestens so breite L2-Anbindung anzunehmen, wie sie mindestens seit Northwood verwendet wird. (iirc gab es auch da keine Verbesserung gegenüber Williamette, das heißt Intel ist beim Wechsel von P6 auf Netburst auch von 64 auf 128 Bit gewechselt.)
      • Von PCGH_Carsten Redakteur
        Zitat von ruyven_macaran
        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?
      • Von VikingGe
        Zitat
        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:
        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.

        Zitat
        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.

        Zitat
        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.
      • Von ruyven_macaran Trockeneisprofi (m/w)
        Zitat von VikingGe
        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.

        Zitat
        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.
  • Print / Abo
    Apps
    PC Games Hardware 01/2017 PC Games 12/2016 PC Games MMore 01/2016 play³ 01/2017 Games Aktuell 12/2016 buffed 12/2016 XBG Games 11/2016
    PCGH Magazin 01/2017 PC Games 12/2016 PC Games MMORE Computec Kiosk On the Run! Birdies Run
article
1114769
CPU
AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte
Still und heimlich hat Hewlett Packard den ersten Komplett-PC mit einem FX-670K auf den Markt gebracht. Entgegen bisheriger Erwartungen, dass AMD Viermoduler ohne Grafikeinheit für den Sockel FM2(+) bringen könnte, handelt es sich weiterhin um einen Zweimoduler. Fraglich bleibt allerdings, ob die integrierte Grafikeinheit deaktiviert worden ist.
http://www.pcgameshardware.de/CPU-Hardware-154106/News/AMD-FX-670K-FM2-aufgetaucht-1114769/
24.03.2014
http://www.pcgameshardware.de/screenshots/medium/2014/03/CPU-Z-Screenshot_AMD_FX-670K-pcgh_b2teaser_169.jpg
amd,apu,cpu
news