Intel vergleicht 96 Cascade-Lake-AP-Kerne gegen 64 AMD-Zen-Kerne

110
News Mark Mantel Als bevorzugte Quelle auf Google hinzufügen
Intel vergleicht 96 Cascade-Lake-AP-Kerne gegen 64 AMD-Zen-Kerne (3)
Quelle: Intel

Auf der Supercomputing-2018-Konferenz rührt Intel weiter die Werbetrommel für seine Cascade-Lake-AP-Familie, die als Dual-Chip-Lösung bis zu 48 CPU-Kerne nutzt. Zwei kommende Topmodelle mit insgesamt 96 Kernen sieht Intel um den Faktor 1,5 bis 3,4 vor zwei Epyc-7601-Modellen von AMD mit zusammen 64 Kernen.

Anfang November hat Intel die Produktserie der Advanced-Performance-Prozessoren innerhalb der Cascade-Lake-Familie vorgestellt. Die neue Speerspitze vereint zwei Siliziumchips auf einem Package, was bis zu 48 nutzbare CPU-Kerne und 12 Speicherkanäle ergibt - physisch vorhanden sind vermutlich 56 Rechenherzen. Zur Vorstellung nannte Intel erste Performance-Werte aus synthetischen Benchmarks. In Stream Triad sollen zwei kommende 48-Kerner 30 Prozent schneller rechnen als zwei Epyc-7601-CPUs von AMD mit jeweils 32 Kernen. In Linpack sei Intels Angebot 240 Prozent flotter. Machine-Learning soll gegenüber zwei hauseigenen Xeon Platinum 8180 mit Hilfe der neuen AVX512VNNI-Erweiterung innerhalb von Intels "DL Boost" um den Faktor 17 beschleunigt werden.

Neue hochgerechnete Benchmarks von Cascade Lake-AP

Auf der Supercomputing 2018 hat Intel jetzt die ersten "Real World"-Benchmarks veröffentlicht, wo die 96 Cascade-Lake-AP-Kerne um den Faktor 1,5 bis 3,1 schneller rechnen sollen als zwei Epyc-7601-CPUs (insgesamt 64 Kerne, 2,2-3,2 GHz, 16 × 16/32 GiByte DDR4-2666, SMT wie bei Intel aus). Es handle sich um Ergebnisse, die anhand von Vorserien-Hardware hochgerechnet worden seien. Das könnte zum Beispiel bedeuten, dass die Cascade-Lake-AP-Modelle mit einem niedrigeren Takt als final anvisiert liefen und die Werte anhand der erwarteten Frequenzen interpoliert wurden. Genaue Angaben zu den Spezifikationen oder dem Testsystem gibt es nicht.

Die 50 Prozent mehr Leistung in MILC, einer Anwendung für Quantenchromodynamik, entspricht genau dem Plus an Kernen, die Cascade Lake-AP gegenüber AMDs Zen nutzen kann. In WRF (Berechnung von Wetterprognosen) und OpenFOAM (Berechnung von numerischer Strömungsmechanik) falle die Mehrleistung mit 60 Prozent etwas höher aus, wobei dort die insgesamt 12 statt acht Speicherkanäle helfen dürften. Die Performance in NAMD (APOA1) und YASK (ISO 3DFD) steige um den Faktor 2,1 beziehungsweise 3,1. Bei YASK sollte man allerdings beachten, dass es sich um ein Intel-Framework handelt.

Mehr zum Thema: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen

Intel möchte Cascade Lake-AP kommendes Jahr veröffentlichen. Dort wird sich der 48-Kerner mit AMDs Zen 2 anlegen müssen, der bis zu 64 Kernen in einem Package nutzt. Mit einer Verdoppelung der Kerne, einem zu erwartenden höheren Takt und architektonischen Optimierungen dürfte AMD die Nase leistungstechnisch 2019 vorne haben. Spätestens die Effizienz sollte dank TSMCs 7-nm-Fertigung eine ganze Ecke besser ausfallen.

Bildergalerie

110
    • Kommentare (110)

      Zur Diskussion im Forum
      • Von empy Lötkolbengott/-göttin
        Zitat von PCGH_Torsten
        Zu den Cavium Thunder findet man einige Artikel, aber ich kenne mich mit den dort verwendeten Benchmarks nicht gut genug aus, um ein eigenes Urteil zu fällen. Aber es liegen zumindest keine Größenordnungen zwischen den verschiedenen Architekturen.
        Das hätte mich auch gewundert, aber wäre halt schon mal interessant, wie gut ARM dann schlussendlich doch nach oben mitskaliert. Als Energiesparwunder werden sie ja schon lange bezeichnet, allerdings war das damals noch so fernab der Vergleichbarkeit zu den größeren x86-CPUs, dass man sich unweigerlich gefragt hat, wieviel davon wohl noch übrig bleiben würde, wenn man mit ARM ähnliche CPUs bauen würde.

        Zitat von PCGH_Torsten
        Problematische Latenzen dürften durch den Decoder meiner Einschätzung nach kaum entstehen, denn letztlich müssen auf allen Plattformen die gleichen Berechnungen durchgeführt werden. Bei ARM steckt der komplexe Teil des Codes halt im Quelltext, bei x86 wird ein Befehl an die CPU gegeben und die kümmert sich um den Rest. Das kostet gegebenenfalls etwas zusätzliche Zeit, aber dafür kann die CPU den gesamten weiteren Ablauf optimal abstimmen.
        Am Ende werden so oder so dem RISC-Teil irgendwelche Instruktionen um die Ohren gehauen und er schaut dann, welche er jetzt ausführen kann und reiht diese dann ein. Ob die jetzt direkt aus dem RISC-Kompilat (Quellcode ja jetzt nicht) oder per CISC-Kompilat aus dem Microcode kommen, sollte keine riesige Rolle spielen. Auf der anderen Seite ist wieder die Frage, ob die Latenzen durch die Decoderstufe nicht verpuffen, weil an der Stelle eh noch nichts passiert, das großartig Organisation braucht. Die Latenzen spielen ja erst dann wirklich eine Rolle, wenn Entscheidungen davon abhängen.

        Zitat von PCGH_Torsten
        Wenn sich ein Entwickler sehr viel Mühe gibt und hardware-nah optimiert, hat er bei RISC prinzipiell mehr Möglichkeiten – deswegen hat Intel bei Itanium damals sehr viel Organisatinslogik dem Compiler überlassen. Aber wir wissen ja alle, was daraus wurde.
        Naja, EPIC hatte halt das große Problem, dass es im Endeffekt VLIW war und die Parallelität, die die heutigen CPUs dynamisch managen, im Compiler gelöst werden sollte. Ich finde das ist insofern nicht richtig vergleichbar. Von dem Durchsetzungvermögen her kann man jetzt drüber streiten, ob die fehlende Unterstützung für alte Software oder die Mikroarchitektur selbst jetzt mehr Schuld war.
      • Von empy Lötkolbengott/-göttin
        Zitat von PCGH_Torsten
        Zu den Cavium Thunder findet man einige Artikel, aber ich kenne mich mit den dort verwendeten Benchmarks nicht gut genug aus, um ein eigenes Urteil zu fällen. Aber es liegen zumindest keine Größenordnungen zwischen den verschiedenen Architekturen.
        Das hätte mich auch gewundert, aber wäre halt schon mal interessant, wie gut ARM dann schlussendlich doch nach oben mitskaliert. Als Energiesparwunder werden sie ja schon lange bezeichnet, allerdings war das damals noch so fernab der Vergleichbarkeit zu den größeren x86-CPUs, dass man sich unweigerlich gefragt hat, wieviel davon wohl noch übrig bleiben würde, wenn man mit ARM ähnliche CPUs bauen würde.

        Zitat von PCGH_Torsten
        Problematische Latenzen dürften durch den Decoder meiner Einschätzung nach kaum entstehen, denn letztlich müssen auf allen Plattformen die gleichen Berechnungen durchgeführt werden. Bei ARM steckt der komplexe Teil des Codes halt im Quelltext, bei x86 wird ein Befehl an die CPU gegeben und die kümmert sich um den Rest. Das kostet gegebenenfalls etwas zusätzliche Zeit, aber dafür kann die CPU den gesamten weiteren Ablauf optimal abstimmen.
        Am Ende werden so oder so dem RISC-Teil irgendwelche Instruktionen um die Ohren gehauen und er schaut dann, welche er jetzt ausführen kann und reiht diese dann ein. Ob die jetzt direkt aus dem RISC-Kompilat (Quellcode ja jetzt nicht) oder per CISC-Kompilat aus dem Microcode kommen, sollte keine riesige Rolle spielen. Auf der anderen Seite ist wieder die Frage, ob die Latenzen durch die Decoderstufe nicht verpuffen, weil an der Stelle eh noch nichts passiert, das großartig Organisation braucht. Die Latenzen spielen ja erst dann wirklich eine Rolle, wenn Entscheidungen davon abhängen.

        Zitat von PCGH_Torsten
        Wenn sich ein Entwickler sehr viel Mühe gibt und hardware-nah optimiert, hat er bei RISC prinzipiell mehr Möglichkeiten – deswegen hat Intel bei Itanium damals sehr viel Organisatinslogik dem Compiler überlassen. Aber wir wissen ja alle, was daraus wurde.
        Naja, EPIC hatte halt das große Problem, dass es im Endeffekt VLIW war und die Parallelität, die die heutigen CPUs dynamisch managen, im Compiler gelöst werden sollte. Ich finde das ist insofern nicht richtig vergleichbar. Von dem Durchsetzungvermögen her kann man jetzt drüber streiten, ob die fehlende Unterstützung für alte Software oder die Mikroarchitektur selbst jetzt mehr Schuld war.
      • Von PCGH_Torsten Kokü-Junkie (m/w)
        Zitat von empy
        Ich würde es halt so sehen: Der Decoder braucht Zeit, das führt zu Latenzen, die widerum bei Abhängigkeiten zu Stalls führen können. Dass ARM eigentlich schon nahe rankäme, würde ich auch so sehen, aber mir waren da noch keine Modelle geläufig. Bin in dem Thema aber auch nicht so drin.
        Zu den Cavium Thunder findet man einige Artikel, aber ich kenne mich mit den dort verwendeten Benchmarks nicht gut genug aus, um ein eigenes Urteil zu fällen. Aber es liegen zumindest keine Größenordnungen zwischen den verschiedenen Architekturen.

        Problematische Latenzen dürften durch den Decoder meiner Einschätzung nach kaum entstehen, denn letztlich müssen auf allen Plattformen die gleichen Berechnungen durchgeführt werden. Bei ARM steckt der komplexe Teil des Codes halt im Quelltext, bei x86 wird ein Befehl an die CPU gegeben und die kümmert sich um den Rest. Das kostet gegebenenfalls etwas zusätzliche Zeit, aber dafür kann die CPU den gesamten weiteren Ablauf optimal abstimmen. Wenn sich ein Entwickler sehr viel Mühe gibt und hardware-nah optimiert, hat er bei RISC prinzipiell mehr Möglichkeiten – deswegen hat Intel bei Itanium damals sehr viel Organisatinslogik dem Compiler überlassen. Aber wir wissen ja alle, was daraus wurde.
      • Von Duvar Kokü-Junkie (m/w)
        Zitat von empy
        Jetzt werden hier aber die großen Fachbegriffe ausgepackt. Wenn du jetzt noch im Kontext hättest bleiben können, wäre das schon fast gut gewesen. Blöd wenn die eigene Hochspezialisierung grade nicht zum Thema passt, versuchen kann man es aber ja mal.
        Er meint damit folgendes und zwar, warte mal, dieses Video erklärt es: YouTube
      • Von gaussmath
        empy, hier ist dein Kontext: mach' dich mal locker und sei nicht so eine Spaßbremse.
      • Von empy Lötkolbengott/-göttin
        Zitat von gaussmath
        Ja, so ist es. Dabei bin ich davon ausgegangen, dass empy klar ist, dass Threadripper bei Workloads punktet, die sich dadurch auszeichnen, dass sie chache-lastig, stark parallelisierbar und zumeist unabhängige Threads fahren, was zum Beispiel bei diskreten Optimierungsverfahren mit small Data Objective Function der Falle ist, welche multiinstanziell auf großen Lösungsräumen operieren und kontraktiv auf einem Big Valley wirken.
        Jetzt werden hier aber die großen Fachbegriffe ausgepackt. Wenn du jetzt noch im Kontext hättest bleiben können, wäre das schon fast gut gewesen. Blöd wenn die eigene Hochspezialisierung grade nicht zum Thema passt, versuchen kann man es aber ja mal.
      Direkt zum Diskussionsende
  • Print / Abo
    Apps
    PCGH Magazin 08/2026 PC Games 08/2026 play5 08/2026 N-Zone 08/2026 Linux Magazin 08/2026 LinuxUser 08/2026 Raspberry Pi Geek 09/2026
    PC Games Hardware PC Games Linux Magazin Raspberry Pi Geek Computec Kiosk