AMD Ryzen 3000: Erste Ergebnisse mit AGESA 1.0.0.4 sind vielversprechend

Nö, weil du mir einfach so aus dem Nichts einen AMD vs Intel Modus vorwirfst..

Warum reitest du denn sonst so auf der Kernanzahl rum?

Naja, da deine getroffene These irgendwie nicht zutrifft, wohl eher nicht :fresse:
SMT/HT an/aus hat also absolut keine kausalen Zusammenhänge zwischen der Engine-Programmierung und den zugeteilten Threads. Na dann...

Oder liegt es einfach nur daran, dass sich die Workloads bei den Pro-Anwendungen allgemein besser parallelisieren lassen und da weniger Abhängigkeiten zwischen den unterschiedlichen Tasks herrschen?
100 Punkte! Die pro-Anwendungen wurden so gebaut, dass man sie gut in Workloads aufteilen kann. Ist bei Spielen auch möglich, erfordert halt nur, dass man die Engine entkernt und von Anfang an jeden Thread unabhängig aufbaut. Bei Runtime-Bedingungen baust du dann evtl. einen kleinen Thread-Cluster zusammen. Benötigt natürlich ein recht tiefes Eingreifen in die spiel-Logik. mit Baukastenprogrammierung funzt das ganze nicht mehr.

Gerade bei Spielen muss sehr viel untereinander synchronisiert werden, was einer freien Skalierung über alle verfügbaren Threads entgegen steht. Die freien Ressourcen können dann dafür anderen Sachen genutzt werden, wie z.B. den Kopierschutz.. Denuvo :hust:
Und warum bekommt Star Citizen das dann hin? Gibt ein paar interessante Videos dazu auf Youtube, wie das Ding sich im Offline-Modus verhält.




"Honestly I didn't notice much of a difference between 3.5 and 4.4ghz in this game. Maybe if I had more settings turned up but as is, the cpu never seems to get pushed."

Hä, was denn jetzt?
Ich dachte die FPS skalieren bei dem Spiel linear mit der Frequenz..
Das Spiel an sich scheint ziemlich broken zu sein..
Und was für ne GPU hat der Typ? Zockt der noch mit ner IGP?
Aber generell: Ja - das Spiel ist ziemlich kaputt.


Spiele/Software für Konsolen oder andere Systeme, wo bestimmte Kerne fürs OS abgestellt werden und der Entwickler nicht befürchten muss, dass da auf einmal etwas anderes den Kern belastet, wären solche Kandidaten wo es Sinn machen würde Threads an bestimmte Kerne zu binden bzw zuzuweisen. Ich denke mal, dass die Wahrscheinlichkeit höher ist sich die Performance zu versauen - wodurch hast du ja schon beschrieben - als da wirklich groß die Performance zu verbessern. Man sollte auch bedenken, dass die Betriebssysteme ja nicht einfach so willkürlich die Threads zwischen den Kernen hin- und herschieben, sondern versuchen die ganzen Threads möglichst gut über die Kerne zu verteilen, um so die anstehenden Workloads zu balancieren. Dazu werden die Scheduler der OS ja auch immer weiter optimiert.

Threads bestimmten Kernen zuweisen ist schon ziemlich Nische.
Es ist halt ein großer aufwand das so zu bauen, dass es nicht degradiert. Richtig.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Warum reitest du denn sonst so auf der Kernanzahl rum?

Tue ich nicht. Ich gehe nur auf deine Aussagen über die faulen Softwareentwickler ein.


Ist bei Spielen auch möglich, erfordert halt nur, dass man die Engine entkernt und von Anfang an jeden Thread unabhängig aufbaut.

Eine komplette Unabhängigkeit zwischen den einzelnen Threads bei einem Game wirst du nicht erreichen.
Aber woher willst du denn wissen, dass nicht schon darauf geachtet wird, dass es möglichst wenig Abhängigkeiten zwischen den Threads besteht?


Und warum bekommt Star Citizen das dann hin?

Weil dieses Genre dafür prädestiniert ist: Letztlich wird es aber immer auch auf die Spiele ankommen, ob sich die Optimierung für viele Kerne und Threads lohnt. Explizit wird im Rahmen der GDC 2018 das Sandbox-Genre rund um Spiele wie Total War oder anderen Games mit Massenschlachten hervorgehoben, da dort durch viele Einheiten auf großen Karten der größte Bonus sichtbar wird. Bis zu einem gewissen Teil lässt sich dies auch in anderen Genres umsetzen, allerdings mit weitaus geringerem Effekt. Dies kann dazu führen, dass Optimierungen gleich von Anfang an nicht in diesen Bereich sondern nur für die GPU angegangen werden – Games mit geringer CPU-Optimierung und -Skalierung wird es deshalb auch in Zukunft geben.


Und was für ne GPU hat der Typ? Zockt der noch mit ner IGP?
Aber generell: Ja - das Spiel ist ziemlich kaputt..

Hä?!
Ich habe mir das aus deinem Link genommen. Das ist der Dude mit der rx470..
 
Tue ich nicht. Ich gehe nur auf deine Aussagen über die faulen Softwareentwickler ein.
Die es ja gibt. Du schreibst ja selbst weiter unten, dass es andere Spiele gibt, wo (versucht wird) die Parallelisierung auszureizen.

Zum Thema Grenzen: Das habe ich in meinem vorherigem Post erwähnt: Wenn du feste Abhängigkeiten hast, dann erzeugst du einen Thread-Cluster, wo die Threads möglichste innerhalb einer Cache-Zone verbleiben. Das löst zwar nicht die Laufzeitbedingungen, führt aber dazu, dass der Thread auf dem gleichen CPU-Cluster bleibt, so dass am Ende der Berechnung der Cache nicht neu generiert werden muss um das finale Ergebnis zu berechnen. Vor allem bei CPUs mit vielen CPU-Clustern (auch hier: Unabhängig von Intel und AMD - beide machen das) bringt das nochmal einiges an Performance.

Auch ist es möglich Speicherbereiche, die von mehreren Threads benutzt werden in einen Cluster zu packen, so dass dort nicht dauernd hin und her geflusht wird. So verhindert man dann idle Prozesse und optimiert weiter die Auslastung, selbst wenn eine bestimmte Unterfunktion wartet.

Eine komplette Unabhängigkeit zwischen den einzelnen Threads bei einem Game wirst du nicht erreichen.
Nein, du kannst aber trotzdem soweit optimieren, dass du sehr nahe ans Optimum kommst. Auch Star Citizen hat abhängige Threads. Der Hauptunterschied von Star Citizen und anderen Spielen ist, dass die keinen Hauptthread mehr haben, sondern diesen in viele kleine Unterthreads aufgespalten haben, die dann wiederum weiter aufgespalten worden sind. Das wird so lange gemacht, bis der Vorteil der Aufspaltung den Nachteil des größeren "Verwaltungsaufwandes" nicht mehr rechtfertigt.

Das kann jedes Spiel machen - von 4 dödeligen Kernen bis hin zu 128.

Aber woher willst du denn wissen, dass nicht schon darauf geachtet wird, dass es möglichst wenig Abhängigkeiten zwischen den Threads besteht?
Wie ich? Die software-Devs sollen das gefälligst machen. Ich bin der Kunde, der das Spiel kauft. Und wenns ranzig rennt, weil man das Geld ins Marketing statt in die Programmierung gesteckt hat, gibts von mir halt keine Knete. Soweit kommts noch, dass ich als Kunde das Spiel mit nem Profiler auseinander nehme und dann nah stundenlanger Arbeit den Devs ihre zu optimierenden Unterfunktionen vorlege.

Jo, und in MWO kannst du theoretisch auch wunderbar parallelisieren. Haben se aber nicht gemacht, weil sie nach einem Jahr den letzten Engine-Typen rausgeschmissen haben. Und ab da gabs halt keine Optimierungen mehr. Kurz: Gier.

Ich verlange keine komplette Totaloptimierung auf Assembler-Niveau. Was ich will, ist eine technisch solide Umsetzung der aktuellen Technologie.

Hä?!
Ich habe mir das aus deinem Link genommen. Das ist der Dude mit der rx470..
Yo, mein Fehler - dachte, das wäre ein anderer Typ gewesen. Wenn der Mensch zwischen 3.3GHz und 4.4GHz keinen Unterschied sieht, ist da noch was anderes kaputt.
Als ich auf meinem alten 4930k von 3.9 auf 4.3 GHz gesprungen bin, hab ich da einen fast linearen Anstieg der FPS (und entsprechende GPU Auslastung) gesehen.

Ich kann ja mal in den nächsten Tagen das gleiche mit meinem 2700X machen und die Skalierung aufmalen.
 
Ist bei Spielen auch möglich, erfordert halt nur, dass man die Engine entkernt und von Anfang an jeden Thread unabhängig aufbaut. Bei Runtime-Bedingungen baust du dann evtl. einen kleinen Thread-Cluster zusammen. Benötigt natürlich ein recht tiefes Eingreifen in die spiel-Logik. mit Baukastenprogrammierung funzt das ganze nicht mehr.

Das ist einfach mal komplett falsch.
Bei einem Spiel möchte der Anwender nicht ein Ergebnis nach Zeit x - scheiß egal wie man dazu kommt. Sondern der Anwender möchte, dass JEDES verdammte Zwischenergebnis so schnell wie es nur irgendwie geht, auf dem Schirm angezeigt wird.

Nimmt man das mal ins Verhältnis zu einem Cinebench Run, da wäre nicht die Zeit des Runs für das gesamte Bild relevant, sondern die Zeit, wie lange im Schnitt JEDER einzelne Worker benötigt um seinen Teil zu errechnen. -> und nur daran würde man messen. Eigentlich müsste dir hier auffallen, wo das Problem in Games liegt. Die Geschwindigkeit per FPS ermittelt ist am Ende das Resultat von einer strikt sequenziellen Abarbeitung - so oft wie möglich, so schnell wie möglich. Das lässt sich vom Prinzip also nicht per MT erschlagen. Damit man das Problem entschärft, setzen Entwickler auf Multithreading in verschiedenen Teilen des Backends und ebenso bei der Bilderzeugung. Aber auch dort sind klare Grenzen gesetzt.

Simples Beispiel, was bringt es dir, die KI Berechnung 4x so schnell durchführen zu können (auf dem Papier), weil du von 2T auf 8T aufbohrst -> nichts. Absolut gar nichts. Die KI wird nicht schlauer, wenn der Prozessor schneller wird. Der Task ist einfach nur eher fertig und wartet dann bis zum nächsten Run. Im Backend des Spiels läuft die Berechnung normal nach genau definierten Regeln. Das Backend ist auch seit Jahrzenten entkoppelt vom Prozessor Speed, weil keiner in 2019 mehr braucht, dass das Spiel zu schnell läuft, wenn der Prozessor zu schnell ist (siehe Turbotaste zum Einbremsen damals)
Das alles in Summe und noch ganz paar mehr Sachen hindern ein Spiel an einer ansatzweise linearen Skalierung über die CPU Cores in Sachen FPS nach OBEN! (wichtig, es geht dabei um das schneller werden)
Nach unten ist lange kein Problem - um so niedriger der Takt, desto mehr MT Skalierung werden aktuelle Engines aufzeigen...

Und warum bekommt Star Citizen das dann hin? Gibt ein paar interessante Videos dazu auf Youtube, wie das Ding sich im Offline-Modus verhält.
Was bekommt SC denn hin?
Eine MT Skalierung durch Einbau von noch und nöcher weiteren Berechnungen ist kein garant für gute Programmierung. Das bekommt jeder Deppen-Entwickler auf die Beine gestellt. SC skaliert auch nicht über die Threads in Form von absoluten FPS. Mit doppelt so vielen Cores wird das Spiel nicht doppelt so viele FPS raus hauen. Nichtmal ansatzweise. Bei SC skaliert es (wie bei so ziemlich jedem anderen Spiel auch) nur nach unten. Nämlich unterhalb der Basisleistung wird eine Core-Halbierung auch die Frames drastisch senken.

Zudem ist SC noch ein ziemlich unpassendes Beispiel, es setzt auf autogenerierte Welten soweit ich das in Erinnerung habe, es ist kein Konsolenport und es ist zudem lange nicht Final. Niemanden interessiert wie das läuft, weil man sich immer hinter dem Alpha/Beta Argument versteckt, wenn es da problematisch wird mit der FPS Anzahl.

Nein, du kannst aber trotzdem soweit optimieren, dass du sehr nahe ans Optimum kommst. Auch Star Citizen hat abhängige Threads. Der Hauptunterschied von Star Citizen und anderen Spielen ist, dass die keinen Hauptthread mehr haben, sondern diesen in viele kleine Unterthreads aufgespalten haben, die dann wiederum weiter aufgespalten worden sind. Das wird so lange gemacht, bis der Vorteil der Aufspaltung den Nachteil des größeren "Verwaltungsaufwandes" nicht mehr rechtfertigt.

Man kann viel, wenn der Tag lang ist. Die Frage ist, was hat der Entwickler davon? Es geht dabei um Wirtschaftlichkeit - die Typen MÜSSEN Geld mit dem Produkt verlieren. Ein Spiel, was nur auf den obersten 10k Systemen überhaupt startet, verkauft sich nicht. Da nutzt Beste MT Skalierung und sonstwas nichts. Das Spiel muss idR auf einem 2C/4T Prozessor zumindest mal irgendwie laufen, die Konsolen mit 8C/8T, aber sehr niedrigem Takt setzen nochmals andere Anforderungen und bei den PClern kommen noch ganz anderen Konstellationen zum Tragen. Nur weil DU meinst, dass wäre ein Garant von schlechter Programmierung, wird das nicht zur Allgemeingültigkeit.

Mal davon ab, auch ein SC hat diesen sogenannten Hauptthread. Den hat jedes Spiel. Der limitiert bei einem SC auch, wie bei jedem anderen Spiel, wenn man genügend Bumms für all den Beikram aufwendet. Der Unterschied bei einem SC zum Rest der Titel ist nur, dass ein SC so viel Beikram da eingebaut bekommen hat, dass du überdurchschnittlich breite CPUs auffahren musst um diesen Punkt zu erreichen. Über diesem Punkt skaliert da exakt gar nix mehr, denn das Problem, was andere Spiele durch andere Marktausrichtung viel eher aufzeigen ist exakt identisch. Der Thread, der in Schleife läuft bei jedem Frame, was an die GPU geht, wird nicht in die Breite skalieren. Auch bei einem SC nicht. Dein Argumentationsfehler ist hier, dass du offenbar lediglich die deutlich höhere Breitenanforderung als Basisperformance eines SC als Garant für gute Spieleprogrammierung nimmst - was aber zwei völlig verschiedene paar Schuhe sind.

Es wäre wie gesagt ein leichtes nen 32C TR mit irgend einem Task in die Ecke zu fahren - dann hättest du ne perfekte Skalierung bis zu eben jenem Punkt. Aber immernoch das selbe Problem. Mit nem 64C erreichst du kein einziges Frame mehr Performance. Exakt das ist aber der Wunsch der Spieler, die wollen nicht 30 FPS oder 60 FPS - die wollen eben teils 120 FPS und mehr. Selbst in deinem SC ist das nicht möglich - und wenn du da nen 2x64C Epyc 2P Server auffährst, du wirst mit den FPS nicht nach oben skalieren, wenn die Basisperformance einmal ausreichend ist.


PS: mit deinem SMT Ansichten liegst du auch weit neben der Realität. Das SMT ein Problem in Games darstellt bzw. darstellen kann ist im Endeffekt dem Resultat der gleichen Thematik wie oben erwähnt, geschuldet. Sobald das OS auch nur einen kleinen Teil zusätzliche Last über den zweiten Threads eines Cores einkippt - knickt die Performance normalerweise weg. DAS möchte in Games aber keiner. Deswegen bringt SMT meist nichts und ist sogar häufig Nachteilig. Das OS weis nichts von der Wichtigkeit dieses einen Threads, der für die FPS zuständig ist. Würde man nicht FPS als Maßstab nutzen, sondern die Menge an durchgeführten Aufgaben in einer Zeit x, würde man feststellen, dass SMT in so ziemlich jedem Fall zu mehr Leistung führt. Spielt für den Gamer aber keine Rolle - denn dem ist das völlig hupe. Er möchte FPS und das so hoch wie geht...
 
Zuletzt bearbeitet:
Richtig, es war SATA und es waren die B2 (die B3 Stepping waren die gefixte Version) bei der die SATA 3Gb/s und nicht die USB Ports nach einiger ausfallen konnten. SATA und auch nur die SATA 3Gb/s Port, die SATA 6Gb/s Ports waren nicht betroffen, nicht USB, aber Hauptsache mal was behaupten, auch wenn man gar nicht mehr genau weiß was eigentlich Sache war. Googlet doch erst statt nur aus dem Nebel der Erinnerungen zu schöpfen, dann wäre auch dir nicht der Fehler unterlaufen, dass das B3 Stepping das mit dem Fehler wäre, denn das war das B2. Auf den Rest einzugehen ist sinnfrei, denn Verschwörungstheorien kann man mit der Wahrheit nicht vertreiben.
Immer langsam, hier der Link zu den USB Problemen:
Haswell: Intel hat im neuen Chipsatz Probleme mit USB 3.0 - Golem.de
Es waren die 8er Chipsätze mit USB3 Problemen. Und bei Skylake bin ich mir da auch nicht sicher, ob das alles koscher ist. Bei meinen Kollegen und mir gibt's überraschend oft USB Probleme, die auf älteren oder neueren Geräten einwandfrei laufen. Nur die T460er machen da massiv Ärger, ältere oder neuere T hingegen laufen mit den selben USB Geräten problemlos (z.B. Plantronics Headset, haben wir intern schon mal quer getauscht).
 
wieviel Multiprozess-Programme habt Ihr denn schon entwickelt? Wieviel Ahnung habt ihr von Frameworks (im Gaming Engine genannt) und deren entwicklung? Von Multi-Prozess-Kommunikation wie Semaphoren, Pipes,...? Delta-Processing? Keine? Dachte ich mir.

Man kann ein Programm auseinander dividieren, bis es nicht mehr geht. 4096 Threads parallel sind kein Problem. Das Problem steckt ganz woanders. Zum einen muß man sinnvoll segmentieren. Denn die meisten errechneten Ergebnisse braucht man für weitere Berechnungen. Um das mal ganz einfach darzustellen. Man berechnet eine Kreisfläche. A = r²*Pi. Man kann das ganze jetzt locker in zwei Threads splitten. T1 berechnet R² und T2 berechnet das Produkt. Nur macht das keinen Sinn. Denn T2 braucht das Ergebnis von T1. Diese Formel muss komplett sequentiell berechnet werden. Die Berechnung x = 7*7+7/7-7 hingegen kann geteilt werden. Aber auch nicht endlos. Und genau da liegt das Problem in Spielen. Viele Ergebnisse bauen auf anderen auf. Erschwert wird das ganze, indem man Engines verwendet. Damit handelt man sich eine Verallgemeinerung ein. Diese Engine ist nicht auf das jeweilige Spiel optimiert sondern man optimiert die eigene Entwicklung für die Engine. Als Beispiele außerhalb der Spieleentwicklung erkennt man das z.B. ganz deutlich, wenn man sich Java, DotNET oder auch SAP anschaut. Man codiert ganz locker und bequem. Aber von Registern, ALU's, Ports und Speicher-Adressierungsarten hat man keine Ahnung mehr. Von Shared Mem oder IPC (Interprocesscommunication) rede ich hier jetzt garnicht. Nicht nur in der Spieleentwicklung leidet dadurch die Software-Qualität. Das ist in der ganzen IT-Branche der Fall.

Entwickelt man z.B. in Excel mit Makros, werden diese streng sequentiell abgearbeitet. Das geht auch nicht anders. Allein schon deshalb ist es viel schneller, ein eigenes AddOn zu schreiben. Und selbst da ist es noch wichtig, welche Basis man verwendet. Ein kleines praktisches Beispiel. Ich habe ein AddOn geschrieben, das ca. 5 Mio Zellen einliest, was berechnet und dann die gleiche Anzahl wieder in Tabellen zurückschreibt.
In VBA ****** damals die Laufzeit ca. 5 Minuten
In ExcelDNA mit Zellzugriff (Framework) waren es noch 30 Sekunden
In ExcelDNA mit dem Auslesen als Ganzes dagegen 2 Sekunden.

Es ist egal, ob man das Kind nun Bibliothek, Engine oder Framework tauft. Es ist alles das gleiche. Eine Verallgemeinerung.
 
Das ist einfach mal komplett falsch.
Bei einem Spiel möchte der Anwender nicht ein Ergebnis nach Zeit x
Doch - und zwar innerhalb von wenigen Millisekunden. Deswegen nennt sich das auch Echtzeitberechnung. Die hat andere Bedingungen als generelle Prozessverarbeitung, braucht aber auch "Zeit" um einen Prozess abzuarbeiten.

Wenn du alles seriell abarbeitest, brauchst du so lange, dass man es nicht mehr als Echtzeit betrachten kann und deswegen sind die Entwickler ja auch dazu übergegangen zu parallelisieren. Warum skalieren denn Spiele wie AC jetzt schön auf 8 Kerne? Aus Langeweile, oder weil sie damit mehr auf die spielewelt bringen können?

Simples Beispiel, was bringt es dir, die KI Berechnung 4x so schnell durchführen zu können (auf dem Papier), weil du von 2T auf 8T aufbohrst -> nichts. Absolut gar nichts.
Doch, 4x die Anzahl der KI. so kann ich mehr NPCs darstellen oder die Ressourcen in zusätzliche Funktionen stecken. Oder sehen die Spielewelten von heute so aus wie vor 20 Jahren?

Was bekommt SC denn hin?
Guck dir den Offline-Mode bei Youtube selbst an und betrachte die Auslastung von Threadripper/3900X. Online ist es durch den Server limitiert, Offline nicht.

Außerdem lenkst du vom Thema ab - du kannst auch gut seriell programmieren oder ne schlechte Multi-Thread Umgebung bauen. Ändert aber nix daran, dass du eine gewisse komplexität irgendwann nicht mehr seriell abarbeiten kannst, um die Echtzeitbedingung zu erfüllen. Und ob Tech Demo oder nicht, man kann es spielen. Völlig egal was du es für Entengrütze betrachtest oder nicht.

Man kann viel, wenn der Tag lang ist. Die Frage ist, was hat der Entwickler davon? Es geht dabei um Wirtschaftlichkeit - die Typen MÜSSEN Geld mit dem Produkt verlieren. Ein Spiel, was nur auf den obersten 10k Systemen überhaupt startet, verkauft sich nicht. Da nutzt Beste MT Skalierung und sonstwas nichts. Das Spiel muss idR auf einem 2C/4T Prozessor zumindest mal irgendwie laufen, die Konsolen mit 8C/8T, aber sehr niedrigem Takt setzen nochmals andere Anforderungen und bei den PClern kommen noch ganz anderen Konstellationen zum Tragen. Nur weil DU meinst, dass wäre ein Garant von schlechter Programmierung, wird das nicht zur Allgemeingültigkeit.

Indie Devs haben auch nicht die Knete dafür und nehmen sich dann sowas wie die Unreal Engine. große Publisher wie Ubisoft haben eine Engine für mehrere Spiele. In beiden Fällen ist genug Knete da, nur der Geiz limitiert dann, was gemacht wird. Multicore-Optimierung oder Lootboxen basteln. Die Antwort darauf kannste dir selbst ausmalen.

Mal davon ab, auch ein SC hat diesen sogenannten Hauptthread. Den hat jedes Spiel.
Du hörst mir nicht zu, oder? Ich sagte, dass die Prozesse immer weiter aufgespalten werden, bis der flaschenhals die aufspaltung selbst ist. Da gibts keinen "main Flaschenhals" mehr.

PS: mit deinem SMT Ansichten liegst du auch weit neben der Realität. Das SMT ein Problem in Games darstellt bzw. darstellen kann ist im Endeffekt dem Resultat der gleichen Thematik wie oben erwähnt, geschuldet. Sobald das OS auch nur einen kleinen Teil zusätzliche Last über den zweiten Threads eines Cores einkippt - knickt die Performance normalerweise weg. DAS möchte in Games aber keiner. Deswegen bringt SMT meist nichts und ist sogar häufig Nachteilig. Das OS weis nichts von der Wichtigkeit dieses einen Threads, der für die FPS zuständig ist. Würde man nicht FPS als Maßstab nutzen, sondern die Menge an durchgeführten Aufgaben in einer Zeit x, würde man feststellen, dass SMT in so ziemlich jedem Fall zu mehr Leistung führt. Spielt für den Gamer aber keine Rolle - denn dem ist das völlig hupe. Er möchte FPS und das so hoch wie geht...
Komisch, das AC das hinbekommt...
 
Das Problem steckt ganz woanders. Zum einen muß man sinnvoll segmentieren. Denn die meisten errechneten Ergebnisse braucht man für weitere Berechnungen.
Richtig, aber in Spielen machst du keine wissenschaftlichen Berechnungen und kannst Abkürzungen nehmen. Du kannst dir die Ergebnisse von Berechnungen in Tabellen klatschen und sie einfach abrufen, wenn du damit eine Funktion ersetzen kannst. Es ist auch möglich einfach irgendwelche Konstanten mit geringer Genauigkeit in den Code zu hacken, anstatt jedes Mal das Ergebnis neu berechnen zu müssen. Dann wird aus Pi auf einmal 3.141 und r² speicherst du dir in dein Objekt. So hat der Granatwerfer dann 3 fixe Schadenbereiche, die Hitbox sagt, in welchem von denen du dich befindest und dann kann der Schaden einfach aus einer Tabelle ausgelesen werden, anstatt ihn zu berechnen.

Wenn man kreativ genug ist, kannst du ganz viele Abkürzungen nehmen und wenn es den Spielfluss nicht schadet, parallelisierst du halt Sachen, die rein physikalisch gar nicht parallelisierbar sind. Aber wenn die Ungenauigkeit vernachlässigbar ist - who cares?
 
Die es ja gibt. Du schreibst ja selbst weiter unten, dass es andere Spiele gibt, wo (versucht wird) die Parallelisierung auszureizen.

Klar gibt es irgendwo immer schwarze Schafe, aber du stellst es so dar - nicht nur hier - als wäre das die Mehrheit.


Zum Thema Grenzen: Das habe ich in meinem vorherigem Post erwähnt: Wenn du feste Abhängigkeiten hast, dann erzeugst du einen Thread-Cluster, wo die Threads möglichste innerhalb einer Cache-Zone verbleiben. Das löst zwar nicht die Laufzeitbedingungen, führt aber dazu, dass der Thread auf dem gleichen CPU-Cluster bleibt, so dass am Ende der Berechnung der Cache nicht neu generiert werden muss um das finale Ergebnis zu berechnen. Vor allem bei CPUs mit vielen CPU-Clustern (auch hier: Unabhängig von Intel und AMD - beide machen das) bringt das nochmal einiges an Performance.

Wo genau brauchst du das im Mainstream-Bereich und bringt dir so die deutlichen Performance Vorteile?
In diesem Bereich finden sich größtenteils CPUs mit geringen und homogenen Core-To-Core-Latenzen. Nur AMD sticht hier mit dem CCX etwas hervor, wo die Latenz bei der Cross-CCX-Kommunikation einen größeren Hit erleidet. Die Algorithmen in den Caches werden auch möglichst nicht Sachen flushen, die noch für weitere Berechnungen benötigt werden. Auch kommst du mit dem Clustern nicht darum herum die Zwischenergebnisse aus dem gemeinsamen Cache zur Weiterberechnung in die privaten Caches des Kerns zu laden.



Um deine Behauptungen zu belegen?


Warum skalieren denn Spiele wie AC jetzt schön auf 8 Kerne? Aus Langeweile, oder weil sie damit mehr auf die spielewelt bringen können?

Nicht nur jetzt, sondern gab es die Skalierung über viele Threads auch schon davor. Nur sind diese dann irgendwann in andere Flaschenhälse gelaufen, sodass diese gute Kernskalierung verdeckt wurde. Kannst du gut nachstellen, indem du deine CPU stark heruntertaktest und dann verschiedene Thread Konfigurationen durch testest.

Und auch ein AC krankt an genau den gleichen Problemen wie die anderen Spiele. Trotz der der guten Kernskalierung rennt dies in irgendein Flaschenhals, welcher bei CPUs mit einer schwächeren Singlekernleistung eher eintrifft. Während es bei Intel kaum einen Unterschied zwischen 6 und 8 Kernen gibt, hängt der 2700x schon stark hinterher. Die zusätzlichen 2 Kerne bringen dem da nichts, trotz der von dir gelobten Kernskalierung. Widerspricht damit dann auch so deiner Behauptung, dass Ryzen genau diese Spiele liegen..

Intel Core i9-9900K and Core i7-9700K Review > Gaming Benchmarks - TechSpot
 
Klar gibt es irgendwo immer schwarze Schafe, aber du stellst es so dar - nicht nur hier - als wäre das die Mehrheit.
Was im Falle von E/A ja auch zutrifft. Dann gibts wieder andere Studios, die es mit nem wesentlich kleinerem Team dann doch wieder gut hinbekommen. Ich bleib dabei, dass die Gier hier der Hauptgrund ist, warum Spiele nicht ordentlich optimiert werden. Es wird das gemacht, was gerade eben so noch ohne einen Shitstorm durchkommt und dann hat sich der Fisch.

Wo genau brauchst du das im Mainstream-Bereich und bringt dir so die deutlichen Performance Vorteile?
In diesem Bereich finden sich größtenteils CPUs mit geringen und homogenen Core-To-Core-Latenzen. Nur AMD sticht hier mit dem CCX etwas hervor, wo die Latenz bei der Cross-CCX-Kommunikation einen größeren Hit erleidet. Die Algorithmen in den Caches werden auch möglichst nicht Sachen flushen, die noch für weitere Berechnungen benötigt werden. Auch kommst du mit dem Clustern nicht darum herum die Zwischenergebnisse aus dem gemeinsamen Cache zur Weiterberechnung in die privaten Caches des Kerns zu laden.
Das liegt halt am Chiplet Design (welches Intel auch so langsam anstrebt - die werden da also auch genauso drunter leiden - AMD ist damit halt nur früher dran und darf damit auch die Kinderkrankheiten ausbaden)

Intelligente Prozessverteilungsalgos können diesen Effekt abfedern und soweit reduzieren, dass der Nachteil nur noch marginal ist, du dann aber in Sachen Produktmöglichkeiten sehr flexibel bleibst.
Zum Facebook-surfen brauchste diese Optimierungen nicht. Zum Zocken auf nem 60Hz Monitor auch nicht. Und theoretisch könnten wir auch alle mit dem Rad zur Arbeit fahren - dauert halt nur länger.

Um deine Behauptungen zu belegen?
Ich denke mir Mikroruckler also nur aus? Warum gibts nochmal 1% und 0,1% low Benches? Aus Langeweile? Oder weil das alles gemessen wird, um einen Forennutzer in einem deutschen Hardwareforum zufriedenzustellen?
Wenn du in einer Szene 50ms auf eine Funktion warten musst, ist da was verkackt worden. Das liegt dann auch nicht mehr am Prozessor, sondern an fehlenden Optimierungen.

Nicht nur jetzt, sondern gab es die Skalierung über viele Threads auch schon davor. Nur sind diese dann irgendwann in andere Flaschenhälse gelaufen, sodass diese gute Kernskalierung verdeckt wurde. Kannst du gut nachstellen, indem du deine CPU stark heruntertaktest und dann verschiedene Thread Konfigurationen durch testest.
Da wären wir aber beim Thema Gesamtsystem und nicht mehr, warum man jetzt unbedingt einen 9900k zum Zocken braucht.

Und auch ein AC krankt an genau den gleichen Problemen wie die anderen Spiele. Trotz der der guten Kernskalierung rennt dies in irgendein Flaschenhals, welcher bei CPUs mit einer schwächeren Singlekernleistung eher eintrifft. Während es bei Intel kaum einen Unterschied zwischen 6 und 8 Kernen gibt, hängt der 2700x schon stark hinterher. Die zusätzlichen 2 Kerne bringen dem da nichts, trotz der von dir gelobten Kernskalierung. Widerspricht damit dann auch so deiner Behauptung, dass Ryzen genau diese Spiele liegen..
Tritt jetzt der 2700X gegen den 9900k an oder hab ich was verpasst? Den gibts derzeit für 180€. Der 9900k kostet 510€.

Ansonsten bleibt halt nur dein System. Du hast ne Graka, nen monitor und daraus irgendwo ne maximal zu erwartende FPS. Schafft der Prozzi die --> perfekt. Schafft der die nicht --> bessere CPU kaufen. Ich muss schon ziemlich hart konstruieren, um da ne Niesche für den 9900k zu finden.
 
Ich bleib dabei, dass die Gier hier der Hauptgrund ist, warum Spiele nicht ordentlich optimiert werden. Es wird das gemacht, was gerade eben so noch ohne einen Shitstorm durchkommt und dann hat sich der Fisch.

Liegt das dann an den Softwareentwicklern oder anderen Abteilungen, die das Geld abdrehen?


Das liegt halt am Chiplet Design (welches Intel auch so langsam anstrebt - die werden da also auch genauso drunter leiden - AMD ist damit halt nur früher dran und darf damit auch die Kinderkrankheiten ausbaden)

Ich glaube aber nicht daran, dass wir das alsbald im Desktop-Bereich von Intel sehen werden. Eher im High-Core-Count Bereich oder da, wo platzsparende Designs benötigt werden.


Ich denke mir Mikroruckler also nur aus? Warum gibts nochmal 1% und 0,1% low Benches? Aus Langeweile? Oder weil das alles gemessen wird, um einen Forennutzer in einem deutschen Hardwareforum zufriedenzustellen?
Wenn du in einer Szene 50ms auf eine Funktion warten musst, ist da was verkackt worden. Das liegt dann auch nicht mehr am Prozessor, sondern an fehlenden Optimierungen.

Um den Grund aufzuzeigen, was da verkackt wurde.


Da wären wir aber beim Thema Gesamtsystem und nicht mehr, warum man jetzt unbedingt einen 9900k zum Zocken braucht.

:confused:
Wann wurde diese Behauptung hier aufgestellt?! Und du unterstellst mir einen Intel vs AMD Modus..

Zudem sind wir dann nicht beim Thema Gesamtsystem, wenn du die Auswirkung von unterschiedlichem Takt und Kern/Thread-Konfigurationen testen sollst. Wäre natürlich nicht sonderlich schlau dies so zu machen, dass da etwas anderes limitiert als die CPU. :fresse:


Tritt jetzt der 2700X gegen den 9900k an oder hab ich was verpasst? Den gibts derzeit für 180€. Der 9900k kostet 510€.

Ansonsten bleibt halt nur dein System. Du hast ne Graka, nen monitor und daraus irgendwo ne maximal zu erwartende FPS. Schafft der Prozzi die --> perfekt. Schafft der die nicht --> bessere CPU kaufen. Ich muss schon ziemlich hart konstruieren, um da ne Niesche für den 9900k zu finden.

Seit wann hat der 2700x 2 Kerne mehr als ein 9900k? Warum geht es jetzt um den Preis? Warum triggert es dich so, wenn ich einen Vergleich verlinke, wo Intel besser bei wegkommt?

Es ging mir nur darum deine Behauptung zu widerlegen, mehr nicht.
Verschone mich mit diesem unnötigen Kaufberatungsdiskussionen, die hier ständig in jedem Bereich ausbrechen. Lass die Leute doch kaufen, was diese wollen. Ich glaube, dass es kaum jemanden juckt, was andere über deren Kaufentscheidung denken. Zumal viele wohl besser wissen werden, welche CPU für deren individuellen Workload am besten passt. Zumindest besser als irgendwelche Forenexperten..
 
Liegt das dann an den Softwareentwicklern oder anderen Abteilungen, die das Geld abdrehen?
Was macht das für einen Unterschied? Die Firma hats verkackt, Ende.

Ich glaube aber nicht daran, dass wir das alsbald im Desktop-Bereich von Intel sehen werden. Eher im High-Core-Count Bereich oder da, wo platzsparende Designs benötigt werden.
Und deswegen sollten wir nicht mehr optimieren oder nur dann, wenns um Intel geht oder was willst du damit sagen? Das ist auch der Grund, warum ich dir vorwerfe, Intel-Fanboy zu sein.

Um den Grund aufzuzeigen, was da verkackt wurde.
Was da verkackt worden ist siehst du nicht an den 0.1% lows, nur den Effekt. Ein Benchmark ist kein Profiler.

:confused:
Wann wurde diese Behauptung hier aufgestellt?! Und du unterstellst mir einen Intel vs AMD Modus..
Ja, weil deine Ausführungen stark Intel-lastig sind. Siehe oben.

Seit wann hat der 2700x 2 Kerne mehr als ein 9900k? Warum geht es jetzt um den Preis? Warum triggert es dich so, wenn ich einen Vergleich verlinke, wo Intel besser bei wegkommt?
Wovon redest du überhaupt? Wer hat das behauptet? Du selbst hast doch den 2700X angebracht und jetzt bist du davon verwirrt? Du musst doch selbst wissen, warum du den als Argument angebracht hast.
Ich kenne jedenfalls niermanden, der behauptet, dass der 2700X genauso schnell ist wie ein 9900k.

Es gibt jedoch massig Situationen, wo der Geschwindigkeitsunterschied irrelevant ist, wie in den von mir beschriebenen Situationen, die zu mindest bei Steam auf >90% der Nutzer zutreffen.

Es ging mir nur darum deine Behauptung zu widerlegen, mehr nicht.
Ja, das merke ich. Um die Wahrheit gehts hier schon lange nicht mehr, nur noch ums Ego.

Verschone mich mit diesem unnötigen Kaufberatungsdiskussionen, die hier ständig in jedem Bereich ausbrechen.
Kein Problem - wenn du dann damit aufhörst zu behaupten, man bräuchte den die bessere single-Kern Performance, wenn du den Flaschenhals nicht kennst.
Lass die Leute doch kaufen, was diese wollen.
Endlich mal was, wo ich zustimmen kann. Macht mit eurem Geld was ihr wollt. :)
 
Was macht das für einen Unterschied? Die Firma hats verkackt, Ende.

Du beschwerst dich über die faulen Softwareentwickler? :hmm:


Und deswegen sollten wir nicht mehr optimieren oder nur dann, wenns um Intel geht oder was willst du damit sagen? Das ist auch der Grund, warum ich dir vorwerfe, Intel-Fanboy zu sein.

Nein, will ich nicht. Bleib doch ganz nüchtern beim Geschriebenen..


Wovon redest du überhaupt? Wer hat das behauptet? Du selbst hast doch den 2700X angebracht und jetzt bist du davon verwirrt? Du musst doch selbst wissen, warum du den als Argument angebracht hast.
Ich kenne jedenfalls niermanden, der behauptet, dass der 2700X genauso schnell ist wie ein 9900k.

Ich verlinke dir einen Test, wo mehrere CPUs vertreten sind. Dabei hatte ich AC gewählt, weil du dies als gutes Beispiel angegeben hattest. Dabei vergleiche ich sogar die Intel CPUs untereinander - welche alles fast gleich auf sind - und vergleiche auch den 6 Kerner (8700k) von Intel mit dem 8 Kerner (2700x) von AMD. Einfach nur um dir zu zeigen, dass auch in Spielen mit guter Kernskalierung die pro Kern Performance auch noch eine große Relevanz hat, und um deine Behauptung zu widerlegen, dass Spiele mit einer guten Kernskalierung (und so gut programmiert wurden?) auch dem Ryzen gut liegen, weil deren Threadlogik nicht einfach rein geklatscht wurden.

Sry, dass ich da etwas verwirrt bin und nicht so ganz nachvollziehen kann, warum dies auf einmal ein 9900k vs 2700x sein soll und auch nicht so ganz verstehe, was die Nennung von Preisen da plötzlich zu suchen hat. Zumal dieser Vergleich ziemlich unfair ist, da du den Preis einer CPU im Abverkauf mit dem von einer CPU vergleichst, welche sich nicht im Abverkauf befindet und diese nicht in großen Stückzahlen vorhanden ist..
 
Du beschwerst dich über die faulen Softwareentwickler? :hmm:
Ja, weil so ein Spielestudio Software entwickelt. Das sind Softwareentwickler. Die armen Programmierer im Keller haben da wohl auch wenig Lust zu, Lootbox-Frameworks zu basteln. Aber wenn el Cheffe das will, dann müssen die das tun (oder sich nen neuen Arbeitgeber suchen) Auch die Putzfrau eines Spielestudios ist irgendwo ein Glied in der Kette. Das macht sie nicht zum Programmierer, aber trotzdem ist sie in einer Software-Schmiede angestellt.

Vielleicht wird es so klarer: Der Programmierer darf nicht entscheiden, was er programmiert. Das sind globale Entscheidungen der Firma. Da ich hier aber in Spekulation abdrifte, wer jetzt wirklich für diesen Schmarn verantwortlich ist (Management, Marketing, whatever) wäre es vermessen zu sagen "Der/Die da wars!". Ergo bleib ich bei "Die Firma hats verkackt".

Nein, will ich nicht. Bleib doch ganz nüchtern beim Geschriebenen..
Gut - dann trinken wir jetzt beide mal einen Tee und begraben den Kindergarten. Okay?

Dann mal analytisch:
(Achtung, ich will dich hier nicht auseinandernehmen, sondern die Punkte strukturiert abarbeiten)

Ich verlinke dir einen Test, wo mehrere CPUs vertreten sind. Dabei hatte ich AC gewählt, weil du dies als gutes Beispiel angegeben hattest.
Gut skalierende Spiele sind auch zu favorisieren, da diese einen kleinen Blick in die Zukunft der Spielebranche zeigen. Weitere Spiele die gut skalieren gibt es kaum, da diese eher unter "Tech Demo" fallen. Was ich hier auch noch anmerken möchte, ist dass die Skalierung auch stark von dem Betriebsystem abhängt. Unter Linux gibt es beispielsweise Ports, die alleine durch die Übersetzung schon 20-40% Performance verlieren. Der gute Scheduler + Treiber sind aber fähig, diese Differenzen wieder auf ~10% zu reduzieren. Wir müssen hier also nicht nur das Spiel alleine betrachten, sondern wie es zusammen mit dem Betriebsystem als Einheit skaliert. Dort sind dann natürlich auch die Hersteller (AMD und Intel) gefragt, entsprechenden Support einfließen zu lassen.

Dabei vergleiche ich sogar die Intel CPUs untereinander - welche alles fast gleich auf sind - und vergleiche auch den 6 Kerner (8700k) von Intel mit dem 8 Kerner (2700x) von AMD. Einfach nur um dir zu zeigen, dass auch in Spielen mit guter Kernskalierung die pro Kern Performance auch noch eine große Relevanz hat,
Ich finde den von dir geposteten Link schön, weil man dort mehrere Sachen gleichzeitig erkennen kann:

1) Die Single Thread Leistung spielt auch bei gut skalierenden Spielen eine Rolle, da es offensichtlich auch bei gut skalierenden Spielen Unterfunktionen gibt, die "warten" müssen. Besonders auffällig bei der 1080p Betrachtung ist aber die Differenz zwischen Durchschnitt und 1% low. Während die Durchschnittswerte bei Intel davonfliegen, sind die 1% low Werte nahezu gleich auf. Das deutet darauf hin, dass das Spiel mal durch einen Profiler gefolgen sein muss, um die gröbsten Übeltäter wegzuoptimieren (was dann im Multicore-Fall geht) - denn sonst würden die 1% low mit den average-Frames mehr oder weniger mitskalieren - wo der 2700X dann sowas wie 40 FPS haben müsste. Er liegt dort aber im gleichen 60/70'er Bereich im Brackwasser der Intel CPUs.

Die exakte Ursache, warum die Intels dem 2700X davonrennen, wenn keine Übeltäter zu berechnen sind, lässt sich in der Latenz/IPC vermuten - denn dort sind die Intel CPUs ja auch besser als der 2700X. (stock vs stock)
Entprechend wundert es auch nicht, wenn der 2700X mit getuntem Speicher große Sprünge nach vorne macht, wo der Hauptflaschenhals des 2700X liegt. Der restlichen Unterschiede sind dann fast nur noch auf die reine Taktfrequenz zurückzuführen, da der 2700X nicht die 4.7GHz schafft.

2) Das Review zeigt uns mit Absicht FPS Zahlen und nicht einfach Prozente. Denn die FPS sind wichtig um entscheiden zu können, ob die CPU "okay" ist. Knackt die CPU die 60 FPS, ist sie ausreichend schnell. Der nächste Schritt wären dann 144Hz. Das bekommt aber die Graka wohl nicht mehr gebacken.

3) Bei 1440p prasseln die Ergebnisse in einen engen Schlauch, wo man praktisch keine relevanten Unterschiede mehr erkennen kann. Der 2700X sinkt eben nicht relativ zu Intel mit nach unten, sondern hält sich dort direkt in Konurrenz nahezu auf Augenhöhe. Das kommt zum einen durch das gestiegene GPU Limit, zeigt aber auch, dass die Multi-Thread Umsetzung gut ist - da der Flaschenhals mit ein wenig mehr Luft nach oben direkt mal aufgelöst wird.


und um deine Behauptung zu widerlegen, dass Spiele mit einer guten Kernskalierung (und so gut programmiert wurden?) auch dem Ryzen gut liegen, weil deren Threadlogik nicht einfach rein geklatscht wurden.
Was ja auch passiert. Wäre die Threadlogik schlecht, würde der 2700X weit abgelschagen sein und auch bei 1440p nicht wirklich viel näher rankommen. Tut er aber.

Sry, dass ich da etwas verwirrt bin und nicht so ganz nachvollziehen kann, warum dies auf einmal ein 9900k vs 2700x sein soll und auch nicht so ganz verstehe, was die Nennung von Preisen da plötzlich zu suchen hat.
Ich hab keine Ahnung, warum der 2700X überhaupt zur Diskussion steht, denn der 3700X ist ja draußen. Und den Preisunterschied hab ich halt genannt, weil das der Elefant im Raum ist.

Zumal dieser Vergleich ziemlich unfair ist, da du den Preis einer CPU im Abverkauf mit dem von einer CPU vergleichst, welche sich nicht im Abverkauf befindet und diese nicht in großen Stückzahlen vorhanden ist..
Unfair oder nicht, das sind die aktuellen Preise. ;)
Bei Intel CPUs sehe ich keine Abverkaufspreise. Evtl. wäre es mal klug für Intel die letzte Generation mit den gleichen Rabatten zu versehen, wie es AMD macht. Nur würden die dann so spott billig werden, dass die damit ihre neuen Produkte damit kannibalisieren. Nvidia hat das Problem ja mit der GTX 1080 vs RTX 2070/2080 gehabt. Aber wir sind hier schon längst OT.

Edit:
Ich sehe in dem von dir verlinken Artikel ein Spielchen, was sogar noch besser skaliert: Rainbow Six. Wunderbare Skalierung der GPU über die auflösung und praktisch keine Unterschiede von Intel zu AMD. Dort spielt sie single-Core Performance nahezu gar keine Rolle mehr und die Last wird fast symmetrisch über alle Kerne verteilt. Dafür scheinen die dort aber irgendwo eine Unterfunktion drin zu haben, die durch den Profiler geflutscht ist, denn die 1% low skalieren linear mit den Durchschnittswerten nach unten.
 
Zuletzt bearbeitet:
Also mein 3900x erreicht seine beworbenen 4,6GHz nicht mit einem ASUS Strix X570-E UEFI 1404 aka agesa 1004b, leider weiß ich nicht ob es am MB oder CPU liegt :(
 
Wieso sollte es am Mainboard liegen? Die Spawas sind sicher nicht schuld, die CPUs brauchen bei Last auf nur einem Kern ja nicht viel Leistung. Also wenn, dann liegt es vielleicht am UEFI und dem darin enthaltenden AGESA, aber wahrscheinlicher an der CPU. Nachdem die TR3000 ja nur bis 4,5GHz Boosttakt haben, sollte klar sein, dass dies der realistische maximale Boosttakt ist, bei dem es auch eine gute Ausbeute gibt und Dies bei denen wenigstens ein Kern mehr schafft, einfach selten sind. Wie selten solche Perlen sind, werden wir bald anhand der Verfügbarkeit des 3950X sehen, bei dem ja sogar ein Kern bis 4,7GHz gehen soll.
 
Also mein 3900x erreicht seine beworbenen 4,6GHz nicht mit einem ASUS Strix X570-E UEFI 1404 aka agesa 1004b, leider weiß ich nicht ob es am MB oder CPU liegt :(

Was erreicht deiner denn an Singlecoreboost? Mach mal einen Singlethread Cinebench R20 run. Meiner boostet während eines R20 Singlethread runs auch nur vereinzelt auf die 4,6GHz und die meiste Zeit liegen so 4,55-4,575 an.
 
Was erreicht deiner denn an Singlecoreboost? Mach mal einen Singlethread Cinebench R20 run. Meiner boostet während eines R20 Singlethread runs auch nur vereinzelt auf die 4,6GHz und die meiste Zeit liegen so 4,55-4,575 an.

100mal schon gemacht mitlehr weile und alle möglichen settings und das max sind 4,4 meist allerdings 4,35 bis 4,38
 
Hast du CPPC, die Prefered Cores, C- States usw im Bios Enabled? Die CPU kann nur hoch boosten wenn Windows weiß welche Kerne gut sind und wenn die meisten Kerne schlafen.


Edit: Die Settings sollten im Bios eingestellt sein. Wenn du Cool n Quiet und PPC Adjustment nicht hast ist es nicht schlimm, die sind nicht so wichtig.

Global C-state Control = Enabled
Power Supply Idle Control = Low Current Idle
CPPC = Enabled
CPPC Preferred Cores = Enabled
AMD Cool'n'Quiet = Enabled
PPC Adjustment = PState 0
 
Zuletzt bearbeitet:
Hast du CPPC, die Prefered Cores, C- States usw im Bios Enabled? Die CPU kann nur hoch boosten wenn Windows weiß welche Kerne gut sind und wenn die meisten Kerne schlafen.


Edit: Die Settings sollten im Bios eingestellt sein. Wenn du Cool n Quiet und PPC Adjustment nicht hast ist es nicht schlimm, die sind nicht so wichtig.

Global C-state Control = Enabled
Power Supply Idle Control = Low Current Idle
CPPC = Enabled
CPPC Preferred Cores = Enabled
AMD Cool'n'Quiet = Enabled
PPC Adjustment = PState 0

Ja weis ich :/

Global C-state Control = Enabled
Power Supply Idle Control = Low Current Idle
CPPC = Enabled
CPPC Preferred Cores = NICHT VORHANDEN DANKE ASUS
AMD Cool'n'Quiet = NICHT VORHANDEN DANKE ASUS
PPC Adjustment = NICHT VORHANDEN DANKE ASUS
 
Hast du es schon mal mit dem 1usmus Energiesparplan versucht? Der könnte dir helfen.
 
Und am wichtigsten: Wie gut ist die CPU gekühlt? Nicht dass einfach wegen der Kerntemperatur vorsorglich gedrosselt wird.
 
News - AMD Ryzen 3000: Neuer Energiesparplan soll 250 MHz mehr Takt bieten| Seite 49 | ComputerBase Forum


Die entscheidende Frage die sich ein jeder hier, besonders aber der gute Roman und Yuri, einmal mal ernsthaft stellen sollten: Weshalb werden all diese Taktmessungen und Spielereien Observationen nie von echten Benchmarks flankiert? Weshalb spielen alle nur noch ihr nichts sagendes Lieblingsspiel: Cinebench R20?

Hier ein kleines Beispiel:

Am 7.7. habe ich die Erstinstallation meine 3800X auf meine X470 Board vorgenommen.
AMD AGESA Combo-AM4 1.0.0.2
ein recht alter AMD Chipsatztreiber
Windows 10 1809
Cinebench R20:
Single Core: 510
Multi Core: 5.017
Anschließend nur die RAM-Timings optimiert, nicht den Takt und PBO aktiviert.

Cinebench R20:
Single Core: 519
Multi Core: 5.074
Schon zu dieser Zeit hat mir sowohl HWiNFO als auch der Ryzen Master bestätigt, der 3800X erreicht in gewissen Szenarien die beworbenen 4,5 GHz, teils sogar 4,525 GHz auf dem besten Kern und wiederum 4,5 GHz auf zwei weiteren. Alles super!

1574407188639.png 1574407213674.png

Nun 4 1/2 Monate später:
AGESA 1.0.0.4b
neue SMU-Firmware 46.54.0
neuster AMD Chipsatztreiber
Windows 10 1909 inkl. KB4524570
zahlreiche neue Energiesparpläne
Ergebnis:

Die Resultate sind 1:1 gleich, auch wenn ich jetzt sowohl im Ryzen Master als auch in HWiNFO gar 4,575 GHz zu sehen bekommen und sowohl der maximale als auch der durchschnittliche Takt um rund 50 MHz höher liegen. Die Resultate in echten Benchmarks (nein nicht Cinebench) sind 1:1 die selben wie beim Release von Ryzen 3000.

Beispiel:

Blender Benchmark:
am 7.7.: 15:45 Minuten
am 22.11.: 15:43 Minuten
Cortana Benchmark:
am 7.7.: 101 Sekunden
am 22.11.: 100 Sekunden
Min. FPS in Superposition (1.280 x 720):
am 7.7.: 126 fps
am 22.11.: 126 fps
Hinsichtlich der Performance spielt es überhaupt keine Rolle welchen Energiesparplan man nutzt, oder ob man AGESA 1.0.0.2 oder 1.0.0.4b auf seinem Board geflasht hat. Die Detail- und Kompatibilitätsverbesserungen nimmt man gerne mit, aber zu denken man bekäme ein schnelleres System ist dann eher Einbildung.

Der Cinebench zumindest ist weniger ein valider Benchmark, sondern ein Schnellcheck.

Investiert die Zeit lieber in gezieltes RAM OC, genau justiertes Undervolting & Co., damit kann man gerade im CPU-Limit noch einmal 5-10 Prozent herausholen und seine CPU sogar kühler und damit leiser betreiben.

Sein System mit AGESAs und Energiesparplänen zu tunen ist absolute Zeitverschwendung!
 
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