Luxxkompensator 2020: Wir übertakten den Speicher

[HWL News Bot]

Weiter geht es beim Luxxkompensator: Nachdem wir den Ryzen Threadripper 3990X mit all seinen 64 Kernen auf 4 GHz übertakten und dabei sogar mit reduzierter Spannung fahren konnten und wir uns auch der verbauten Zotac GeForce RTX 2080 Ti AMP Extreme (Test) gewidmet haben, kommt heute der Arbeitsspeicher ins Spiel.
... weiterlesen

 

[Bitmaschine]

Schickes Teil 😍
Das mit dem RAM ist ja echt witzig. Ja, wenn man zu viel Schaum auf dem Mund vor lauter Aufregung hat .... 😂

... wegen Tests: Ich denke die üblichen Tests, die ihr so macht. Ich würde den Flight Simulator 2020 von MS mit aufnehmen. Anscheinend profitiert das Spiel von vielen Kernen und viel Speicher.

 

[Yargen]

Schon ein außergewöhnliches Stück Technik, ich bin immer wieder begeistert

 

[Hyrasch]

Bei Caseking wollte man ein bisschen sparen
An den Ram-OC Guide gehalten?
Wie viel Zeit hast du mit dem Ram-OC verbracht? Dauerte bei mir Anfangs Stunden

 

[Romsky]

Schickes Teil 😍
Das mit dem RAM ist ja echt witzig. Ja, wenn man zu viel Schaum auf dem Mund vor lauter Aufregung hat .... 😂

... wegen Tests: Ich denke die üblichen Tests, die ihr so macht. Ich würde den Flight Simulator 2020 von MS mit aufnehmen. Anscheinend profitiert das Spiel von vielen Kernen und viel Speicher.

dem ist leider nicht so es werden maximal sechs Kerne plus HT genutzt

 

[Micke]

Warum baue ich im Code extra eine Zeile ein, nur 6 Kerne zu nehmen ?? Dieses merkwürdige Einmischen ins Ressourcen Management scheint ja schon länger an irgendeiner Game Dev Schule gelehrt zu werden, die leider nicht geschlossen wird.

 

[Mayk-Freak]

Wieviel Zeit braucht der Rechner zum Booten sieht ja übelst langsam aus und wieso braucht der Rechner so lange um das CPU-Z Fenster öffnen?

 

[Romsky]

Warum baue ich im Code extra eine Zeile ein, nur 6 Kerne zu nehmen ?? Dieses merkwürdige Einmischen ins Ressourcen Management scheint ja schon länger an irgendeiner Game Dev Schule gelehrt zu werden, die leider nicht geschlossen wird.

Ich glaube eher du weisst nicht wie genau das läuft. Im Code muss du eher sehr viele Zeilen einbauen um verschiedene Aufgaben aufzuteilen so das mehrere Threads und somit auch Kerne genutzt werden können. Umso mehr Threads genutzt werden sollen umso schwerer wird es. Manche Aufgaben kann man nicht einmal in mehrere Threads aufteilen. Es ist also nicht so das MS da extra Zeilen einbaut damit nur 6 Kerne + HT genutzt werden, sondern man hat Zeilen integriert damit überhaupt mehr als 1 Kern genutzt werden kann. Denn Standard wäre 1 Thread.

 

[christian8672]

Finde Dennis Bode ist einfach nur Mega Sympathisch und erklärt alles hervorragend.
Danke an Ihn und die Comunity die da hinter steckt!

 

[DragonTear]

dem ist leider nicht so es werden maximal sechs Kerne plus HT genutzt

Legt die Software wirklich bestimmte Threads für HT aus? Das wäre dann doch wieder ungewöhnlich.
Normalerweise gibt es eher Vorteile wenn man alle Threads auf separaten Kernen laufen lässt und dann würde der Simulator durchaus auf bis zu 12 Kernen skalieren.
Gehe aber schon davon aus dass die GPU bei realistischen Auflösungen wie immer vorher deckelt.

 

[Romsky]

Damit etwas auf mehrere Threads verteilt werden kann muss ein passender Scheduler her oder Module und die Ergebnisse der Berechnungen müssen auch wieder zusammengeführt werden da viele voneinander abhängig sind. Software auf multithreading zu optimieren ist je nach Anwendungsgebiet sehr komplex.

 

[Muffin-Man]

Warum habt ihr nicht 4x 16GB genommen? von acht Rigeln profitiert man doch nicht bei quad channel.

 

[Bitmaschine]

Legt die Software wirklich bestimmte Threads für HT aus? Das wäre dann doch wieder ungewöhnlich.
Normalerweise gibt es eher Vorteile wenn man alle Threads auf separaten Kernen laufen lässt und dann würde der Simulator durchaus auf bis zu 12 Kernen skalieren.
Gehe aber schon davon aus dass die GPU bei realistischen Auflösungen wie immer vorher deckelt.

Irgendwie habe ich noch im Kopf, dass Threads, je nach Prioritätsangabe vom System/Programm, verteilt werden. PC-Games HW hat beim Flight Simulator festgestellt, dass je mehr Kerne und Takt da sind, umso mehr Frames sind herauszuholen. Das Spiel muss wohl die CPU sehr beanspruchen. Diese Aussage steht, kann man auch im Video anschauen:
Erste Tests und Flight Simulator 2020 im Benchmark-Test

 

[Romsky]

Irgendwie habe ich noch im Kopf, dass Threads, je nach Prioritätsangabe vom System/Programm, verteilt werden. PC-Games HW hat beim Flight Simulator festgestellt, dass je mehr Kerne und Takt da sind, umso mehr Frames sind herauszuholen. Das Spiel muss wohl die CPU sehr beanspruchen. Diese Aussage steht, kann man auch im Video anschauen:
Erste Tests und Flight Simulator 2020 im Benchmark-Test

Das ist aber Unsinn Nachweislich werden nicht mehr als sechs Kerne genutzt. Und wie gesagt das System kann gar nicht dynamisch Threads verteilen da es gar nicht die Abhängigkeiten kennt und somit nicht aufteilen kann. Wie bereits erwähnt kann man nicht jede Aufgabe aufteilen und auf mehrere Kerne verteilen. Aus dem Grund sind auch heutzutage viele Programme noch nicht auf Nutzung mehrerer Kerne optimiert. Wäre toll wenn es so funktionieren würde wie du es meinst aber das klappt aus mehreren Gründen so nicht.

 

[Bitmaschine]

Warum das auf 6 Kerne limitiert ist, erschließt sich für mich noch nicht so ganz. Klar liegt es am Programm, wie viel Kerne er sich für sich beansprucht, bzw. der Prozessor limitiert die Threads, weil ja Hintergrundprogramme ständig abgearbeitet werden müssen. Wenn es so wäre, dann kann ich es mir nur so erklären, dass 4-6 Kerne + Threads im Schnitt lege artis war/ist und Programmierer davon ausgehen müssen, das es so ist (Minimalkonfiguration). Ich muss halt nur gerade an Cinebench denken. Der schnappt sich die Kerne und Threads, mit all den Hintergrundprogrammen die noch laufen. Und das schon gut 2 Jahrzehnte. Also ist es möglich, man muss es nur zu nutzen wissen. Das Programm weiß ja auch nicht am Anfang, wieviel Kerne ihn erwarten. Entsprechend skaliert das Programm, bzw. der das programmiert hat. Wäre aber cool, wenn der "vor dem Bildschirm sitzende" dem Programm sagen kann, "ich habe einen 12 Kerner, du kannst 10 Kerne für dich beanspruchen". Wegen Prioritäten die für Programme definiert werden können, dieser Link: Prozesse dauerhaft Priorisieren
Vielleicht kommt noch ein Patch seitens Microsoft zu der Skalierung und die Umstellung auf DirectX 12, wenn ein Win. 10 System erkennbar ist. Man verspricht sich davon viel.

 

[DragonTear]

Damit etwas auf mehrere Threads verteilt werden kann muss ein passender Scheduler her oder Module und die Ergebnisse der Berechnungen müssen auch wieder zusammengeführt werden da viele voneinander abhängig sind. Software auf multithreading zu optimieren ist je nach Anwendungsgebiet sehr komplex.

Das ist mir schon klar als Softwareentwickler, nur du hast oben nicht einfach 6 Kerne gesagt, sondern 6 Kerne + HT. Um 6 Kerne inkl. HT auszunutzen muss die Software 12 Threads bereitstellen die zumindest manchmal nicht alle gleichzeitig idlen.
Das wiederum sollte zumindest "ein wenig" auf 12 echte Kerne + HT skalieren.

Ist die Aussage von MS oder empirisch festgestellt worden? In letzterem Fall kann natürlich sein dass diese Momente wo 12 Threads zeitgleich arbeiten, so selten oder kurz sind dass mehr echte Kerne keinen messbaren Anstieg mehr bringen.

@Bitmaschine
Wie schon erwähnt wurde ist es schlicht nicht so simpel.
Es ist programmiertechnisch bei manchen Aufgaben nicht möglich sinnvoll mehr Kerne zu verwenden.
Nehmen wir mal als ganz einfaches Beispiel eine Physikengine die in vielen Games zum Einsatz kommt. Diese hat in erster Linie damit zu tun die Bewegung und Kollision von Objekten zu berechnen. Singlethreaded würde man nacheinander durch alle Objekte durchgehen und anhand der Geschwindigkeiten, jeweils die neue Positionen berechnen. Dann im zweiten Durchlauf werden alle Kollisionen und daraus resultierenden neuen Geschwindigkeiten berechnet.

Wenn du das nun multithreaded machen willst, musst du eine Anzahl an Objekten jedem Thread zuweisen und dann alle laufen lassen. Soweit so gut, das lässt sich belibig skalieren.
Problem ist aber nach dem ersten Schritt musst du erst alle Threads synchronisieren denn wenn du beide Aufgaben (Bewegung UND Kollisionen) sofort nacheinander ausführst, dann kollidiert ein Objekt aus Thread A womöglich mit einem Objekt aus Thread B welches noch garnicht seine neue Position erhalten hat.
D.h. entweder musst du synchronisieren was einen Zeitverlust bedeutet weil manche Threads auf andere warten, oder du musst per Rechenaufwand vorher feststellen welche Objekte garantiert nie kollidieren werden und nur diese getrennten Threads zuteilen.

Beide Lösungen werden aufwendiger bzw. nachteilbehafteter je mehr Threads es gibt.
Darum ist dem ganzen quasi ein physikalisches Limit gesetzt.
Hinzu kommt dann auch noch ein ganz pragmatisches Problem: Was wenn ein Thread genau in dem Moment einen neuen Wert schreibt während ein anderer liest? Unter Umständen kommt bei sogenannten nicht-atomaren Operationen dann kompletter Unsinn raus.
Das zu verhindern erfordert ebenfalls einen Aufwand der mehr Rechenleistung bzw. Zeit kostet je mehr Threads gleichzeitig laufen.

Btw. wenn immer möglich werden die Threads durchaus an den vorhanden Threads der Hardware angepasst (windows gewährt einem Zugriff auf diese Information). Es wird aber nach unten angepasst, denn nach oben ist einfach ein limit.

Hoffe das ist damit jetzt klarer

 

[Bitmaschine]

Ja, danke. Mir kam es einfach nicht in den Sinn, dass das eine vom anderen abhängig sein kann und ist. Was in der Komplexität limitiert. Kurzer gedanklicher Fehler.

 

[Romsky]

@DragonTear
Ok, wusste nicht das du ein Kollege bist. ^^
Ja, laut diversen Tests war ab 6 Kernen + HT keine Mehrleistung mehr zu erreichen. Korrekt ist, wenn diese Aussage stimmen sollte, das man mit 12 Kernen ohne HT nochmals etwas an Leistung gewinnen können sollte.

 

[Micke]

Ich glaube eher du weisst nicht wie genau das läuft. Im Code muss du eher sehr viele Zeilen einbauen um verschiedene Aufgaben aufzuteilen so das mehrere Threads und somit auch Kerne genutzt werden können. Umso mehr Threads genutzt werden sollen umso schwerer wird es. Manche Aufgaben kann man nicht einmal in mehrere Threads aufteilen. Es ist also nicht so das MS da extra Zeilen einbaut damit nur 6 Kerne + HT genutzt werden, sondern man hat Zeilen integriert damit überhaupt mehr als 1 Kern genutzt werden kann. Denn Standard wäre 1 Thread.

Wofür diese Aufklärung ? Daß der Flugsimulator Multithreading beherrscht ist ja geklärt wenn er auf 6 Kerne verteilen kann. Der default bei MT ist aber eben "nimm alle Kerne", nicht nimm max 6.
Die kleinsten Einheiten bei Parallelisierung sind ja nicht Threads, sondern die Funktionen.
Sodaß bei der Vielzahl von Funktionen im Flugsimulator-Code auf dem von dir erwähnten Scheduler so ein riesiges Kommen & Gehen herrscht, daß die genaue Anzahl von Kernen/Threads eine völlig untergeordnete Rolle spielen sollte. Es wäre genug für jedwede CPU da.
Es sei denn man managed Threads selbst, statt es dem Scheduler zu überlassen, oder der Code erlaubt keine bessere Skalierung.
Beides spricht für eine schlechte Abstraktion.

 

[DragonTear]

Wofür diese Aufklärung ? Daß der Flugsimulator Multithreading beherrscht ist ja geklärt wenn er auf mehrere Kerne verteilen kann. Der default bei MT ist aber "nimm alle Kerne", nicht nimm max 6.
Desweiteren sind die kleinsten Einheiten bei Parallelisierung übrigens nicht Threads, sondern die Funktionen.
Sodaß bei der Vielzahl von Funktionen im Flugsimulator-Code auf dem von dir erwähnten Scheduler so ein riesiges Kommen & Gehen herrscht, daß die genaue Anzahl von Kernen/Threads eine völlig untergeordnete Rolle spielen sollte. Es wäre genug für jedwede CPU da.
Es sei denn man managed Threads selbst, statt es dem Scheduler zu überlassen, oder der Code erlaubt keine bessere Skalierung.
Beides spricht für eine schlechte Abstraktion.

Was redest du da für überheblichen Quatsch. Es gibt sicherlich Ansätze, Software in "Jobs" einzuteilen (so nennt Unity das z.B.) welche durch einen integrierten Scheduler verwaltet werden, aber ganz bis auf einzelne Funktionen runter geht das praktisch nicht und es skaliert auch nicht ins Unendliche.
Während solche Konzepte zwar den Entwicklungsaufwand etwas verringern, so muss man doch einiges an Zeit/Aufwand in die Logik investieren. 12 parallele Threads mit messbarem Leistungsanstieg sind schon ein starkes Stück. Mehr hat wohl einfach wirtschaftlich keinen Sinn gemacht.
Erwartest du wirklich skalierung bis auf einen Threadripper mit 64 Kernen? Welche GPU soll das dann stemmen?

Wie auch immer, in diesem Thread sollte es eigentlich um RAM OC gehen, erinnert sich noch wer?

 

[Micke]

"aber ganz bis auf einzelne Funktionen runter geht das praktisch nicht und es skaliert auch nicht ins Unendliche"
Dann ist dein Wissensstand veraltet. Asynchrone Funktionen sind schon seit Jahren die bessere Alternative zu dedizierten Threads. Echt, als Entwickler traust du dir neue Technologie als Quatsch abzutun, wenn du sie noch nicht kennst ? Gute Jobwahl

"Erwartest du wirklich skalierung bis auf einen Threadripper mit 64 Kernen? Welche GPU soll das dann stemmen? "
Lustige Sicht. Diesen Zusammenhang gibt es überhaupt nicht. Du meinst die GPU ist bei einem Schachprogram überfordert, wenn die Threadripper CPU darunter auf Anschlag ist ? Ja genau

 

[DragonTear]

"aber ganz bis auf einzelne Funktionen runter geht das praktisch nicht und es skaliert auch nicht ins Unendliche"
Dann ist dein Wissensstand veraltet. Asynchrone Funktionen sind schon seit Jahren die bessere Alternative zu dedizierten Threads. Echt, als Entwickler traust du dir neue Technologie als Quatsch abzutun, wenn du sie noch nicht kennst ? Gute Jobwahl

Ach das meinst du. Sowas kenne ich ehrlich gesagt nur aus der Webentwicklung und einigen Businessapplikationen.
Kennst du eine AAA Game engine die das in grossem Stil einsetzt?
Meines Wissens nach steigt der Overhead dabei zu schnell wenn die komponenten so vielschichtig miteinander verwoben sind wie games. Einen Webseitenbau kann man nunmal besser abstrahieren.
Es ist jedenfalls kein Allheilmittel für Parallelisierungsprobleme!

"Erwartest du wirklich skalierung bis auf einen Threadripper mit 64 Kernen? Welche GPU soll das dann stemmen? "
Lustige Sicht. Diesen Zusammenhang gibt es überhaupt nicht. Du meinst die GPU ist bei einem Schachprogram überfordert, wenn die Threadripper CPU darunter auf Anschlag ist ? Ja genau

Wir redeten hier von einem konkreten Spiel/Programm: Dem neuen MS Flugsimulator.
Klar gibt es software die sich sehr gut paralelisieren lässt. 3D games sind aber nunmal meist am Ende durch die GPU limitiert.

 

[RcTomcat]

Das Vorschaubildchen auf der HWLuxx Startseite titelt: Luxxkomensator: Arbeitsspeicher
Da ist wohl was falsch geschrieben worden ^^.