Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
BerichtAMD Epyc 7003: Milan mit Zen 3 bietet auch CPUs mit 32 MB L3 pro Kern
da steht gar nichts dran. aber wenn Quad-Channel 100 GB/sek schaffen und ein TR 3970 Schaft sogar mehr dann sind 8 Channel und 200 GB/sek gar nicht so fern.
Da muss nichts dran stehen, da steht: DDR4-200. Wenn man sich etwas auskennt, weiß man, dass das DDR4-3200 heißen müsste und dann zu einem Schema passt: DDR2-800, DDR3-1600...
Es geht überhaupt nicht darum, ob 200 GB realistisch sind, das ist - völlig indiskutabel - ein Schreibfehler.
Im übrigen ist das nicht "nicht fern" sondern es wären exakt 204,8 GB/s, das ist simple Mathematik.
Man baut ein Script, das an Kern x y% Last anlegt, um in der entsprechenden Farbe angezeigt zu werden.
Außerdem muss entweder die Aktualisierungsrate des Task Managers stark erhöht oder n Zeitraffer gemacht werden.
Ein Traum - insbesondere wenn sich Rechenzentren dadurch konsolidieren können, ein Rack der neuen Generation ersetzt gefühlt mehr als zwei vollbestückte der vorletzten Generation 😁🥰
@(-_-)@fox40phil man achte auf den ersten Kommentar: „Now run DOOM on it“ 😂🤣 der Autor kündigts aber bereits an - und hat Pong lauffähig. Zu geil, muss ich morgen im Kollegenkreis teilen - und unseren RZ-Nerds derartige Spielchen gleich ausreden ^^
Zuletzt bearbeitet von einem Moderator:
(Ergänzung)
In Games würde das theoretisch schon was bringen, weil der L3 Cache eben der Cache ist, der die RAM Zugriffe abfedert, die bei Zen2 und 3 eben über die IF laufen, also extern sind. Dennoch würde so ein "256MB" L3 Cache Teil schlicht unter gehen im Gaming.
Du hast die Problemstellung nicht verstanden (oder ich dir nicht ausreichend erklärt):
Abgesehen von der Frage ob der Datensatz in den Cache passt, ist natürlich auch relevant mit welcher Bandbreite und Latenz auf die Daten zugegriffen werden muss.
Wenn die Anwendung selber in den Cache passt, ist der Datendurchsatz zum Verarbeitungssatz oft nicht mehr das Problem. Das ist aber sehr aufwändig und am Ende wohl nur durch testen des individuellen Anwendungsfalls herauszufinden.
Ich frag mich, warum man damals im CPU Core Umfeld nie wollte, dass aus 4x3GHz beim Quardcore = 12GHz gemacht wurden, aber beim Cache ist das gängige Praxis und dann vergleichen die Nasen ohne den technischen Zusammenhang sogar noch die Mengen stumpf
Der Prozessor hat vllt 256MB total, aber eben in 8x32MB verteilt. Beim 8C mit 8x32MB bedeutet das, jeder Kern hat volle 32MB und für jeden Querzugriff untereinander MUSS über die lahme und latenzschwache IF gegangen werden.
Weil das eine totaler Schwachsinn ist. 4 Kerne skalieren nicht zu 100 % auf 12 GHz. Nie.
Speziell hier wird davon ausgegangen, dass keiner CPUs kauft, bei denen viel weniger Kerne benötigt werden als vorhanden sind, insofern ist der Cache als ganzes durchaus korrekt.
Ich habe jetzt keine Daten zur Hand, aber der zugriff auf die anderen Cache Teile sollte nach wie vor deutlich besser sein als auf den RAM, insbesondere aus Latenzgründen.
Naja, ich sag mal so, uns kostet ein Mischbetrieb deutlich höhere Betriebsaufwände. Weil eben so näckische Sachen wie Livemigrationen nicht mehr gehen.
DAS ist tatsächlich ein Punkt den viele nicht kennen oder gar verstehen, weil das sehr tief in die technischen Grundlagen geht.
Ändert aber nichts daran, dass EPYC für viele die bessere Wahl sind - sofern sie erhöhte Ansprüche haben.
Mit den F-CPUs ist auch Intels Taktvorteil nur noch sehr eingeschränkt.
Das Argument, dass die CPUs preislich ja so nebensächlich sind (so lesen sich deine Aussagen) ist aber auch Quatsch. Ich kenne die Preise bei HPE ganz gut und da dampfen nicht nur CPU-Preise weg, auch Platten und Controller sind teilweise erstaunlich günstig.
Die letzten FC16G HCAs hab ich z.B. als DualPort für den Preis der Singleport Karten bekommen.
Ergänzung ()
Bigfoot29 schrieb:
@Nagilum99 : Ich sage mal: Es ist NOCH ein Nischenproblem. Im Jahre 4 "nach AVX512 Geburt" [Viel Text]
Nein, es bleibt ein ein Nischenproblem. AVX512 braucht Aufgaben die sich mit diesem instruktionssatz (deutlich schneller) lösen lassen. Wenn das der große Helbringer wäre, hätte man schon längst viel mehr Software dorthin optimiert. Das ist oftmals nicht mehr Arbeit als einen aktuelleren Compiler zu nutzen.
Hier ein Beispiel:
Übrigens gibt es nach wie vor etliche Anwendungen, die nicht mal von AVX(2) profitieren. Darüberhinaus gehen einige Dinge auch noch besser über ASICS oder GPUs - wo wir gerade bei Videocodierung wären.
AVX512 soll ja mit Genoa/Zen 4 kommen, aber ich persönlich kenne niemanden (bewusst) der irgendeinen Nutzen daraus ziehen würde.
Nein, es bleibt ein ein Nischenproblem. AVX512 braucht Aufgaben die sich mit diesem instruktionssatz (deutlich schneller) lösen lassen. Wenn das der große Helbringer wäre, hätte man schon längst viel mehr Software dorthin optimiert. Das ist oftmals nicht mehr Arbeit als einen aktuelleren Compiler zu nutzen. (..) Übrigens gibt es nach wie vor etliche Anwendungen, die nicht mal von AVX(2) profitieren. Darüberhinaus gehen einige Dinge auch noch besser über ASICS oder GPUs - wo wir gerade bei Videocodierung wären.
AVX512 soll ja mit Genoa/Zen 4 kommen, aber ich persönlich kenne niemanden (bewusst) der irgendeinen Nutzen daraus ziehen würde.
Selbst im HPC-Bereich, wofür es ursprünglich gedacht war, konnte es sich nicht richtig durchsetzen und wenn wir ehrlich sind nicht den Siegeszug des heterogenen Computings mit ASICs und GPUs aufhalten. Irgendwo müssen die Flops ja für die Maschinen herkommen und einfach nur CPUs zu verbauen führt zu einem zu großen, weitläufigen Netzwerk welches wieder seine eigenen Probleme mitbringt.
Die Ausnahme hierbei ist der Fujitsu A64-FX der mit der Scalable Vector Extension, Arm’s Pendant zu AVX, in Fugaku viel Leistung auf die Straße bringen kann. Doch darf man hierbei auch nicht den HBM Speicher auf den CPUs vergessen, welche für eine absurd hohe Speicherbandbreite sorgen und perfekt für Anwendungen wie Computational Fluid Dynamics sind.
Dies werden Intel und AMD ja wohl erst mit Genua und Saphire Rapids in den Markt bringen können um dann die Rolle der CPU als Compute Engine zu “verteidigen”. Bis dahin wird der Siegeszug der GPUs, denke ich, unvermindert weitergehen.
Inwiefern sich diese sehr HPC-zentrische Betrachtung auf den “Normalverbraucher” auswirkt fällt mir bisher schwer zu beurteilen.
Die Ausnahme hierbei ist der Fujitsu A64-FX der mit der Scalable Vector Extension [...] Bis dahin wird der Siegeszug der GPUs, denke ich, unvermindert weitergehen.
Inwiefern sich diese sehr HPC-zentrische Betrachtung auf den “Normalverbraucher” auswirkt fällt mir bisher schwer zu beurteilen.
Der Fugaku ist ein sehr spezieller Rechner der sicherlich für sehr spezielle Aufgabenstellungen konzipiert wurde:
sowohl SVE als auch der RAM-Aufbau. Auch wenn hier immer wieder irrläufer behaupten, dass RAM-Durchsatz alles sei, zeigen auch die Benchmarks auf Computerbase, dass das nicht so ist. HBM hat aber hier einen gravierenden Nachteil: 32 GB für 48 Kerne. Das ist für HPC Knoten (pro Kern) sehr wenig.
"Die Breite der Ausführungseinheiten kann von 128 Bit bis 2048 Bit in 128 Bit-Schritten reichen" <- SVE hat hier übrigens nur deswegen einen breit nutzbaren Vorteil, weil es sehr flexibel ist. Mehr AVX(2) Ausführungseinheiten könnten also viel hilfreicher sein als AVX512. Alles sehr individuell.
(Es ist auch kein Geheimnis, dass der LINPACK nur beschränkt ausagekräftig ist)
Der Normalverbraucher... schwierig. Bei AMD wird das Konzept der gemeinsamen Chips sicher bestand haben, sie sind damit überaus erfolgreich, also wird es geben, was AMD insgesammt für sinnvoll hält.
Das lässt außer acht, dass der 3960 mit UDIMMs betrieben werden kann, Der Epyc aber deutlich teurere RDIMMs benötigt. Je nach Anwendungsfall wären UDIMMs aber ausreichend.
Schaut gut aus! Leider haben meine Freunde aus der IT und dem Dienstleister Bereich eine nicht so hohe Meinung von AMD Serverlösungen. Am Ende des Tages zähle doch die Stabilität des Gesamtsystems.
Das Ur-Doom dürfte von der Größe bestimmt komplett in den Cache der CPU passen. Das dürften traumhafte Ladenzeiten sein, wenn weder Datenträger noch RAM der limitiertende Faktor ist.
Schaut gut aus! Leider haben meine Freunde aus der IT und dem Dienstleister Bereich eine nicht so hohe Meinung von AMD Serverlösungen. Am Ende des Tages zähle doch die Stabilität des Gesamtsystems.
Kann ich nicht nachvollziehen. Betreibe nen AMD Epyc Proxmox Cluster für die Entwicklung.
Läuft einwandfrei. Nächste AMD Server sind schon in der Angebots Phase.
Zur Probe hatte ich ESXI mit VSAN 7 drauf geprügelt lief ebenso ohne Probleme.
So lange es keine abhängigkeiten mit Zertifizierungen ala SAP gibt. Sehe ich aktuell keinen Grund sich nicht doch auch mal AMD Server anzuschauen.
In einem ESXI Cluster nicht alles auf einmal getauscht wird sondern rollierend. Das ist wohl der größere Hehmschuh.
Darf man dann auch alsbald mit den Threadripper 5000 rechnen?
Bisher habe ich da ausser ein paar Gerüchten noch nix gehört.
Viel ändern wird sich ja ausser dem Wechsel auf Zen 3 nicht, 24/32/64 Kerne
ich finde den Turbo Takt im Server Umfeld irgendwie nach wie vor zu gering. Ich meine... 1.5 Ghz weniger als im Desktop wenn man die Topmodelle vergleicht...
Das wir wohl mit Langlebigkeit, Stromverbrauch, wärme und co. zu tun haben. Außerdem wüsste ich auch nicht das Single-Core Turbos im Sever Umfeld so gefragt sind. Zumindest auf Hyper-V / VMware Farmen kommt der bei unseren Kunden nie zum Vorschein, bei der Packungsdichte der VMs. Lieber vernünftiger "Grund" Takt oder All-Core Turbo, meiner Meinung nach.
Die Singlecore bringt AMD ja mit den 1.5V hoch, was zu extremer wärme und Verbrauch führt auf kleinem Raum.
Ich rate mal und sage AMD beschränkt sich auf 1.35V/1.4V im Serverbereich und spart dabei 50% Energie im Boostfall
Wir aktualisieren die HW Clusterweiße - aber gut, wir haben auch nur 2 xD
Da ist eher die fehlende Livemigration das größte Problem..wenn wir zu Epyc gehen würden..schade sowas..nuja ist ja noch ein Jahr+ hin zum HW Wechsel..
?
