OOP oder Prozedural?
-
die meisten spiele sind heutzutage doch immer noch cpu limitiert, was soll da der unterschied zu frueher sein, als 95% der rechenzeit der cpu fuer graphik draufging
-
Welches Spiel soll denn heute CPU limitiert sein?
Speicher ja, aber CPU? Naja ich weiss nich...
-
Cpp_Junky schrieb:
Welches Spiel soll denn heute CPU limitiert sein?
so ziemlich jedes gut optimierte spiel ist cpu limitiert. deswegen kann man die meisten auch auf 1600*1200 mit 4AA (oder mehr) und 8AF spielen.
hier z.b. shooter benchmarks (und das sind die graphiklastigsten spiele) http://www.hartware.de/review_680_14.html wie du dort sehen kannst bewegt sich die framerate nicht bei moderaten aufloesungen ueberhaupt nicht, und ein AMD64 4000+ ist weit mehr als bei den meisten spielen als optimal angegeben wird.
-
Hm überzeugt mich nicht, ich will einen Test sehen auf dem die Framerate mit einer schnelleren CPU signifikant höher ist.
-
http://www.xbitlabs.com/articles/cpu/display/29cpu-hl2_3.html
Es gibt solche und solche.
Die meisten Spiele-Benchmarks findet man bei den Indoor FPShootern, die noch dazu den Schwerpunkt auf Multiplayer haben, also kaum AI berechnen müssen.Bei Spielen wie Rome-TotalWar, ArmedAssault oder FlightSimX sähe das vermutlich anders aus, hier sind organisierte Benchmarks aber schwer zu finden.
-
Cpp_Junky schrieb:
Hm überzeugt mich nicht, ich will einen Test sehen auf dem die Framerate mit einer schnelleren CPU signifikant höher ist.
Was hat die Framerate mit der CPU zu tun?
-
SeppSchrot schrieb:
http://www.xbitlabs.com/articles/cpu/display/29cpu-hl2_3.html
Es gibt solche und solche.
Die meisten Spiele-Benchmarks findet man bei den Indoor FPShootern, die noch dazu den Schwerpunkt auf Multiplayer haben, also kaum AI berechnen müssen.Bei Spielen wie Rome-TotalWar, ArmedAssault oder FlightSimX sähe das vermutlich anders aus, hier sind organisierte Benchmarks aber schwer zu finden.
Jo da kann man schön sehen, bei welchen Einstellungen was zum Flaschenhals wird. Auf 1024x768 ohne alles ist es klar, das die CPU limitiert. Da schläft die Grafikkarte ja dabei ein. Auf Qualitäts-Einstellungen (1280x1024, 4x FSAA, 16x AF) bewegt sich der Unterschied dann lediglich noch im Bereich von 4 Frames.
lolz schrieb:
Cpp_Junky schrieb:
Hm überzeugt mich nicht, ich will einen Test sehen auf dem die Framerate mit einer schnelleren CPU signifikant höher ist.
Was hat die Framerate mit der CPU zu tun?
Hast du den Thread überhaupt gelesen?
-
Cpp_Junky schrieb:
lolz schrieb:
Cpp_Junky schrieb:
Hm überzeugt mich nicht, ich will einen Test sehen auf dem die Framerate mit einer schnelleren CPU signifikant höher ist.
Was hat die Framerate mit der CPU zu tun?
Hast du den Thread überhaupt gelesen?
Ja hab ich, aber ich hab gepennt (noch zu früh am Morgen :D).
-
Cpp_Junky schrieb:
Jo da kann man schön sehen, bei welchen Einstellungen was zum Flaschenhals wird. Auf 1024x768 ohne alles ist es klar, das die CPU limitiert. Da schläft die Grafikkarte ja dabei ein. Auf Qualitäts-Einstellungen (1280x1024, 4x FSAA, 16x AF) bewegt sich der Unterschied dann lediglich noch im Bereich von 4 Frames.
meistens weil die benchmarks lediglich graphik testen, z.b. die timedemos. sobald logik, physic,sound etc. voll laeuft, bist du in den meisten spielen cpu limitiert.
-
Ja, sowas hab ich mir auch mal gedacht. Also ich hab ein Spiel (Oblivion). Stelle ich bei mir die grafischen Einstellungen auf fast voll, läuft es ganz flüssig. Dann wollte ich mal mehr rausholen, indem ich einige Features runtergeschraubt hab --> kein signifikanter Unterschied.
Das lustigste war sowieso, dass ich manchmal im Spiel heftige Ruckler bei vielen Tieren auf einmal hatte, zig Menschen haben nicht geschadet. Dann entdeckte ich das Problem, der Flaschenhals war meine (Onboard-)Soundkarte. Oblivion erzeugt bei _jedem_ Auftreten von nicht menschlichen Füßen einen realistischen 3D-Sound. Ein Rudel Wölfe hat meine Soundkarte in die Knie gezwungen.
Gruß
Don06
-
"Auf CPU limitiert" bedeutet, "die ganze Arbeit hat die CPU" oder was hat man darunter zu verstehen oO?
-
CPU-limitiert heißt, dass die Grafikkarte sehrwohl noch genügend Power hätte um mehr FPS darzustellen es aber an CPU-Leistung dafür fehlt.
MfG SideWinder
-
hach, da macht es richtig spaß, eines der jüngeren schlagwörter in den raum zu werfen GPGPU.
Bis jetz liegen ja fast alle logischen vorgänge (auch die für tausende instanzen) bei der cpu, die gpu macht grafik. saubere trennung (sollt ich auch ma mit dem müll so halten oO). Eig wäre eine gpu für diese aufgaben aber besser geeignet, aufgrund der konstruktion.
-
piXelshooter schrieb:
Bis jetz liegen ja fast alle logischen vorgänge (auch die für tausende instanzen) bei der cpu, die gpu macht grafik. saubere trennung (sollt ich auch ma mit dem müll so halten oO). Eig wäre eine gpu für diese aufgaben aber besser geeignet, aufgrund der konstruktion.
nein, ueberhaupt nicht.
-
piXelshooter schrieb:
hach, da macht es richtig spaß, eines der jüngeren schlagwörter in den raum zu werfen GPGPU.
Bis jetz liegen ja fast alle logischen vorgänge (auch die für tausende instanzen) bei der cpu, die gpu macht grafik. saubere trennung (sollt ich auch ma mit dem müll so halten oO). Eig wäre eine gpu für diese aufgaben aber besser geeignet, aufgrund der konstruktion.die gpu ist für grafische berechnungen designed, und nicht für logische vorgänge. diese technik nutzt man nur, weil die graka in der logischen rechenphase des programms relativ wenig zu tun hat, und man diese Rechenpower nicht verschwenden will. Und natürlich, weil die gpus enorm viele berechnungen parallel vornehmen können.
Was wir bräuchten, wär eine art LPU
-
Hallo
hab mich jetzt dafür entschieden ein Klassendesign zu verwenden um auf die DirectX Funktionen etc. zuzugreifen.
Jetzt stehe ich aber vor dem Problem der Performance.
Wie hier schon gesagt wurde, scheint der Performanceunterschied zwischen prozeduraler und objektorientierter Programmierung heutzutage nicht mehr all zu groß zu sein.
Jetzt überlege ich aber, ob ich die Mittel der STL, besonders vectoren, verwenden soll oder lieber auf C Arrays zurückgreifen soll. Wie groß schätzt ihr die Geschwindigkeitsunterschiede hierbei ein?
Bin nämlich momentan dabei, eine Klasse für die Palette zu schreiben und benötige dazu entweder ein Array für die einzelnen Einträge oder einen vector.
Oder gibt es anstelle eines vectors noch einen anderen Container, der schneller ist also eher an ein normales Array ankommt?
PS: Wie ich in einem anderen Forum zum Thema Doom3 SDK gelesen habe, wurden dabei anscheinend auch C Arrays und andere C Methoden genauso wie Klassen verwandt (also "C+").
-
ein Vector ist intern ein dynamisches array, wieso sollte er langsamer sein? Am Ende tut er nicht mehr, als du eh schreiben müsstest. Nur mit dem Unterschied, dass er von Fachleuten programmiert wurde, die lange messreihen durchgeführt haben um zu testen, wie der vector wachsen muss, damit er so schnell wie möglich ist.
wenn du was dynamisches brauchst, bist du damit 1000 mal besser beraten als mit der handgeschriebenen Lösung(allein das thema fehelranfälligkeit ist ne sache für sich).wenn du ein statisches array brauchst, dann kannst du das c-array nutzen, alternativ kann man aber auch das "neue" std::tr1::array nutzen, das ist ein c-array mit vector interface.
und vergiss niemals:
premature optimisation is the root of all evil.
-
Hi,
ich grab diesen Thread wieder aus, da ich jetzt in meinem Klassendesign weitergekommen bin.
Allerdings fällt mir jetzt beim Testen auf, dass das selbe Programm mit Klassendesign langsamer läuft als wenn man das ganze nur in einigen Funktionen zusammenfasst. Das mag nicht an den Klassen selbst liegen, sondern eher an dem Overhead der bei meiner Programmierung eingeflossen ist. Auf der anderen Seite sind diese Überprüfungen etc. notwendig, da meine Klassen von der Bittiefe weitestgehend unabhängig sein sollen (sprich man gibt sie nur einmal an und alle anderen Klassen beziehen sich auf diese Angabe)...Nun frage ich mich natürlich, wie ich weitermachen sollte.
Den Verlust an Geschwindigkeit zunächst ausblenden und weiterschreiben und hinterher versuchen, noch was rauszuholen.
Oder lieber jetzt schon das ganze auf das notwendigste begrenzen und versuchen die Geschwindigkeit wieder rauszuholen.
Oder das ganze Klassenkonzept vergessen?
Oder die Geschwindigkeit nicht beachten aber dafür ein ordentliches Klassenkonzept als Grundstein zu haben?Was würdet ihr empfehlen? Denn je komplexer das ganze wird, umso langsamer wird es ja unter Umständen und dann läuft das Spiel hinterher mit 10 fps oder so...
Naja ich hoffe ihr versteht was ich meine...
Danke
-
Definiere "langsamer laufen"!
Also im Grunde bringt ein simples Klassendesign, richtig eingesetzt, keinen bis kaum einen Geschwindigkeitsnachteil. Ich denke eher, dass du vllt einige typische Performancekiller eingebaut hast (Bsp. unnötige Kopierkonstruktor-Aufrufe bei größeren Objekten).Verwendest du dynamische Polymorphie (also in C++ "virtual")? Das kann schonmal Performance kosten ist aber immer noch wesentlich schneller als Type-Switching.
Allerdings glaube ich nicht, dass das alles soviel Performance zieht. Schau dir doch mal Irrlicht an, die haben ein Interface, das mit OpenGL, DirectX, Software-Renderern funktioniert und auf vielen Plattformen läuft. Trotzdem ist die Performance nicht so schlecht und die Dynamik überragend.
Gruß
Don06
-
bevor man einfach kristalkugel perforance analysen macht, sollte an erstmal die verlaesslichen mittel wie z.b. profiler nutzen, denn am ende ist es eher schlechtes programmieren als c++-overhead.
jedenfalls meine erfahrung mit leuten die solche vermutungen dahinwerfen.