Intel Cascade Lake X: 10- und 18-Kerner im Geekbench

58
News Andreas Link Als bevorzugte Quelle auf Google hinzufügen
Cascade Lake X: 10- und 18-Kerner im Geekbench (3)
Quelle: Intel

Im Geekbench sind zwei Prozessoren der Reihe Cascade Lake X aufgetaucht. Die Ergebnisse sollten nicht überbewertet werden, sind aber ganz interessant auch im Hinblick darauf, dass AMD ja noch Threadripper 3000 und den Ryzen 9 3950X in der Hinterhand hat. Im Segment der stark parallelisierten Rechenleistung ist AMD bisher kompetitiver gewesen.

In der Datenbank von Geekbench sind zwei Cascade-Lake-X-Prozessoren aufgetaucht, die im Herbst auf der HEDT-Plattform mit X299-PCH erscheinen sollen. Bei den gelisteten Modellen handelt es sich um einen 18-Kerner und einen 10-Kerner. Vermutlich stammen die Tests aus den Laboren von Dell, wo sie für einen PC vom Typ Precision 5820 X Series getestet worden sein könnten. Dabei handelt es sich um Workstations von Dell, die aktuell mit LGA-2066-Prozessoren der aktuellen Generation ausgestattet sind.

Die neuen Modelle indes werden als "GenuineIntel Family 6 Model 85 Stepping 7" aufgeführt. Der 18-Kerner wird mit 2,19 GHz Basis- und 3,28 GHz Boost-Takt gelistet. Der 10-Kerner steht in der Datenbank mit 3,39 GHz Basis- und 4,59 GHz Boost-Takt. Wie final die Werte sind, sei dahingestellt. Für gewöhnlich sind Engineering Samples mit reduziertem Tempo unterwegs. Wie die Lage bei den konkret gelisteten zwei Modellen ist, ist unklar. Der 18-Kerner ist jedenfalls langsamer unterwegs als das aktuell verfügbare Modell Intel Core i9-9980XE (3,0/4,5) und auch der 10-Kerner kommt nicht an sein aktuelles Pendant, Core i9-9900X (3,5/4,4), heran.

Auch lesenswert: AMD Threadripper: Dritte Generation im Oktober?

Entsprechend vorsichtig sollte man auch die Werte behandeln, die für den 18-Kerner bei 5.387/54.597 Punkten liegen. Der 10-Kerner hat 5.468/39.820 Punkte. Damit wäre der 18-Kerner auf dem Leistungsniveau eines Ryzen Threadripper 2970WX und der 10-Kerner auf dem Niveau eines Ryzen Threadripper 2920X. Natürlich wird von AMD im Herbst ebenfalls eine neue HEDT-Plattform erwartet, die - zusammen mit genaueren Werten von Intel-Modellen - ein bisschen Würze in das Segment bringen dürfte, denn AMD rüstet auf Zen 2 um. Threadripper 3000 dürfte vor allem im Mehrkern-Ergebnis einige Punkte mehr holen als der Vorgänger, aber auch bei der Pro-Takt-Leistung auf einem Kern näher an Intel liegen.

Was man auf jeden Fall erwarten darf, ist, dass es die ganze Leistung nicht ohne Haken geben wird und der dürfte bei der Leistungsaufnahme liegen. Die auf der Computex gezeigten Mainboards für die HEDT-Plattform haben umfangreiche Spannungsversorgungen mit noch größeren Kühlern als noch bislang üblich. 165 Watt TDP sind sicher gesetzt und werden wohl auch wieder die Grenze auf dem Papier darstellen, ungezügelt dürfte es aber auch darüber hinaus gehen.

Cascade Lake X: 10- und 18-Kerner im Geekbench (1) Quelle: Twitter Cascade Lake X: 10- und 18-Kerner im Geekbench (2) Quelle: Twitter
58
    • Kommentare (58)

      Zur Diskussion im Forum
      • Von gaussmath
        @Torsten: OK, das könnte ich mir tatsächlich sogar noch vorstellen. Der Remote Cache wird global im I/O-Die verwaltet und arbeitet dann als Stufe 4 wie ein L4 Cache. Jedes CCX hätte dann "nur" 2 L3 (eigentlich ja lokal L3 und global L4?!) Domains zu durchsuchen. Durch die schlechten Latenzen des IFs und den zusätzlichen Verwaltungsaufwand sehe ich halt die signifikanten Vorteile nicht. Aber der Ansatz könnte proportional zu IF-Verbesserungen zukünftig Vorteile bringen. Man kann nur hoffen, dass Zen 3 diesbzgl. optimiert wird, dann kann man wirklich von shared L3 Cache reden.

        Edit: Hier noch eine Ergänzung aus eine Diskussion bei CB.

        "Looking at the AMD numbers above 16 MB, it is clear that is no large 256 MB L3-cache. The AMD EPYC 7742 rather consist of 16 CCX which alll have a relatively fast 16 MB L3. So although the 64 cores are one big NUMA node now, the 64-core chip is basically 16x 4 cores, each with 16 MB L3-caches. Once you get beyond that 16 MB cache, the prefetchers can soften the blow, but you will be accessing the main DRAM."

        Quelle

        Also leider kein Shared Cache. Die leichten Vorteile kommen vom Prefetcher.
      • Von gaussmath
        @Torsten: OK, das könnte ich mir tatsächlich sogar noch vorstellen. Der Remote Cache wird global im I/O-Die verwaltet und arbeitet dann als Stufe 4 wie ein L4 Cache. Jedes CCX hätte dann "nur" 2 L3 (eigentlich ja lokal L3 und global L4?!) Domains zu durchsuchen. Durch die schlechten Latenzen des IFs und den zusätzlichen Verwaltungsaufwand sehe ich halt die signifikanten Vorteile nicht. Aber der Ansatz könnte proportional zu IF-Verbesserungen zukünftig Vorteile bringen. Man kann nur hoffen, dass Zen 3 diesbzgl. optimiert wird, dann kann man wirklich von shared L3 Cache reden.

        Edit: Hier noch eine Ergänzung aus eine Diskussion bei CB.

        "Looking at the AMD numbers above 16 MB, it is clear that is no large 256 MB L3-cache. The AMD EPYC 7742 rather consist of 16 CCX which alll have a relatively fast 16 MB L3. So although the 64 cores are one big NUMA node now, the 64-core chip is basically 16x 4 cores, each with 16 MB L3-caches. Once you get beyond that 16 MB cache, the prefetchers can soften the blow, but you will be accessing the main DRAM."

        Quelle

        Also leider kein Shared Cache. Die leichten Vorteile kommen vom Prefetcher.
      • Von PCGH_Torsten Kokü-Junkie (m/w)
        Zitat von Solavidos
        Warmwassergekühlte Server habe ich schonmal gehört. Da geht es aber um die großen RZ von FB. So ein Wassergekühlter kleiner Server für Firmen hab ich noch nicht gehört. Aber es gibt wohl alles
        Wasserkühlungen gibt es in allen Größenordnungen. Von Notebooks bis Rechenzentren, einschließlich einzelner Tower, Racks oder Cabinets in der Mitte. Allerdings ist das wirklich ein Nischenmarkt, da kleine Server weder soviel Abwärme erzeugen, dass sich gegenüber einer Klimatisierung viel Geld sparen ließe noch so leise sein müssen, dass sie direkt im Büro stehen können.

        Zitat von gaussmath
        Eine zentrale Verwaltung (1 L3 Domain) über den I/O-Die würde ja bedeuten, dass keine Latenz besser als ein CCX <-> I/O-Die Link sein kann. Wie sollen dadurch Latenzen von unter 10ns möglich sein? Ich denke daher, dass jedes CCX seinen exklusiven L3 Cache hat. Cross-Cache Zugriffe machen wegen der Latenz und mehrstufigen Verwaltung keinen Sinn.
        Nicht alle Cache-Zugriffe werden zentral verwaltet, sondern nur die auf Remote Caches. Also beispielsweise eine vierte Domain, die sich organisatorisch mit der lokalen L3-Stufe überlappt. Das wäre zwar unsauber, aber trotzdem fehlerresistent, da nur bei einem Miss im Überlappungsbereich, also im lokalen L3, überhaupt auf diese Domain zugegriffen wird und AMD die Caches ohnehin als Victim behandelt. Noch simplere, noch lahmere Alternative: Der RAM-Controller, der ohnehin nach einem Cache-Miss im lokalen L3 angesprochen wird, behandelt die Gesamtheit aller L3s als Buffer. Dann ergibt sich aus Sicht des einzelnen Kerns gar keine zusätzliche Domain und somit auch keine Nachteile durch die Funktion. Im Gegenteil, man hat relativ simpel die Daten-Kohärenz über alle Caches gewährleistet und das muss AMD sowieso machen, denn die Unterteilung der Zwischenspeicher ist für laufende Software transparent.

        Umgekehrt resultieren daraus natürlich kaum Geschwindigkeitsvorteile, man spart sich nur die reinen Zugriffslatenzen von DRAM und hält Arbeitsspeicher-Datentransferrate für andere Tasks frei. Aber genau diese Minimalvorteile zeichnen sich auch in den Messergebnissen ab.
      • Von Buggi85 Software-Overclocker(in)
        Zitat von TheBadFrag
        Dann zeig mir mal wie ich ein Premiere Projekt in 3 Teile aufteilen soll und mit welcher Software das geht. Dir ist schon klar das ich nicht nur Video A nehme und das in Video B konvertiere?
        Von Hand in 3 Projekte zu teilen braucht mehr Zeit als man durch gleichzeitiges Rendern jemals wieder reinholt. Ich müsste dann alle auf einander abhängig und dubliziert erstellte Videos 3 mal machen. Gefällt einem etwas nicht muss man es nicht 1x ändern, sondern in allen 3 Projekten.

        Adobe Premiere hat nichts mit V-Ray oder Tomatenmark aus der Tube zu tun.
        Da du von Videorendern sprichst ist das Unterfangen generell etwas schwierig und nur mit Knebellösungen machbar. Du wirst wahrscheinlich nicht in MJPEG rendern, somit ist eine Job Aufteilung nur die halbe Miete bei der du am Ende alle Jobs wieder zusammen rendern musst. Dein Problem werden u.a. die Container und Header sein. Immer dann wenn du auf komprimierten Output gehst hast du Keyframes und I, P, B Frames in dem Strom. Da nur die Keyframes ganze Bilder sind und dazwischen die Veränderungen beschrieben werden, kannst du keinen nahtlosen Strom durch Parallelität erzeugen, weil die anderen Rechner keine Bilder rendern können deren Informationen von dem letzten Frame abhängen.
        Was du also bräuchtest wäre eine Netzwerklösung bei der alle Rechner gemeinsam am selben Frame arbeiten oder aber einen Job der vorab die Keyframes berechnet und diese segmentiert an die Rechner verteilt, damit diese dann eine jeweilige Range rendern können. Technisch bräuchtest du wohl einen GBit Downlink je Client.
      • Von TheBadFrag Lötkolbengott/-göttin
        Zitat von BigBoymann
        Versehe dich nicht, Netzwerkrender ist in drei Minuten gebaut.

        Am billigsten ist es mittels eines KVM Switch, denn beim Rendern musst du ja nicht eingreifen, also Job erstellen Rendern lassen und einfach zum nächsten Hardware Rechner switchen. Moderner geht es über RemoteDesktop.
        Und die Möglichkeiten von HPC Cluster sind da noch gar nicht genannt.

        Aber wenn man natürlich gebunden ist an Mac oder Windows, dann sind die o.g. Möglichkeiten wohl die simpelsten.

        P.S.
        Ist natürlich nur eine andere Art der Parallelisierung, aber ich hoffe doch ,dass du nicht ständig jedes Video neu renderst und dafür das zuvor gemachte brauchst! Weil dann ist dir in vielerlei Hinsicht nicht zu helfen.
        Dann zeig mir mal wie ich ein Premiere Projekt in 3 Teile aufteilen soll und mit welcher Software das geht. Dir ist schon klar das ich nicht nur Video A nehme und das in Video B konvertiere?
        Von Hand in 3 Projekte zu teilen braucht mehr Zeit als man durch gleichzeitiges Rendern jemals wieder reinholt. Ich müsste dann alle auf einander abhängig und dubliziert erstellte Videos 3 mal machen. Gefällt einem etwas nicht muss man es nicht 1x ändern, sondern in allen 3 Projekten.

        Zitat von Buggi85
        V-Ray kann problemlos im Netzwerk rendern. Eigentlich kenne ich das gar nicht anders von Renderfarmen.
        Adobe Premiere hat nichts mit V-Ray oder Tomatenmark aus der Tube zu tun.
      • Von gaussmath
        Zitat von yummycandy
        Robert Halock sprach mal von 1-2ns über die IF vom CCD bis zum IOD. Müsste also am Verwaltungsaufwand liegen.
        No way. Von einem CCD zum I/O-Die müssen es ja ca. 35-40ns sein, weil die Inter-Core-Latenz (2 mal CCD <-> I/O-Die) bei ca. 70-80ns liegt.

        Zitat von PCGH_Torsten
        Wäre es direkte DRAM-Zugriffe ohne L3-Beteiligung, müssten die Latenzen jenseits von 16 MB exakt denen des DRAM entsprechen. Tatsächlich waren sie im verlinkten Test aber selbst im L3-Worst-Case noch niedriger als im DRAM-Best-Case.
        Oder es ist halt einfach ein Mittelwert aus L3 und RAM Zugriffen.

        Zitat von PCGH_Torsten
        Verwalten lässt sich das dank des zentralen I/O-Dies relativ einfach. Aus Sicht eines Kerns sind "alle anderen L3s" eine weitere Stufe respektive ein langsam antwortender Teil des (nicht ganz so) einheitlichen L3. Interessant wäre noch, ob die hohe Latenz allein aus dem IF resultiert, oder ob die Verwaltungslogik direkt mit dem Speicher-Controller assoziiert ist.
        Eine zentrale Verwaltung (1 L3 Domain) über den I/O-Die würde ja bedeuten, dass keine Latenz besser als ein CCX <-> I/O-Die Link sein kann. Wie sollen dadurch Latenzen von unter 10ns möglich sein? Ich denke daher, dass jedes CCX seinen exklusiven L3 Cache hat. Cross-Cache Zugriffe machen wegen der Latenz und mehrstufigen Verwaltung keinen Sinn.
      Direkt zum Diskussionsende
  • Print / Abo
    Apps
    PCGH Magazin 08/2026 PC Games 07/2026 play5 08/2026 N-Zone 07/2026 Linux Magazin 07/2026 LinuxUser 07/2026 Raspberry Pi Geek 07/2026
    PC Games Hardware PC Games Linux Magazin Raspberry Pi Geek Computec Kiosk