Jump to content

Warum wird nur mit 2 Kernen gearbeitet?


Gixxuki

Recommended Posts

Moin,

 

da ich schon von Anfang an Probleme mit der Framerate hatte, habe ich mich mal ans Ursachen suchen gemacht. Gerade wenn rechenintensive Sachen, wie der Litening TGP, laufen schwinden die FPS dahin. Gehe ich in die Außenansicht und Instrumente etc. müssen nicht mehr berechnet werden, ist alles okay. Mir ist aufgefallen, dass DCS nur 2 der 6 Kerne nutzt. Zum Einsatz kommt ein AMD Phenom 1100t Prozessor. Ist das normal, oder stimmt da irgendwas nicht. :cry:

 

Gruß Gixxuki

Link to comment
Share on other sites

Gibt es da überhaupt Tendenzen, mehr Kerne zu nutzen? Wie schwierig ist das, Rechenprozesse auf verschiedene Kerne aufzuteilen?

 

Ist es nicht ungenutztes Potential in unserer Welt, in der die meisten Leute mehr als 2 Kerne im CPU haben?

PC: Asus P8Z77-M Mainboard; Intel i5-3570K (4x3,4Ghz) mit Scythe Mugen 3 CPU Kühler; 16Gb Corsair XMS3 1600Mhz; Nvidia GTX570 1280mb; Samsung 830 SSD; Samsung HDD

Flight Sim Gear: TM Warthog; Saitek Pro Pedals; TM Cougars on an 19" screen; TrackIR 5 w/ trackclip pro; Logitech G35 headset

Link to comment
Share on other sites

Moin,

 

ja das mit der CPU Auslastung ist echt schon ein Problem.

Bevor Black Shark in der Version 1.02 herraus kam wurde immer nur ein Kern genutzt.

Erst mit dem Patch haben die Entwickler die Soundengine ausgelagert.

Das war wahrscheinlich so das einfachste was man machen konnte.

 

Wenn man alle anderen Bereiche trennen will, also Physik, Wetter, KI, Netzwerk und Grafik-Engine dann muss man fast alles neu entwickeln.

Weil alle diese Bereiche sehr doll mit einander verwoben sind.

Ersteinmal muss man die Schnittstellen zwischen den einzelnen Bereichen definieren, und abwägen wie wichtig der Informationsfluss zwischen den einzelnen Bereichen ist.

 

Wenn das alles geklärt ist, dann kann man anfangen die einzelnen Bereiche zu trennen. Sicherlich lässt sich vieles des bestehenden Codes weiter verwenden.

 

Ich hoffe das war jetzt nicht zu viel der Theorie oder gar falsch (wenn doch kann das jemand ergänzen oder berichtigen).

 

Derzeit wird ja eine neue Grafik-Engine (EDGE) entwickelt und die wird sicherlich einen eigenen Kern benutzen können.

 

CU Micha

Simpit Software by SDA "SIMPIT DEVELOPER ASSOCIATION"

  • DCS ExportScript
  • D.A.C. DCS to Arcaze Communicator
  • Ikarus a new Virtual Cockpit Software

Deutscher Forums Thread

English Forums Thread

 

Hard/Software: AMD Ryzen 7 1800X, 32 GiB RAM, extra SSD for Windows 10 and DCS World, AMD Vega Frontier Edition with 16 GiB VRAM

Link to comment
Share on other sites

Wie schwierig ist das, Rechenprozesse auf verschiedene Kerne aufzuteilen?

 

Das ist extrem schwierig, vor allem wenn die Software nicht von der Pike auf darauf ausgelegt ist. Das größte Problem ist nicht, die Software in einzelne Teile aufzuteilen, sondern diese zeitlich so zu synchronisieren, dass die Aufteilung auch etwas bringt (sprich, damit das Ding schneller oder zumindest gleich schnell als auf einem Kern läuft).

Good, fast, cheap. Choose any two.

Come let's eat grandpa!

Use punctuation, save lives!

Link to comment
Share on other sites

Hm, jetzt kenn ich mich auch nicht so mit der Programmierung aus, aber kann man nicht zB. bestimmte Bereiche der Grafik (bsp: Die Anzeigen der Instrumente) auf einem anderen Kern berechnen lassen? Ich hab wo gelesen, dass die wohl eine der fps bremsen sind.

 

Sobek: Du meinst dass Multicore = komplette Neuprogrammierung bedeutet? Ich meine: inwieweit rechtfertigt eine Multikernauslegung den benötigten Aufwand.

 

Bezogen auf EDGE: Neue Engine auf einem weiteren Kern... was wird dann noch im ursprünlgichen Kern berechnet.

 

Also 1. ?

2. Sound

3. EDGE

4. Idle

 

Die virtuellen vier werden genutzt wenn ich die physikalischen benutze oder?

 

Sind ein paar Fragen für einen Post, aber wie ihr seht, kenn ich mich selbst noch nicht so damit aus und würde gerne mehr darüber erfahren.

 

Guten Flug!

PC: Asus P8Z77-M Mainboard; Intel i5-3570K (4x3,4Ghz) mit Scythe Mugen 3 CPU Kühler; 16Gb Corsair XMS3 1600Mhz; Nvidia GTX570 1280mb; Samsung 830 SSD; Samsung HDD

Flight Sim Gear: TM Warthog; Saitek Pro Pedals; TM Cougars on an 19" screen; TrackIR 5 w/ trackclip pro; Logitech G35 headset

Link to comment
Share on other sites

  • 2 weeks later...
Das ist extrem schwierig, vor allem wenn die Software nicht von der Pike auf darauf ausgelegt ist. Das größte Problem ist nicht, die Software in einzelne Teile aufzuteilen, sondern diese zeitlich so zu synchronisieren, dass die Aufteilung auch etwas bringt (sprich, damit das Ding schneller oder zumindest gleich schnell als auf einem Kern läuft).

 

Das ist der tat das problem. Schneller wird die Software sicherlich laufen, allerdings passieren gerne irgendwelche unabsehbaren Fehler wenn der ein Thread schon schneller fertig war als gedacht. Ich habe selbst nur kleine Programme in Java geschrieben und bin dort schon mehrfach an solche Probleme gestoßen. Hat fast immer ein komplettes Redesign der Softwarearchitektur mit sich gebracht. Seit dem schreibe ich alles was ich programmiere immer mit dem hintergedanken es in mehreren Threads laufen zu lassen.

 

Dabei kann man gerne auch mehr Threads als man Prozessorkerne hat benutzen, weil es nicht bremst und zukünftige Prozessoren mit mehr Kernen unterstützen wird.

 

Wenn also EDGE kommt und das auf einmal 64 Threads benutzt, ist das gut.

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

Dabei kann man gerne auch mehr Threads als man Prozessorkerne hat benutzen, weil es nicht bremst und zukünftige Prozessoren mit mehr Kernen unterstützen wird.

 

Naja, stimmt nicht ganz, oder? Je mehr Threads du herumschieben musst, desto mehr Overhead produziert dir vermutlich der Scheduler.

Good, fast, cheap. Choose any two.

Come let's eat grandpa!

Use punctuation, save lives!

Link to comment
Share on other sites

Naja, stimmt nicht ganz, oder? Je mehr Threads du herumschieben musst, desto mehr Overhead produziert dir vermutlich der Scheduler.

 

Schon, ist aber zu vernachlässigen. Ist ja schon heute von vorteil, beispielsweise die ganzen Core i7 mit ihrem Hyper Threading. Es gibt schneller echte 8-Kerner in normalen PCs als man sich vorstellen kann. Früher oder Später wird wohl der Task Manager umgebaut werden müssen, weil 16 verschiedene Charts für die simulierten Kerne anzuteigen irgendwie unübersichtlich wird :)

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

Also bei mir sieht das so aus als würde DCS mindestens vier Kerne nutzen:

cpudcszmu1j.jpg

Im Hintergrund laufen noch Firefox, Thunderbird, TS3 und Steam. Ohne DCS liegt die Prozessorauslastung bei ~<1-5%



CPU: AMD Ryzen 9 5900X | Mobo: Gigabyte X570 Aorus Pro | RAM: 64GB DDR4 3600 G.Skill TridentZ | GPU: Palit RTX3080 Ti 12GB | SSDs: 2xSabrent Rocket 1TB M.2 | Samsung Pro 256GB | Samsung EVO 850 500GB | Samsung QVO 1TB 

Peripherals: Warthog HOTAS | TrackIR 5 | MFG Crosswinds | 3xTM Cougar MFDs | HP Reverb G2
 
Link to comment
Share on other sites

Ein Programm in Threads zu organisieren erfordert, dass die gesamte Programmstruktur in unabhängige Module aufgeteilt wird. Ein Thread ist ein kleines, eigenständiges Programm in einem Programm. Um die Effektivität auszunutzen muss man möglichst Abhängigkeiten zwischen den Threads vermeiden. Z.B. sollte ein Thread nicht warten müssen bis ein anderer Thread sein Ergebnis geliefert hat. In der Praxis zerlegt man ein Flugzeug in seine, für die Simulation wichtigen Teile. Z.B. Triebwerk, Flügel, Rumpf, Fahrwerk, atmosphärische Umgebung... Jedes dieser Module kann in einem eigenen Thread laufen und liefert seine Ergebnisse an eine gemeinsame Ergebnisliste. Aus dieser Ergebnisliste können dann die Kräfte errechnet werden, die auf das Flugzeug einwirken. Umgekehrt kann jeder Thread Parameter aus der Liste verwenden um seine eigenen Funktionen zu berechnen. Auf diese Art ist die Synchronisation auf die Listenzugriffe beschränkt. Diese können mit einiger Disziplin durch Zugriffsobjekte geschützt werden. Wir haben auf diese Weise bis zu 250 Flugzeuge (Threads) in einer Simulation berechnet. Dabei ist der Thread Overhead vernachlässigbar. Das eigentliche Nadelöhr ist der Transport der Geometriedaten auf den Bildgenerator. Geschieht dies im gleichen Computer, so existiert nur ein einziger Zugang für alle 250 Flugzeuge auf die Grafikkarte. Damit ist zwar ein Teil des Gewinns wieder verloren aber alle anderen Treads müssen nicht warten. Sie können unabhängig weiterrechnen. Das Windows Betriebssystem verteilt die Threads gleichmäßig auf alle Kerne. Diese Lastverteilung bringt den größten Gewinn. Mit den Windows Server Betriebssystemen kann man sogar Threads gezielt auf bestimmten Kernen laufen lassen. Alles in allem kann aber ein bestehendes, linear organisiertes Programm kaum auf Threads umorganisiert werden. Dazu kommt noch die nach meiner Erfahrung weit verbreitete, herzliche Abneigung zu Threads bei den Grafikprogrammierern. Trotzdem wird sich das Prinzip in der Zukunft immer mehr durchsetzen. CPUs mit 12 Kernen sind nichts mehr Besonderes. Leider hat das Konzept in dieser Form noch keinen Zugang zu Grafikkarten gefunden. Das wäre der nächste große Schritt.

TOWSIM

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

 

Derzeit wird ja eine neue Grafik-Engine (EDGE) entwickelt und die wird sicherlich einen eigenen Kern benutzen können.

 

Wurde das irgendwo angekündigt?

Spoiler

AMD Ryzen 9 5900X, MSI MEG X570 UNIFY (AM4, AMD X570, ATX), Noctua NH-DH14, EVGA GeForce RTX 3070 Ti XC3 ULTRA, Seasonic Focus PX (850W), Kingston HyperX 240GB, Samsung 970 EVO Plus (1000GB, M.2 2280), 32GB G.Skill Trident Z Neo DDR4-3600 DIMM CL16, Cooler Master 932 HAF, Samsung Odyssey G5; 34", Win 10 X64 Pro, Track IR, TM Warthog, TM MFDs, Saitek Pro Flight Rudders

 

Link to comment
Share on other sites

Ich muss das ein wenig relativieren. Die modernen Grafikkarten haben natürlich auch mehrere GPUs und Shader-Einheiten, die vordergründig parallel arbeiten. Nur, der Programmierer hat fast keinen Einfluss auf den Arbeitsablauf. Mann kann natürlich auch kleine Programme für die Grafikkarte schreiben, die auf die Karte geladen werden können und an den verschiedensten Stellen in die Render Pipeline eingreifen können. Eine echte Thread-Unterstützung wäre die Schaffung mehrerer Übergabepunkte auf dem PCI Bus,die quasi parallel benutzt werden können. Besser wäre noch ein neuer Technikstandard, der mehrere Übergabepunkte in einem Steckslot vereint und eine Neukonstruktion der Rendersoftware auf der Grafikkarte. Letztere müsste ganze Objekte, z.B. Flugzeuge, auf der Karte zusammensetzen und verwalten anstatt nur Dreiecke und Texturen. Das gab es alles schon mal vor 20 Jahren mit dem TIGA Standard von Texas Instruments. TIGA konnte sich nicht durchsetzen, da Windows nicht 100%tig unterstützt wurde. Aber die Welt bleibt nicht stehen. Ich glaube, dass wir in den nächsten zehn Jahren einiges im Grafikmarkt erleben werden.

TOWSIM

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

War es nicht so (der Erfahrung nach nicht, aber ich meine, ich habe das mal gelesen), dass Windows 7 die Thread-Organisation übernehmen kann und einen Thread auf mehrere Kerne verteilen kann? Bin jetzt aber auch nicht so tief da drin und zweifle gerade, ob sowas möglich ist.

Aber irgendwas soll win7/8 doch bzgl. Multithreading besser machen...

 

Hyperthreading habe ich bei mir ausgeschaltet, in der Hoffnung, dass die ganzen Singlekern-Nutzer dadurch mehr Leistung bekommen. Vollast-Programme, die 100% nutzen, wenn sie Amok laufen, sind ja auch bei 4 realen Kernen kein Problem.

Vielleicht war es auch das, dass Win7 beim Hyperthreading einen Prozess auf zwei virtuelle Kerne verteilt? Dann hätte ich durch Ausschalten von HT keinen Vorteil.

 

Fragen über Fragen.


Edited by hypocrisie
Link to comment
Share on other sites

DirectX 10 und 11 sind AFAIK in der Lage die Prozessorlast auch ohne entsprechende Programmierung auf die Kerne zu verteilen. Das geht natürlich erst ab Vista.

 

XP ist ohnehin nur ausgelegt, um maximal 2 Kerne zu nutzen. Übrigens auch mit ein Grund, warum die Portierung von DX10/11 auf XP aufgegeben wurde.

 

 

Wie gesagt: Die 4+4 "Kerne" teilen sich in dem Beispiel schon die Arbeit, aber es bringt keinen Geschwindigkeitsvorteil, weil die Software dafür nicht ausgelegt ist. Immerhin minimiert es nach meinem Wissensstand Ruckler und Ladezyklen, da die einzelnen Kerne so etwas mehr Puffer haben.

Gigabyte GA-Z87-UD3H | i7 4470k @ 4.5 GHz | 16 GB DDR3 @ 2.133 Ghz | GTX 1080 | LG 55" @ 4K | Cougar 1000 W | Creative X-Fi Ti | TIR5 | CH HOTAS (with BU0836X-12 Bit) + Crosswind Pedals | Win10 64 HP | X-Keys Pro 20 & Pro 54 | 2x TM MFD

Link to comment
Share on other sites

Hyperthreading macht Sinn bei allen moderneren Betriebssystemen. Eine normale Anwendung ist in der Regel der kleinste Teil der Prozessorlast wenn man solche Anwendungen wie DCS World als Sonderfall betrachtet. Es Laufen ständig 30 bis 50 Betriebssystem Threads und irgendwelche Hintergrundprozesse. Allein deshalb macht es Sinn das Hyperthreading zu aktivieren.

 

Das deutlichste Beispiel kommt aus alten Tagen wo nur ein Kern auf einem Rechner lief. Wenn man damals in einer Applikation eine Endlosschleife ohne Sleep oder Sleep < 2 ms programmiert hat, dann hat der ganze Rechner gehangen. Hypocrisie nennt das in seinem Post sehr schön "Programme, die 100% nutzen, wenn sie Amok laufen". Das kann bei mehreren Kernen kaum passieren weil die anderen Kerne ihre Arbeit normal fortführen.

 

Auch unter XP wurde bereits die Threadlast gleichmäßig verteilt. Dem Betriebssystem ist es schnurzegal ob eine Anwendung single- oder multithreaded organisiert ist. Sobald zwei Anwendungen parallel auf einem Rechner laufen , ist eine Multithread Situation vorhanden denn Jede Anwendung ist im Kern ein Thread.

 

Der Unterschied zu Hyperthreading ist, dass verschiedene Sektionen eines Kerns (nicht der Hauptausführungsteil) hardwaremäßig dupliziert werden. Dabei wird ein zweiter Prozessorkern simuliert und die Benutzung von Ressourcen optimiert. Das bedeutet, wenn ein Thread auf die Freigabe einer Ressource (Speicher, Ports...) warten muss dann wird sofort auf einen andern Thread umgeschaltet. Hyperthreading bringt einen Performancevorteil zwischen 5% bis 30%. Je nachdem wie viele Anwendungen parallel laufen und wie die Anwendungen für Multithreading organisiert sind.

 

Soll eine Anwendung den Vorteil von Multithreading/Hperthreading nutzen, so ist eine bestimmte Programmstruktur einzuplanen, die sich gänzlich von der linearen Programmierung unterscheidet. Lineare Programmierung bedeutet: es existiert in einem Programm nur ein Hauptmodul, z.B. WinMain(), aus dem alle anderen Funktionen als Unterfunktionen in einem ständigen Loop aufgerufen werden. Bei Thread organisierten Programmen werden aus dem Hauptmodul alle nötigen Threads angestarted und das Hauptmodul wird fast arbeitslos. Die Threads steuern das Programm mit ihren Funktionen und kommunizieren untereinander über Messages.

 

Fazit: wer nicht gerade Windows 98 fährt, der sollte wenn möglich das Hyperthreading einschalten.

 

Selbst wenn nur singlethreaded Programme benutzt werden, ist jeder weitere Prozessorkern von Vorteil da das Betriebssystem im Hintergrund intensivst das Multithreading nutzt und eine parallel gestartete, zweite Anwendung midestens einen neuen Thread startet. Der Ärger über Anwendungen, die wegen fehlender Threadorganisation meine schönen 12 logisch Kerne auf eine i7 980 brach liegen lassen ist zwar berechtigt. Der Trost ist aber, das ich meinen Rechner mit parallel laufenden Anwendungen zupacken kann ohne einen Leistungseinbruch zu bemerken. Zu Feuerfalke's Beitrag ist zu sagen, dass seine Beobachtung richtig ist. Man muss sich aber den umgekehrten Fall vorstellen, in dem ein wunderschön threadorganisiertes Programm wie DirectX auf nur einem Kern zusammengepfercht wird. Das ist wie Samstag vormittags in der Schlange an der Supermarktkasse. Selbst da kann man die Performance erhöhen indem man eine zeite, dritte ... Kasse aufmacht.

 

Also, echtes Multithreading wäre weitere Kassen aufmachen. Hyperthreding wäre die Situation, dass während die Oma nach ihrem Kleingeld kramt, würde sich die Kassiererin sofort dem nächsten Kunden zuwenden und sich um die Oma wieder kümmern würde wenn der nächste Kunde fertig ist.

 

Ein singelethreaded Programm wäre die Familie mit 10 Kindern, Opa und Oma, die gemeinsam einkaufen und geschlossen mit einem Einkaufswagen an einer Kasse anstehen (Oma zahlt...).

Das multithreaded Programm wäre die gleiche Familie, in der jedoch soviel wie möglich Einkaufsgruppen gebildet werden. Jede Gruppe kann sich an einer anderen Kasse anstellen.

 

Bitte entschuldigt die lange Ausführung. Ich habe versucht das Thema für alle verständlich zu formulieren.

Gruss,

TOWSIM


Edited by towsim
  • Like 2

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

Super Erklärung! Hat mir sehr weitergeholfen.

PC: Asus P8Z77-M Mainboard; Intel i5-3570K (4x3,4Ghz) mit Scythe Mugen 3 CPU Kühler; 16Gb Corsair XMS3 1600Mhz; Nvidia GTX570 1280mb; Samsung 830 SSD; Samsung HDD

Flight Sim Gear: TM Warthog; Saitek Pro Pedals; TM Cougars on an 19" screen; TrackIR 5 w/ trackclip pro; Logitech G35 headset

Link to comment
Share on other sites

Der Ärger über Anwendungen, die wegen fehlender Threadorganisation meine schönen 12 logisch Kerne auf eine i7 980 brach liegen lassen ist zwar berechtigt. Der Trost ist aber, das ich meinen Rechner mit parallel laufenden Anwendungen zupacken kann ohne einen Leistungseinbruch zu bemerken.

 

JA, ABER! Wenn man prozessorintensive Applikationen nutzt will man ja gerade viel Leistung darauf konzentrieren; der Trost ist keiner. Um im Beispiel zu bleiben: Man will eben, dass 10 Kerne mit DCS beschäftigt werden und nur 2 mit sonstigem Krams, was völlig ausreichen wird, denn es ist schon rein organisatorisch was faul, wenn nicht-interaktive Prozesse "nebenbei" auch noch volle Last haben wollen. Da muss man dann eh einschreiten.

Link to comment
Share on other sites

ist ohnehin nur ausgelegt, um maximal 2 Kerne zu nutzen. Übrigens auch mit ein Grund, warum die Portierung von DX10/11 auf XP aufgegeben wurde.

Aha, und ich dachte DX10 nicht für XP verfügbar, wäre ein Marketingtrick um mehr Vista zu verkaufen. Vlt. auch...

 

Interessanter Thread:). Danke für die super Erklärung und deinem Input towsim.:thumbup:

Deutsche DCS-Flughandbücher

SYSSpecs: i7-4790K @4GHz|GA-Z97X-SLI|16GB RAM|ASUS GTX1070|Win10 64bit|TrackIR5|TM Warthog/Saitek Pro Pedals

Link to comment
Share on other sites

Das war Anfangs ja auch deren Argument: alles nur PR.

 

Aber ganz so problemlos war es dann wohl doch nicht ;)

Gigabyte GA-Z87-UD3H | i7 4470k @ 4.5 GHz | 16 GB DDR3 @ 2.133 Ghz | GTX 1080 | LG 55" @ 4K | Cougar 1000 W | Creative X-Fi Ti | TIR5 | CH HOTAS (with BU0836X-12 Bit) + Crosswind Pedals | Win10 64 HP | X-Keys Pro 20 & Pro 54 | 2x TM MFD

Link to comment
Share on other sites

Also, echtes Multithreading wäre weitere Kassen aufmachen. Hyperthreding wäre die Situation, dass während die Oma nach ihrem Kleingeld kramt, würde sich die Kassiererin sofort dem nächsten Kunden zuwenden und sich um die Oma wieder kümmern würde wenn der nächste Kunde fertig ist.

 

Haha, das war die beste Ausführung zu dem Thema, die ich je gehört habe! :thumbup:

 

You must spread some Reputation around before giving it to towsim again. :cry:

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...