Ichaufloesung
Kabelverknoter(in)
Absolut, keine Frage. Mir ist klar, dass das bei weniger Kernen eine ganz andere Geschichte ist.
BF Bad Company 2 aus 2010 war so ein Titel, der die Spreu vom Weizen getrennt hat. Im MP wurde ein E8400 auch mit OC gern mal voll ausgelastet, mit entsprechend "tollen" Frametimes."Mehrkernwette": Das prominenteste Beispiel, das mir dazu einfällt, ist die Entscheidung zwischen Core 2 Quad Q6600 und Core 2 Duo E8400 vor vielen Jahren. Die Dinger waren eine Weile vergleichbar teuer, also stellte sich die Leistungsfrage (während die Leistungsaufnahme trotz des G0-Steppings klar für den Wolfdale sprach). Mittlerweile sucken beide, keine Frage. Zwischendrin gab es jedoch eine Zeit, in der man mit vier optimierten Kentsfield-Kernen irgendwo zwischen 3,2 und 3,6 GHz klar besser fuhr als mit einem Wolfdale @ 4+ GHz. Das passiert derzeit zwischen 4- und 6-Sechskernern und wird in einigen Jahren auch die Achtkerner einholen.
MfG
Raff
Ein Minimum kann und wird doch offenbar auch von machen Spielen gesetzt. Manche Spiele starten doch auf 2T CPUs z.B. nicht. Meine Überlegung war, dass durch das Begrenzen von Threads der Scheduler weniger gezwungen wird, einen Kern mit zwei (zeit)kritischen Threads zu belegen.Wie im von dir soeben zitierten Post beschrieben:
Es gibt kein "mindestens" und selbst wenn es das gäbe, bräuchte es zusätzlich noch ein "maximal". In der Praxis geht es aber um das Zusammenspiel zwischen Spiel, Scheduler und CPU. Die Entwickler kennen das Spiel, aber nicht die Gegenseite – erst Recht nicht mit Blick auf die Zukunft.
Dann wäre doch eine manuelle Auswahlmöglichkeit am besten, oder nicht? Warhammer Vermintide 1 und 2 bieten so eine Möglichkeit sogar.Wenn Anno keine zusätzlichen Threads für weitere Kerne spawnt (oder diese keine Konflikte verursachen) kann die manuelle Zuweisung genauso helfen, wie eine UEFI-Änderung, ja. Wenn der Verwaltungsoverhead für viele Threads mit jeweils nur geringer Rechenlast das Problem ist, muss der Zugang zu den Kernen dagegen schon beim Start verweigert werden – das kann der Taskmanager nicht bieten, da hilft nur das UEFI.
Ja, es ist schon lange nicht mehr sinnvoll reine Spiele CPUs mit (zu weitem) Blick in die Zukunft zu kaufen und sehr viel Geld dafür auszugeben. Es recht unter Betrachtung der Kernzahl. Der Q6600 hat sich nur mit OC gelohnt (im Vergleich zum E8400). Der Thuban nie so richtig. Bei Ryzen 1700(X) und 8700k hat sich das Blatt auch noch lange nicht zu Gunsten des AMD gewendet.Das ist eher ein Situation wie zwischen E8400 und QX9650: Beide mit hohem Takt, einer mit doppelt so vielen Kernen aber auch so schweine viel teurer, dass die E8400-Käufer ein paar Jahr später einen i5-2500K nebst Board vom gesparten Geld kaufen konnten. Und der ist gegenüber einem QX9650 klar vorzuziehen.
Es geht in dem Test um SMT, nicht um einen CPU Test allgemein.Bitte nicht zum 20000sten Mal diese Diskussion
Es lässt sich seit langem abfragen, wie viele physikalische und wie viele logische Kerne die CPU besitzt. Erwartet man dann eine "übliche" x86 CPU im Windows Bereich, hat diese max. ein Verhältnis von 2:1 (logisch zu virtueller Kern). Architekturen wie Buldozer kann man da im Zweifel genauso ignorieren wie die ersten Treadripper, und Seerver-CPU mit 4 virt. Kernen je physiklaischem genauso wie Big-Little CPUs.Spieleentwickler wissen zwar, womit ihre Software zurecht kommt, sie wissen aber nicht, was die CPU kann. Meinem Wissen nach meldet das Betriebssystem der Software keine Details über den Prozessoraufbau
Die Spiele scheinen eher für die minimalste Kombi aus CPU+GPU optimiert, auf der das Spiel noch laufen soll. Den Rest hat dann gefälligst jemand anderes für den auch so gebeutelten Spieleentwicker (wohl oft eher den Projektmanager oder Geldgeber) zu erledigen. Ist ja auch kein Wunder bei Spielen, die wohl oft beim Kunden reifen.In der Praxis spart man sich den ganzen Aufwand und passt die Spielkonfiguration entweder gar nicht an die vorliegende Hardware an, sondern entwickelt für einen allgemeinen Durchschnitt
Klar, also löst es wieder die HW und der Geldbeutel der Gamer. Die scheinen ja sowieso alles zu akzeptieren.Allgemein gilt aber ohnehin, dass eine Ausreizung von SMT auf schwachen CPUs eine gute Idee ist und dass die Performance auf guten CPUs die Entwickler reichlich wenig interessiert, weil die sowieso meist im GPU-Limit stecken.
Ja und? Das am Anfang genannte Tool pinnt die Threads wohl einfach an die passenden Kerne, wie es auch auf die alten Threadripper optimierte Anwendungen tun, damit sie ein amok laufender Scheduler nicht wieder irgnedwo hin verschiebt.Es würde nicht reichen allein die Menge an Threads zu begrenzen.
Das ist mir zwar selbst mit einem Threadpool noch nicht passiert, aber dafür kann man unter .NET immer noch Threads händisch erzeugen. Und wenn der dann mal läuft, wird er auch laufen gelassen. Ich komme aber auch nicht auf die Idee mir Mutithraed-Programmierung anzutun, wenn es nicht zwingend nötig ist. Dafür habe ich aber shcon oft genug die Threadanzahl beschränkt wenn aus den Tests mit den drei vorhandenen PCs/Laptops klar war, dass dies bei gewisser HW-Aussattung bedeutend sinnvoller/performanter ist.Besonders krass ist es, wenn dabei z.B. an .net denkt: Innerhalb der .net Runtime läuft die "Concurrency Runtime". Diese wägt u.a. anhand vom Systemzustand und von Codeanalysen ab, ob die Mehrkosten für das Erstellen und Verwalten eines Threads die "Aufgabe" aufwiegt. Sollte also das Erzeugen und Verwalten eines Threads teurer sein, wird die Aufgabe synchron ausgeführt und kein separater Thread gestartet. Auch dann nicht, wenn die Aufgabe selbst als Thread programmiert wurde.
BF Bad Company 2 aus 2010 war so ein Titel, der die Spreu vom Weizen getrennt hat. Im MP wurde ein E8400 auch mit OC gern mal voll ausgelastet, mit entsprechend "tollen" Frametimes.
Ein Minimum kann und wird doch offenbar auch von machen Spielen gesetzt. Manche Spiele starten doch auf 2T CPUs z.B. nicht. Meine Überlegung war, dass durch das Begrenzen von Threads der Scheduler weniger gezwungen wird, einen Kern mit zwei (zeit)kritischen Threads zu belegen.
Was den Meisten wohl noch nicht aufgefallen ist, SMT Off beeinflusst auch die Latenzen.
Beim 3900X wurde nur L3 schlechter. Beim 5900X wird auch der L3 schelchter, aber die Memory Latenz wird verbessert.
Zumindest in meinen Tests. Hier 2 Beispiele mit und ohne SMT. Rest ist gleich, optimierter 3200 CL14 RAM.
mit SMT
Anhang anzeigen 1350544
ohne SMT
Anhang anzeigen 1350545
Gibt es seit 1996, nennt sich "Task-Manager".
Du kannst bei jedem beliebigen Prozess die Zugehörigkeit manuell festlegen. Blöderweise halt bei jedem Spielstart aufs neue.
Anhang anzeigen 1349727
Der Scheduler macht das ständig. Und zwar bei allen Hunderten Prozessen die auf deinem PC so laufen gleichzeitig - anhand von sehr komplexen Kriterien auf Hardwareebene. Da ist keine Zeit und auch keine Kapazität um großartig zu implementieren dass es bei Spiel XY (also einem von zig Milionen Programmen) aber jetzt anders sein soll. Das ist die Aufgabe der Entwickler, nicht die von Microsoft. Denn der Entwickler des Spiels kann sehr einfach dem Scheduler sagen wie viele/welche Threads er adressieren soll. Er muss es nur auch machen - da CPUs mit 32 Threads aber eine Verbreitung von <<0,1% haben wird darauf keine Minute der Optimierung verschwendet.
Wäre doch mal ein interessantes Thema für ein Interview!BF MP war und ist in nahezu jeder Generation ein Multicore-Killer. Ich verstehe bis heute nicht wieso. Wenn man vergleicht, was um die Jahrtausendwende an Multiplayer-Shootern komplett auf einem Kern lief und wofür der BF-MP zwei beziehungsweise mittlerweile eher vier zusätzliche Kerne gegenüber BF-SP frisst, ist das Ergebnis einfach nur absurd.
Keine Frage, aber nur unter der Prämissen, wenn es mit SMT sauber läuft.Die von dir vorgeschlagene, manuelle Threadbegrenzung würde High-End-Prozessoren massiv einbremsen. Wenn eine Engine auf einem 5800X mit SMT etwas schlechter läuft als auf einem 5800X ohne SMT und deswegen hart auf eine Threadzahl limitiert wird, die trotz SMT sauber berechnet wird, dann wäre überhaupt erst einmal abzuwarten, ob der Scheduler bei weiterhin aktivem SMT damit überhaupt die Performance der SMT-losen Konfiguration erreicht. Fest steht aber von vorneherein, dass dieses Spiel auf einem 5950X kaum noch besser als auf einem 5800X performen wird.
Vielleicht erinnere ich mich falsch, aber genau das, was du beschreibst, war/ ist doch zu beobachten (ohne den genauen Grund zu wissen). Die größeren Ryzen hatten sich kaum von den kleineren absetzen können und hatten da Problem mit SMT. PCGH hat damals dazu geraten SMT bei Ryzen abzuschalten - auf jeden Fall bei den 8-Kernern.In dem Vergleich ist das erstmal "nur" schlechte Presse, aber setzen wir uns mal in eine Zeitmaschine und reisen in den Dezember 2016: Mainstream wird von Skylake dominiert, im HEDT bringt Broadwell E eine ähnliche pro-Kern-Leistung, aber deutlich mehr Kerne. Spiel X skaliert jenseits von sechs Kernen mit SMT schlecht und wird deswegen vom Entwickler auf diese Grenze festgeschnürt. Ein halbes Jahr später erscheint der Ryzen 7 1800X mit einer geringeren pro-Kern-Leistung, aber 16 logischen Prozessoren. Spiel X weigert, sich diese auszunutzen, obwohl bei der geringeren pro-Kernleistung die zusätzliche Rechenleistung trotz Overhead gut genutzt werden könnte. AMD-Prozessoren skalieren jenseits von Ryzen 5 gar nicht mehr und der kann gerade eben so mit Kaby Lake mithalten. Es resultiert der letzte Shitstrom, den dieser Spielepublisher jemals erleben wird, bevor er zumachen kann.
Vielleicht war meine Überlegung nicht zu Ende gedacht. Ziel sollte es sein, dass CPUs mit vielen Kernen (und SMT) zumindest keinen Nachteil haben sollten, während CPUs mit weniger Kernen effizienter genutzt werden könnten. Dabei geht es (mir) auch weniger um die Durchschnitts-FPS, sondern um konstante Ausgabe der Bilder.Und wozu das Ganze? Damit ein sehr kleiner Kreis von Luxus-CPU-Besitzern nicht einfach "sehr gute Fps", sondern noch einmal 5 Prozent mehr hat. Wie gesagt: Aus Entwicklersicht ein absolut bescheuerter Optimierungsansatz. Wichtig ist, dass ein Spiel auf einer Einsteiger- bis Mittelklasse-CPU optimal läuft. Die haben aktuell acht bis zwölf logische Kerne. Alles, was darüber hinaus geht ist optional und muss nicht optimal skalieren. Natürlich wäre es toll, wenn ein Titel einfach überall perfekt laufen würde, aber dafür muss man eben Architekturspezifisch an die Sache rangehen.
Ich habe den Fall Hyperthreading / SMT an / aus mal mit meinem PC in Origins nachgestellt.Origins auf jeden Fall, dort habe ich ohne SMT 10-15fps mehr. Cyberpunk eher weniger und RDR2 kann ich gerade nicht genau sagen, läuft aber sauber mit einem 3600 ohne SMT. Ich schau mir das die Tage genauer an, Teste den 3600 und meinen 5900X.
Ja, als reiner Gamer ist es schwer einen guten Mittelweg zu finden.Ja, es ist schon lange nicht mehr sinnvoll reine Spiele CPUs mit (zu weitem) Blick in die Zukunft zu kaufen und sehr viel Geld dafür auszugeben. Es recht unter Betrachtung der Kernzahl. Der Q6600 hat sich nur mit OC gelohnt (im Vergleich zum E8400). Der Thuban nie so richtig. Bei Ryzen 1700(X) und 8700k hat sich das Blatt auch noch lange nicht zu Gunsten des AMD gewendet.
Bei der Spieleentwicklung, geht es offensichtlich nicht darum, ein technisch einwandfreies Produkt abzuliefern.Warum sind die Spielentwickler nicht zu sowas in der Lage, das ist Aufgabe der Anwendung, und dort auch recht problemlos lösbar. Die Entwickler wissen, mit wie vielen Threads ihre (ja offensichtlich zu dumme) Software zurecht kommt.
Anfang? Seit mind. 2010 (SandyBridge) haben Spiele (und schlecht programmierte Anwendunge) Probleme damit. Das sind 10 Jahre in denen die Entwickler der Spiele hätten reagieren können.
Der aktuelle Ansatz der Industrie, auszuliefern sobald der Updater funktioniert, ist aber auch nicht so klasseBei der Spieleentwicklung, geht es offensichtlich nicht darum, ein technisch einwandfreies Produkt abzuliefern.
Nach 10 Jahren sollte das jedem Konsumenten klar sein?