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

[TheBadFrag]

Dann zeig doch mal Benchmarks, dass es so ist. Ich habe weiter oben welche verlinkt, dass es nicht so ist.

Der 3900X ist keine 5% vom schnellsten 12 Kerner von Intel entfernt, der aber das Doppelte kostet: Premiere Pro CPU Roundup: AMD Ryzen 3, AMD Threadripper 2, Intel 9th Gen, Intel X-series

Ja und die CPUs da sind alle ohne OC. Die Intel kann man noch sehr gut hochtakten, die AMD kann man quasi nicht übertakten.(oder sie werden langsamer durch OC)

Hier ein kleines Video dazu(ja es ist Linus...)

Eingebundener Inhalt

Youtube

youtube.com/watch/?v=8swaS6H5OiU

An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst: Alle externen Inhalte laden Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.
Für mehr Informationen besuche die Datenschutz-Seite.

Bin gespannt wieviel schneller der fertige Server sein wird, wo auch anständige Kühlung drin ist.

...und selbst wenn man am Ende nur 15% schneller wird für das dreifache an Kosten ist das auch egal. Denn 15% von einem 10 Stunden Renderjob sind 1,5 Stunden die man spart. Und wenn man das nicht nur 1x sondern 100x macht... oder wenn man nur einen Abschnitt vorrendert und auf das Ergebnis wartet...

 

[Freiheraus]

Hier sieht das auch nicht so aus als ob der 3950X nicht die Krone an sich reißen könnte, wenn der 3900X schon so dicht an Skylake 18 Kerner und TR 16 Kerner dran ist: AMD Ryzen 7 3700X & Ryzen 9 3900X Workstation Performance – Techgage

Edit:
Naja, wenn ein Renderjob gar so wichtig ist und einen halben Tag dauert, dann geht man eher auf Sicherheit und Stabilität, sprich kein (starkes) OCing und bei Bedarf ECC...

 

[TheBadFrag]

Edit: Naja, wenn ein Renderjob gar so wichtig ist und einen halben Tag dauert, dann geht man eher auf Sicherheit und Stabilität, sprich kein (starkes) OCing und bei Bedarf ECC...

Wieso sollte OC instabil sein? Wenn man richtig Übertaktet, dann läuft das System auch stabil. Mein System läuft mit 4,5 Ghz allcore tagelang ohne Probleme. Für mehr Takt müsste ich die AiO gegen eine custom Wakü tauschen, da ich im Moment temperaturlimitiert bin. Und ein Rednerjob, der einen halben Tag dauert ist nichts besonderes. Ich render mitlerweile in h.265 und das dauert immer brutal lange.(obwohl ich nicht mal in bester Qualität render)

 

[PCGH_Torsten]

Woraus schließt du diese Erkenntnis? Ein CCX hat exklusiv 16MB und dann geht's (sehr wahrscheinlich) auf den RAM, so dass bei 32MB im Mittel 132ns herauskommen. Jedes CCX hat mit Sicherheit sein eigene L3 Domain. Wenn die alle bei einer Abfrage miteinbezogen werden würden, hätte man eine 6-stufige Hierarchie. Das wäre verwaltungstechnisch totaler Overkill.

Aber da man IF und RAM ja jetzt unterschiedlichen takten kann, müsste man das doch irgendwie testen können?!

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. Nicht spürbar besser, sodass kaum Vorteile für die Arbeitsgeschwindigkeit resultieren, aber dass es gar keine Überlappung der Latenzspannen gibt, schließlich quasi aus, dass es sich um gleichartige Zugriffe handelt. Auch wird der L3 von AMD in seiner Gesamtgröße als shared vermarktet; das würde sehr böses Blut geben wenn Zugriffe ausschließlich innerhalb eines CCX möglich wären.

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. So bescheuert letzteres auch klingt, aber vom Interconnect habe selbst ich mir eine höhere Performance erhofft. Die paar ns Unterschied zum Arbeitsspeicher passen dagegen gut zu einem "regulären RAM-Zugriff", der seine Daten aus verdammt schnellen, IF-angebundenen SRAM statt lahmen DRAM-DIMMs bezieht. Das ließe sich sogar mit einer normalen, 4 stufigen Verwaltung realisieren.

 

[yummycandy]

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.

Robert Halock sprach mal von 1-2ns über die IF vom CCD bis zum IOD. Müsste also am Verwaltungsaufwand liegen.

 

[Solavidos]

Ja und die CPUs da sind alle ohne OC. Die Intel kann man noch sehr gut hochtakten, die AMD kann man quasi nicht übertakten.(oder sie werden langsamer durch OC)

Hier ein kleines Video dazu(ja es ist Linus...)

...und selbst wenn man am Ende nur 15% schneller wird für das dreifache an Kosten ist das auch egal. Denn 15% von einem 10 Stunden Renderjob sind 1,5 Stunden die man spart. Und wenn man das nicht nur 1x sondern 100x macht... oder wenn man nur einen Abschnitt vorrendert und auf das Ergebnis wartet...

Ich kann mir aber nicht vorstellen das professionelle Anwender übertakten. Als wenn die eine bessere Kühlung als den Boxed Lüfter einbauen und herumexperimentieren.... Stabilität ist alles im prof. Bereich und was bringt einem ein mögliche schnelleres Rendering wenn das System abstürzt ? Da wird doch alles @stock laufen nehme ich an.

 

[DaHell63]

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.

Mich würde mal interessieren wo Ihr die knapp 54600 Punkte für einen 2970WX gefunden habt. Der höchte Eintrag unter Windows sind 46418 Punke von einem OC ~@4.2GHz 2970WX.
System manufacturer System Product Name
- Geekbench Browser


Da kann man dann auch mal einen OC i9 9980XE dagegen setzen
System manufacturer System Product Name
- Geekbench Browser

 

[TheBadFrag]

Ich kann mir aber nicht vorstellen das professionelle Anwender übertakten. Als wenn die eine bessere Kühlung als den Boxed Lüfter einbauen und herumexperimentieren.... Stabilität ist alles im prof. Bereich und was bringt einem ein mögliche schnelleres Rendering wenn das System abstürzt ? Da wird doch alles @stock laufen nehme ich an.

Es gibt wassergekühlte OC Server. Soviel dazu. Wenn es Geld bringt, dann wird es gemacht.
...und wieso soll OC instabil sein? Es gibt 1000 Fertigsysteme überall zu kaufen, die Pre-OCed sind ab Werk mit voller Garantie und Gewährleistung. Niemand verkauft einen PC, der 5 Mal am Tag einen Bluescreen erzeugt.

 

[BigBoymann]

Ja und die CPUs da sind alle ohne OC. Die Intel kann man noch sehr gut hochtakten, die AMD kann man quasi nicht übertakten.(oder sie werden langsamer durch OC)

Hier ein kleines Video dazu(ja es ist Linus...)

Eingebundener Inhalt

Youtube

youtube.com/watch/?v=8swaS6H5OiU

An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst: Alle externen Inhalte laden Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.
Für mehr Informationen besuche die Datenschutz-Seite.

Bin gespannt wieviel schneller der fertige Server sein wird, wo auch anständige Kühlung drin ist.

...und selbst wenn man am Ende nur 15% schneller wird für das dreifache an Kosten ist das auch egal. Denn 15% von einem 10 Stunden Renderjob sind 1,5 Stunden die man spart. Und wenn man das nicht nur 1x sondern 100x macht... oder wenn man nur einen Abschnitt vorrendert und auf das Ergebnis wartet...

Dannkauf doch einfach drei Rechner von AMD und lass drei Renderjobs parallel laufen, dann bist du plötzlich um den Faktor 2,6 schneller

 

[TheBadFrag]

Dannkauf doch einfach drei Rechner von AMD und lass drei Renderjobs parallel laufen, dann bist du plötzlich um den Faktor 2,6 schneller

Wenn das möglich wäre, würde ich das sofort machen. Leider gibt es solche Sachen wie Netzwerkrender leider nicht.

 

[Duvar]

Natürlich kann man die AMD Prozessoren auch übertakten. Ab Werk droppen die unter hoher Last teilweisen Richtung 4GHz. Hab schon genug 3900X Prozessoren gesehen die allcore 4. 3 bis 4.4GHz stabil laufen plus RAM Optimierung und schon nehmen die sich nicht mehr viel gegenüber Intel Pendants.
Außer der AMD Prozessor verbraucht vllt die Hälfte
Mit OC meine ich übrigens nicht PBO+Auto OC, weil das ist schrott.
Hier ohne OC und Tuning YouTube
Bald gibts ja den 3900 non X für 450€, dann frohlocket.

Edit: Taktnormiert ist der 3900X ~20% schneller als der 2920 TR YouTube (beide @ 4GHz) und bald gibt es diese Power für round about 450€ mit dem non X Modell? Das ist doch krank man!

 

[Solavidos]

Es gibt wassergekühlte OC Server. Soviel dazu. Wenn es Geld bringt, dann wird es gemacht.
...und wieso soll OC instabil sein? Es gibt 1000 Fertigsysteme überall zu kaufen, die Pre-OCed sind ab Werk mit voller Garantie und Gewährleistung. Niemand verkauft einen PC, der 5 Mal am Tag einen Bluescreen erzeugt.

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

 

[BigBoymann]

Wenn das möglich wäre, würde ich das sofort machen. Leider gibt es solche Sachen wie Netzwerkrender leider nicht.

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.

 

[Buggi85]

Wenn das möglich wäre, würde ich das sofort machen. Leider gibt es solche Sachen wie Netzwerkrender leider nicht.

V-Ray kann problemlos im Netzwerk rendern. Eigentlich kenne ich das gar nicht anders von Renderfarmen.

 

[gaussmath]

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.

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.

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.

 

[TheBadFrag]

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.

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.

 

[Buggi85]

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.

 

[PCGH_Torsten]

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.

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.

 

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