-
Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Andere Planet Zoo - Wieviel FPS sind mit meinem Sytem zu erwarten (MSI GTX 1070 - AMD 2600)
- Ersteller Blacksystem1
- Erstellt am
Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 12.310
Das ist leider oft zu beobachten.....es ist einfacher pauschal alles schlecht zu finden, als differenziert Kritik zu üben.burglar225 schrieb:Mindestens genauso schlimm ist, dass dann immer in Extremen gesprochen wird. Eine Software kann nur gut oder absoluter Murks sein, wie in deinem Fall.
Ist nicht nur hier so, noch schlimmer ist es in der Politik, denn da steht mehr dahinter als eine ruckelige Spielerfahrung irgendeines Spiels.
Jain....Wenn Handwerker A sich keine Mühe gibt und die Heizung schräg montiert, dann darf ich mich meiner Meinung nach, beschweren, weil es ja offensichtlich auch gerade geht.....dann müsste ich es selbst machen oder hoffen, dass Handwerker B es besser macht.burglar225 schrieb:Ich erzähl doch auch meinem Handwerker nicht, wie er die Heizung zu montieren hat. Warum also ist es im Gamingbereich so verbreitet von schlechter Software, schlechter Engine oder schlechter Optimierung zu sprechen, wo man doch eigentlich von der Thematik überhaupt keine Ahnung hat? Das Glanzbeispiel wird hier wohl immer das Multihreading sein, von dem der normale Gamer immer annimmt, dass sie ja immer perfekt funktionieren muss und möglichst alle zwei Millionen Kerne absolut perfekt ausgelastet sind. Kleiner Tipp: Das ist aus technischer Sicht grober Unfug. Vor allem bei Spielen, wo vieles einfach nicht gleichzeitig berechnet werden kann, ist da schon viel früher Schluss. Das liegt aber keineswegs an der Unfähigkeit irgendwelcher Entwickler, sondern ist ganz und allein einem extrem schwierigen Thema der Softwareentwicklung geschuldet.
Wenn auch unendlich komplexer, sehe ich das bei Software auch so.
Ich sehe in manchen Spielen was möglich ist, und ärgere mich wenn es dann bei anderen Spielen nicht funktioniert.
Man muss ja unterteilen in Multithreading und Programmierkunst, die es möglich macht moderne CPUs mit vielen Threads und neuen Befehlssätzen effektiv auszunutzen, und der Optimierung auf sinnvolle Simulationskomplexität.
AotS kann in DX12 und Vulkan meine 16 Thread CPU fast vollständig auslasten.....90% sehe ich bei so vielen Threads als fast vollständig an.
Aber trotzdem läuft es in vielen Situationen eher mau....da wird einfach zu viel simuliert, von dem ich keinen sinnvollen Nutzen habe....die Entwickler haben sogar für CPUs mit mehr Kernen auch mehr Arbeit vorgesehen.
Aber technisch ein Meisterwerk.
Cities Skylines und Anno 1800 sind ja recht ähnlich bei der CPU Auslastung....so grob 5 Threads.....hat man mehr CPU Leistung läuft es trotzdem nicht besser weil ein Thread limitiert.....und das nicht wegen einer komplexen Simulation sondern vor allem wegen den Drawcalls.....irgendwann natürlich auch zusätzlich wegen der Simulation, aber guckt man nur das Meer an, sind die FPS super und nur über den Städten ist es schlecht...dann kann die Wegfindung und Berechnung der Produktionsabläufe ja nicht der limitierende Faktor sein.
Und da ärgere ich mich halt über Anno, wenn andere Spiele mit DX12 die Drawcalls ordentlich verteilt bekommen und Anno nicht....es wird besser aber kein Vergleich zu Spielen wie AotS, Rise- und Schadow-otTR.
Wenn es also möglich ist(und es kein kleines Entwicklerstudio ohne Geld ist), warum wird dann hier nicht mehr Arbeit in die Entwicklung gesteckt?
Da gebe ich nicht den einzelnen Entwicklern die Schuld.....das ist eher ein Problem im Management.
Anno 1800 haben sie ganz stolz mit ca 30 FPS auf einer iGPU von Intel zum laufen gebracht....schön...30FPS bei einer mini Siedlung und alles auf niedrigsten Settings.
Mir ist klar, dass man nicht alles multithreaden kann....und auch irgendwann weniger mehr ist.
Wenn sich 32Threads absprechen wer was wo rechnet und wie das in einem chronologisch zu ordnenden Spielablauf, wieder zusammengefügt werden kann, dann ist da mehr Zeit in der Kommunikation zwischen den Kernen verloren, als Gewinn durch die zusätzlich benutzen Threads möglich ist.
Aber wie beim Handwerker.....ich muss nicht jede Arbeit gutheißen, nur weil ich sie nicht selbst durchführen kann.
Es ist möglich seine Software zu optimieren...sei es auf bessere Auslastung der Hardware oder auf weniger komplexe Simulation/Drawcalls.
Frostpunk hat z.B. vor kurzem ein Update erhalten und plötzlich läuft es auf meinem PC statt mit ruckeligen Frametimes plötzlich mit stabilen Frametimes....mehr FPS .....Weil sie irgendwie an der CPU Auslastung gearbeitet haben und endlich meine AMD GPU besser ausgelastet wird.
Da war also viel Optimierungspotential vorhanden.
....wobei ich das Spiel auch ruckelig genossen habe.....echt eine Perle.
burglar225
Lt. Commander
- Registriert
- Juni 2004
- Beiträge
- 1.919
Das ist natürlich klar, meine Aussage habe ich auf der Prämisse getroffen, dass der Handwerker weiß, was er tutBaal Netbeck schrieb:Jain....Wenn Handwerker A sich keine Mühe gibt und die Heizung schräg montiert, dann darf ich mich meiner Meinung nach, beschweren, weil es ja offensichtlich auch gerade geht.....dann müsste ich es selbst machen oder hoffen, dass Handwerker B es besser macht.
Nein, eigentlich nicht. Ein Problem bei der Parallelisierung von Software ist, dass immer dann, wenn etwas parallel ausgeführt werden soll, an anderer Stelle darauf gewartet werden muss, dass die Ausführung beendet wird. Allein aus diesem Grund stößt jedes Multithreading eher früher wie später an seine Grenzen. Ein weiterer Punkt ist, dass Multithreading nicht so funktioniert, wie man es gemeinhin annehmen könnte. Multithreading findet auf einer sehr viel tieferen Ebene statt, wie man sie sich normalerweise nur vorstellen kann. Wir reden nicht davon, dass wir einzelne Funktionen parallel ausführen (z.B. Laufen von A nach B von zwei Spielfiguren), sondern vielmehr davon auf dem einen Core zu addieren und auf dem anderen zu subtrahieren.Baal Netbeck schrieb:Man muss ja unterteilen in Multithreading und Programmierkunst, die es möglich macht moderne CPUs mit vielen Threads und neuen Befehlssätzen effektiv auszunutzen, und der Optimierung auf sinnvolle Simulationskomplexität.
Der Thread limitiert aber nicht aus Lust und Laune, sondern vielmehr, weil er der Thread ist, der auf den Abschluss von Operationen wartet (s.o.). Das ist ganz einfach eine technische Limitierung, die man (vermutlich) niemals in den Griff bekommen wird.Baal Netbeck schrieb:Cities Skylines und Anno 1800 sind ja recht ähnlich bei der CPU Auslastung....so grob 5 Threads.....hat man mehr CPU Leistung läuft es trotzdem nicht besser weil ein Thread limitiert
Völlig und absolut richtig, nur sollte man hier wirklich noch sagen, dass es da schon viele Verbesserungen in der Richtung gab.Baal Netbeck schrieb:Aber wie beim Handwerker.....ich muss nicht jede Arbeit gutheißen, nur weil ich sie nicht selbst durchführen kann.
Es ist möglich seine Software zu optimieren...sei es auf bessere Auslastung der Hardware oder auf weniger komplexe Simulation/Drawcalls.
Das Problem bei Performance-Fixes ist, dass diese tatsächlich oft einfach vom Himmel fallen. Hier hat mal ne Idee etwas effizienter zu berechnen, dort fällt ein Fehler im Code auf, etc. Es ist extrem schwierig (abseits von üblichen Patterns) etwas gleich auf Performance zu trimmen.
Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 12.310
Wenn es kein Spiel schaffen würde, würde ich dir Recht geben.burglar225 schrieb:Der Thread limitiert aber nicht aus Lust und Laune, sondern vielmehr, weil er der Thread ist, der auf den Abschluss von Operationen wartet (s.o.). Das ist ganz einfach eine technische Limitierung, die man (vermutlich) niemals in den Griff bekommen wird.
Aber manche Spiele schaffen es, viele Threads zu nutzen und nicht über einen Thread limitiert zu sein.
Bei DX6-11 stimme ich dir auch zu...aber es gibt ja inzwischen DX12 und Vulkan(und Mantel), die hier viel weiter sind.
Soweit ich weiß, ist in der Regel nicht irgendeine Simulation Schuld an den meisten CPU limits....es sind die Drawcalls, die der Grafikkarte bei DX11 in einem großen Schub geliefert werden und das über den "Renderthread".
Der muss alles synchron halten...die Drawcalls bearbeiten und den Treiber auch noch.
Und der kann nicht unendlich viel auslagern, da stimme ich dir zu.
So enden diese Spiele dann über einen Thread limitiert....und dass es da keine Spiele gibt, die mehr als 5 Thrads wirklich ausnutzen, scheint da auch irgendwo das sinnvolle Limit zu sein.
Aber mit DX12 ist es ja möglich, dass jeder Thread selbst seinen Teil der Drawcalls an die GPU sendet.
Eigentlich kann da jeder Thread einen Teil der Arbeit zugewiesen bekommen und sie ohne weiteres absprechen an die GPU senden.....zumindest habe ich dazu vor Jahren mal einen Artikel gelesen.
Beispiel SotTR ....da kann DX12 die Performance grob verdoppeln.
von 42,8 auf 79,3 FPS....1% low Frametimes von 24 auf 52,8 1/s.....das ist nur möglich weil jetzt mehr als 8 Threads voll ausgelastet werden.........würde es nichts bringen mehr Multithreading zu betreiben, würde die Performance nicht so stark steigen.
Da kann ich dir aufgrund von Unwissenheit nicht widersprechen, aber es erscheint mir sehr unlogisch.burglar225 schrieb:Wir reden nicht davon, dass wir einzelne Funktionen parallel ausführen (z.B. Laufen von A nach B von zwei Spielfiguren), sondern vielmehr davon auf dem einen Core zu addieren und auf dem anderen zu subtrahieren.
Wenn ich beides mit SMT/HT auf einem Kern abarbeiten möchte, dann klingt das gut, aber ich möchte ja vor allem weitere echte Kerne nutzen und nur im Notfall auf SMT zurückgreifen.
Und da würde ich davon ausgehen, dass es deutlich schneller ist, zusammenhängende Aufgaben auf den gleichen Kernen zu bearbeiten.
Sonst habe ich doch dauernd Cache misses und muss zwischen den Kernen kommunizieren und auf den Ram zugreifen.
Habe ich die Bewegung von Figur A auf einen Thread und die Bewegung von B auf einem Thread, sind deren Daten größtenteils im Cache und laufen um ein vielfaches schneller ab.
Natürlich wird nicht die Bewegung von den jeweiligen Figuren beschleunigt....aber ich kann viele Figuren gleichzeitig berechnen....und das bestimmt schneller als den Abstand der Figur von irgendwas(subtrahieren), auf einem Kern und das Vorwärtsbewegen(addieren) der Figur, auf einem anderen Kern, zu rechnen.
Ich kann nur Basics in C++....es reicht für Konsolenanwendungen, die Daten einlesen, verarbeiten und ausgeben oder in Dateien schreiben.....mein Code ist sicherlich ein Graus für jeden echten Informatiker, aber mir ist es egal ob das 0,2 oder 0,4s zum Rechnen braucht.
Und ich wüsste auch nicht, wie ich das irgendwie auf multithread programmiert bekomme......auch wenn da viel Potential da ist, weil ich z.B. mit 10 Dateien, erst 10 mal das gleiche mache und dann erst die Ergebnisse weiterverarbeite.....den ersten Teil, der deutlich aufwendiger ist, könnten bei mir locker 10 Threads parallel rechnen...und auch im zweiten Teil könnten viele Einzelaufgaben parallel berechnet werden, da sie nicht vonneinander abhängig sind.
Nur irgendwie scheint es ja zu funktionieren.....sonst gäbe es keine Spiele, wo beliebige Threads genutzt werden oder Spiele wo spezielle Sachen wie Physikberechnungen ausgelagert werden(Anfänge der Multithreadprogrammierung z.B. in Crysis 1)
Ähnliche Themen
- Antworten
- 10
- Aufrufe
- 1.491
- Antworten
- 18
- Aufrufe
- 6.204