@Sun_set_1
Hä? Was hab ich denn versucht die ganze Zeit zu sagen? Genau um diese nicht sonderlich brauchbaren Pauschalen ging es doch.
Ob Linux mit Mehrkern besser skaliert oder nicht, ist doch ein völlig anderes Thema. Der Bench, der verlinkt wurde oben (Indigo) bescheinigt zwischen Linux und Windows in exakt der selben Szene bei einem 2950er quasi gleiche Leistung. Ergo kann es nicht daran liegen. Forscht man bisschen weiter fällt bspw. auf, dass allein das abschalten von SMT bei nem 2990er deutlich Performance bringt unter Windows, während Linux klar Performance verliert.
MMn sind genau solche Benches eben das Problem - irgendwer bringt irgendwo Zahlen. Und die Leute geben unreflektiert einfach nur irgendwas weiter, weil es gerade passend scheint.
Ist das zielführend? Und wenn man dann nachfragt, wird man pissig...
Und was Blender angeht - da solltest du nochmal den Zusammenhang lesen. Ich sagte, dass unterschiedliche Szenen unterschiedliche Bandbreitenanforderungen haben. Denk einen Schritt weiter - wer liefert hier die Infos ob die Szene Bandbreitenlastig ist/war?? Stattdessen wird die Szene pauschal als Maßstab genommen.
Laut Anzeige braucht die BMW27 Szene ~140MB bei den ersten paar Tiles. Ich habe schon Szenen mit Blender gerendet, da waren 100GB+ Verbrauch auf der Uhr. Ich denke es dürfte klar sein, dass der Bedarf an Bandbreite allein um die Datenmenge durch zu schubsen schon weit höher liegen sollte...
Nixdorf schrieb:
Das Problem ist nicht das NUMA-Design an sich, sondern wie heterogen es ist. Je gleichmäßiger die Leistung vorhanden ist, desto dämlicher darf der Scheduler sein. Mit den sehr unterschiedlichen Nodes von Threadripper bzw. der Asymmetrie im Design kommt Windows halt nicht klar, und DLM kann das nur teilweise korrigieren.
Das ist allerdings aus programmiertechnischer Sicht die falsche Sichtweise.
Das NUMA Design besagt normalerweise, dass dem Node eigener Speicher bereit stellt. Das ist bei den WXen nicht der Fall.
Was das am Ende bedeutet, lässt sich über Pauschalen nicht fest machen, weil es so ein Konstrukt (meines Wissens) vorher überhaupt nicht gab.
Sowie ich das sehe versucht der Threadscheduler im Linux primär die Last auf die DIEs 0 und 2 zu fokusieren. Solange, bis es nicht mehr geht, weil man entweder Speicher oder Threads über die Node Grenzen hinweg anfragt.
Windows kann das von Haus aus nicht - deswegen der Workarround von AMD dazu. Windows schubst dazu alle Nase lang die Threads von Core zu Core. Hält die Last primär aber auf einem NUMA Node, wenn man die Grenzen einhält.
Deswegen auch die Frage nach den Zahlen.
PS: dass Linux und Windows bei "einfachen" CPUs effektiv gleich performen ist doch aber überhaupt nicht wahr?
https://www.phoronix.com/scan.php?page=article&item=ryzen-2700x-winlin&num=1
Ich sehe da ne Menge Unterschied, teils 5-10%, wenns nicht so viel ist. Teils aber auch drastisch mehr. Selbst zwischen verschiedenen Linux Distributionen/Versionen liegen teilweise messbare Unterschiede.
