Intel i9-7920X: 12 Kerne mit 2,9 GHz für 1.189 US-Dollar

@ Gubb3L
Naja, wie soll man dir Belege vorlegen können, wenn das Produkt nichtmal im Laden steht!? Darüber schon mal nachgedacht? Frag dich mal, warum AMD nix zur NUMA Aufteilung der Modelle sagt? Frag dich mal, warum AMD im Moment bis maximal 2P geht? Frag dich mal, warum nirgends von einem Quadchannel oder Oktachannel Interface gesprochen wird, sondern immer nur von 4x oder 8x Kanälen? Schau dir die Bilder an, wie Epyc intern aufgebaut sein soll/verdrahtet ist, schau dir die Intel Folien an, auch wenn das dort schon etwas grenzwertig dargestellt ist usw. usf.
Es liegen genügend Indizien auf dem Tisch, die man einfach nur mal deuten muss... Die Frage ist also, WIE warscheinlich hälst du es, durch all diese Indizien, dass es KEIN Multi-NUMA-Node Konstrukt wird?? Und vor allem, welche Indizien sprechen für ein SMP Konstrukt?


"Das NUMA Node Probleme mit sich bringt ist mir klar"??
Den versteh ich persönlich nicht? Was meinst du damit?
-> "NUMA Node" bringt keine Probleme. Probleme bringt ein Multi-Node System dann, wenn Software, die dafür nicht ausgelegt/angepasst ist verwendet wird und man dieses System ggü. einem besser dafür geeigneten Ansatz vergleicht. Und das trifft im Moment auf 99,999% des (HighEnd) Desktop Marktes (SMP only) zu sowie in großen Teilen auf Server-Systeme und Workstations, die bis dato bis auf Ausnahmen maximal mit 2x Nodes in Berührung gekommen sind. :wink: Vielleicht lässt du als Beleg für diese Aussage dazu AMDs eigene Folien durchgehen, zumindest für letztere Aussage. ;)
Sowas siehst man aber bspw. nicht im Cinebench, denn der Skaliert 1A mit dem Nodecount...



@mr.dude
Schonmal was von UPI gehört? Oder vielleicht QPI?
Mit dem ersten Satz liegst du nämlich ganz leicht daneben ;) Eine logische Verdrahtung wäre, entgegen deiner Aussage, durch UPI/QPI möglich. Und damit hast du quasi das gleiche in Bund. Nichts anderes, nur noch weiter extern gelagert ist ein 2-8x Socket Xeon System heute. Und auch AMD hat das in der Vergangenheit, ganz ohne "Stichwort Infinity Fabric" schon geschafft. Stichwort G34...
Oder an welcher Stelle sprichst du es dem Hersteller ab, anstatt 2-8x Sockets mit 2-8x CPUs einfach 2-8x der selben! DIEs zu nehmen und diese über die selbe Verbindungstechnik zusammenspielen zu lassen!? Offenbar bist du dir ja sicher, dass es nicht möglich ist im Moment... Kannst du dann doch für die Dummen unter uns auch erklären!?



@SkizZlz
der Grundtakt ist doch irrelevant. Wichtig wird eher, wie viel Turbo hält das Teil im Alltag, bzw. wie viel Leistung kommt hinten raus... Oder interessierst du dich wirklich für Papierwerte?
Selbst die TDP dürfte eigentlich nebensächlich sein, die Teile sprengen, alle samt, Intel wie AMD, AMD wie NV (bei den GPUs) ihre TDP Angaben, wenn man da mal Volllast drauf drückt. Kühlbar muss es sein. Bei über 150W dürfte das schon sportlich werden.

Mich würde viel eher interessieren, ob Intel bei den 12+ Core DIEs den Deckel verlötet...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@fdsonne
Mich interessiert es einfach.
Denke der wird auch beim 12 Kerner nicht verlötet sein, wenn doch find ichs gut, mal abwarten bis es erste Tests dazu gibt.
 
"Das NUMA Node Probleme mit sich bringt ist mir klar"??
Den versteh ich persönlich nicht? Was meinst du damit?
-> "NUMA Node" bringt keine Probleme. Probleme bringt ein Multi-Node System dann, wenn Software, die dafür nicht ausgelegt/angepasst ist verwendet wird und man dieses System ggü. einem besser dafür geeigneten Ansatz vergleicht. Und das trifft im Moment auf 99,999% des (HighEnd) Desktop Marktes (SMP only) zu sowie in großen Teilen auf Server-Systeme und Workstations, die bis dato bis auf Ausnahmen maximal mit 2x Nodes in Berührung gekommen sind. Vielleicht lässt du als Beleg für diese Aussage dazu AMDs eigene Folien durchgehen, zumindest für letztere Aussage.
Sowas siehst man aber bspw. nicht im Cinebench, denn der Skaliert 1A mit dem Nodecount...

Hauptsache man hat das blaue Lied auf den Lippen und spekuliert mal munter drauf los, ohne irgendwelche Belege oder Anhaltspunkte!
Nach deiner Definition ist schon Ryzen ein NUMA Node, komischreweise ist der von den ganzen Software Problemen übehaupt nicht betroffen, die du so anführst!
Nach dem neusten CB Test schlägt ein Ryzen 1800X und 1600X einen i9 7800X im Gaming, wenn er mit DDR4 3200 MHZ ausgestattet wird (720p).
Vielleicht solltest du mal deine vorlaute Klappe halten bis die ersten Tests vom TR draußen sind, eventuell ist dann das Thema aktuell oder einfach nur ein Furz im Wind!
 
Hauptsache man hat das blaue Lied auf den Lippen und spekuliert mal munter drauf los, ohne irgendwelche Belege oder Anhaltspunkte!
Hier sind für ein Dual-CPU EPYC System 8 NUMA Nodes, auf diesem Screenshot zu sehen, wenn das kein Beleg ist, dann zumindest wohl ein Anhaltspunkt!

Nach deiner Definition ist schon Ryzen ein NUMA Node, komischreweise ist der von den ganzen Software Problemen übehaupt nicht betroffen, die du so anführst!
Jede CPU ist mindestens ein NUMA Node und damit hat auch keine SW ein Problem, aber manche begreifen nichts und leugnen alles, weil sie keine Ahnung aber viel Fanboyparolen im Kopf haben :wall:
 
Ryzen hat eine Verbindung zwischen zwei einzelnen CCX, das ist nach euerer Definition bereits ein NUMA Node, kannst du mir bitte erklären, wo ein Kaby oder Coffee Lake diese Verbindung hat?
Genauso ein Skylake X?

Wenn du zu blöd bist zu verstehen was ich schreibe, na dann, um was geht es denn, um die Sache oder AMD schlecht zu machen?
Ich frage mich immer noch, wo die Belege sind, das Epyc oder TR sich wie ein NUMA Node vehalten, wo gerade Ryzen das Gegenteil beweißt und der Epyc Test bei Anand Tech euch auch nicht weiter hilfft im AMD bashing!
 
Zuletzt bearbeitet:
Du scheinst da was grundlegendes nicht verstanden zu haben, würde sich Ryzen/TR/Epyc wie ein Knoten verhalten wäre diese Diskussion doch obsolet. Nach den bisherigen Infos und dem bisherigen Stand der Technik ist jedes Die ein Numa Knoten, denn jedes Die hat einen eigenen MC auf den aber alle Kerne aller Dies per gemeinsamen Adressraum über die IB Zugriff haben (das ist die Definition von Numa), wie der Anandtech Test beim Speicherzugriff ja auch schön zeigt, ja man könnte das selbst auf den L3 Cache des Ryzens runterbrechen, Stichwort Threadpinning pro CCX, ist dort aber noch nicht so gravierend.

Wie gut das funktionieren wird, muss sich erst zeigen, die Problematik, dass TR/Epyc mehrere Numa Knoten sind kann man aber nicht "weg-fake-new'sen".
 
Ryzen hat eine Verbindung zwischen zwei einzelnen CCX, das ist nach euerer Definition bereits ein NUMA Node,
Lies Dir die Bedeutung des Begriffs NUMA durch. Es gehört definitiv ein getrennter Speicher dazu, den man auch bei den Speicherbenchmarks für EPYC für die vier Dies eindeutig sehen kann. Ob es sich bei den beiden CCX von Ryzen schon um zwei NUMA-Knoten handelt, könnte man nur dadurch herausfinden, dass man entsprechende Streambenchmarks mit gepinnten Threads durchführt. Da aber bisher noch nie ein HEDT-System NUMA-Knoten hatte, weiß faktisch niemand von den Redakteuren auf was er da zu achten hätte. Fakt ist, AMD meldet die beiden CCX nicht als NUMA-Knoten dem Betriebssystem, was aber für die vier Dies eines EPYCs gemacht wird. Was man bei Anandtech sehen konnte, dass es wegen dieser Konstruktion bei Ryzen eine erhöhte Latenz zwischen den beiden CCX gibt. Solange sie diese beiden CCX am selben Memory Controller hängen, wäre das nicht ideal aber das macht es nicht zu zwei NUMA-Knoten.
 
Die CPU ist für die Software vollkommen transparent, wen interessiert das NUMA-Bashing hier? IF kann viel mehr als bisherigen Kohärenz-Protokolle. Ihr zeigt die ganze Zeit auf den Braunbären und habt aber nen Chiwawa im Kopf und meint "das ist ja auch ein Hund"...

Holt
Auf den Quatsch geh ich nicht ein, es macht einfach keinen Sinn mit jemandem zu diskutieren, der nicht mal rechnen kann.
2 Zepplin Dies werden sicher nicht mehr verbrauchen als 2x 1 Zepplin Die, erst recht nicht mit neuem Stepping. Klar könnte Threadripper bis 220W ziehen, wenn du es mit nem Powervirus drauf anlegst, das aber bei 3,5-3,7GHz allcore-Turbo im Torture-Test. Das packt nicht mal der 7900X mit seinen nur 10 Kernen, schau dir den THG-Test doch an...
 
Zuletzt bearbeitet:
Stimmt, wie können wir nur in einem Hardwareforum über die Vor-/ und Nachteile bestimmter Architekturen/Szenarien/Workloads sprechen... besser ist natürlich Verschweigen und blos nicht ansprechen, dann geht die Problematik von alleine weg, wie ja sonst auch, oh man :wall:

Und wie effektiv die IB ist, weißt du natürlich schon, is klar ne? Dass TR/Epyc ein NUMA-System ist(wird), ist Fakt, wie sehr die IB den bisherigen Flaschenhals bei NUMA lösen kann, müssen Test zeigen, die haben wir aber noch nicht. Was soll also die schönrednerei von euch? Niemand streitet ab, dass es besser sein könnte.
 
Zuletzt bearbeitet:
Da gibts nichts zu verschweigen, es ist einfach Schwachsinn, weil es für die Software eh 100% transparent ist. Hier wird was konstruiert um das zu bashen, das hat nichts mit konstruktiver Kritik zu tun. Wenn man sowas diskutieren möchte, das bist du hier aber auch einfach am falschen Ort.
 
Zuletzt bearbeitet:
Korrekt, abgesehen von speziell angepasster Software, sieht die Software einfach den kompletten Speicherbereich, hat aber keine Ahnung über welchen MC der Zugriff letzten Endes läuft, wenn der über die IB läuft, ist das in jedem Fall langsamer als wenn der Zugriff über den MC des Dies auf dem der Thread ausgeführt wird läuft.
 
nicht langsamer, nur höhere Latenz, was sich fast immer maskieren lässt, dafür sind die Caches groß genug.
Es gibt einige Dinge, die achitekturbedingt etwas langsamer laufen, wenn z.B. die L3-Caches als Einheit laufen müssen, weil die Anwendung komplett da hineinpasst, aber das sind Spezialfälle. Ansonsten ist dieser NUMA-Blödsinn einfach BS, weil IF alles für alle Geräte transparent durchadressiert. Weil die OS das jetzt so erkennen und es verwaltungstechnisch vorteilhaft ist, heißt das noch lange nicht, dass hier auch echtes NUMA stattfindet.
Man verwendet dasselbe Protokoll um die zwei Module innerhalb des Zepplin-Dies miteinander zu vernetzen.
 
Zuletzt bearbeitet:
nicht langsamer, nur höhere Latenz

Ähm ja, höhere Latenz=langsamer. Genau das sieht man ja schon beim Pinning auf ein CCX vs. noPinning, und dort betrifft das "nur" den L3, diese Problematik wird deiner Ansicht nach schwächer, je mehr über die Fabrik läuft, ist klar, ne?

Und btw. niemand hier hat ccNUMA angesprochen, ausser dir...
 
Zuletzt bearbeitet:
Ryzen hat eine Verbindung zwischen zwei einzelnen CCX, das ist nach euerer Definition bereits ein NUMA Node, kannst du mir bitte erklären, wo ein Kaby oder Coffee Lake diese Verbindung hat?
Genauso ein Skylake X?

Ringbus/jetzt Mesh. Der Unterschied ist, dass man sich bei den herkömmlichen System nicht drum kümmern muss/kann, wo der Speicher (wo die CPU die Daten zum Rechnen hernimmt...) sitzt, weil das in der Hardware mehr oder weniger effizient gelöst ist, sodass die Nutzung problemlos (=mit erwartbaren Ergebnissen) möglich ist. Bei NUMA-Systemen hat man aber 2/x CPUs mit erstmal "eigenem" Speicher (der den jeweils anderen bekannt ist) und abhängig von der Implementierung der SW kann es, wenn man nicht darauf achtet, welchen Speicher man gerade verwendet zu spürbaren Performanceproblemen kommen.

Versuch einer Analogie: stell dir einen Industriebetrieb A vor, der ein Produkt fertigt: dieser hat 16 Arbeiter, alle arbeiten in einer Halle, in der auch die Materialien gelagert sind (so macht das der Intel Mehrkerner). Jetzt hast du einen Betrieb B, der hat 2 Hallen, in denen auch 16 Leute arbeiten und dazwischen ist eine Straße über die für die Produktion benötigte Materialien hin und her gefahren werden müssen, da man in einer Halle nicht genug Platz hat. Auch wenn das Lager in A nicht effizient ist, ist es sehr wahrscheinlich, dass die Produktivität in A höher ist, als in B... AMD verspricht jetzt mit dem IF, dass aus der Straße, die bisher bei Intel QPI/UPI hieß (oder HT... – AMD hat da lang nix gemacht und IBM/SPARC/... kennt man nicht), irgendein hypermodernes Rohrpostsystem wird, mit dem man bei der Produktionsplanung (Softwareentwicklung) gar nicht mehr berücksichtigen muss, dass man 2 Gebäude hat. Getestet wurde noch nix und genaues sagen kann man auch nur nach Anwendungsfall...
Leider kann sich der gemeine Forenuser mit seinem 10-100m²-Hobbyraum nun nicht vorstellen, was beide Ansätze für Vor-/Nachteile haben und will jetzt natürlich das hypermoderne Rohrpostsystem haben – große Hallen kosten zuviel Kohle und das ist ja jetzt sicher besser.

Wenn du zu blöd bist zu verstehen was ich schreibe, na dann, um was geht es denn, um die Sache oder AMD schlecht zu machen?
Frage mich, warum ich das oben getippt habe.
Mal ein paar Fragen an dich: Weißt du wie man Speicher in C managt? Hast du schon mal fleißig alle Wikipedia-Artikel (wirklich alle) zum Thema gelesen? FPGAs programmiert? Schon mal eine theoretische Informatikgrundvorlesung besucht und erfolgreich den Schein erworben? – falls du eine dieser Fragen mit ja beantworten kannst: google "NUMA Programmierung", lese ein bisschen und überlege, ob du weiterhin zu deinen Aussagen stehst. Falls ja: Glückwunsch, du bist blöd, dumm, ein Kretin. Falls nein: du erkennst deine eigenen Fehler, bist geistig gewachsen und ich freue mich, dass ich Menschen zum Denken angeregt habe :wink:.
Sind alle Fragen böhmische Dörfer für dich: bitte sehe ein, dass du nicht alles wissen kannst, stelle Fragen und schrei' nicht mit Genuss jeder Sau, die durchs Dorf getrieben wird, hinterher, am Ende wird man selber so.


Ich frage mich immer noch, wo die Belege sind, das Epyc oder TR sich wie ein NUMA Node vehalten, wo gerade Ryzen das Gegenteil beweißt und der Epyc Test bei Anand Tech euch auch nicht weiter hilfft im AMD bashing!
s.o....
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh