OOP oder Prozedural?
-
wie schnell es laeuft haengt bei c/c++ von den faehigkeiten des programmieres ab.
btw. wenn jemand streams oder fopen benutzt, hat er eh nicht mit geschwindigkeit am hut.
-
Die grosse Optimierungs-Arbeit fällt heute mehr bei der Grafik an, also Sichtbarkeitstest, optimale Nutzung von Hardware-Features usw. Früher wurden die Engines so zusammengepackt das sie gerade so eben "3D Grafik" darstellen konnten, in dem Umfang das eine 486er CPU ohne Hardware-Beschleunigung das auf die Reihe kriegt (Siehe die ersten 3D Engines, auch "2.5D" Engines genannt - Doom1+2, Build Engine usw). Da durfte natürlich keine Leistung verschenkt werden, damit dieses Konstrukt auf den altertümlichen Dingern auch flüssig lief. Aber heute... Lass doch mal einen Profiler laufen und guck dir an, welche Rechenzeit das Zeug frisst, was nichts mit Grafik am Hut hat
-
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