OOP oder Prozedural?
-
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.
-
Hi,
wie gesagt, ich denke auch nicht, dass es an den Klassen selbst liegt, sondern eher daran, was ich noch zusätzlich gecodet habe. Vielleicht wird es an einem Beispiel deutlicher (an dem ich auch es auch getestet habe):
In meinem Buch wird ein einfacher Pixelplot (1000 Pixel pro Frame) ungefähr so durchgeführt:
Globale Variablen, Defines und in der while Schleife meines Programmes wird einmal gelockt, dann direkt auf die Surfacedaten zugegriffen und die Farbe zufällig gesetzt, dann wieder unlocked.
Mit meinem Klassendesign läuft es ungefähr so:
Beim Start des Programms Objekte erstellt, die die DirectX Objekte kapseln, dabei verschiedene Parameter gesetzt wie z.B. Bittiefe, in der while Schleife wird dann die Lockmethode meiner Klasse aufgerufen, die Methode zum Plotten und dann die Unlockmethode.
Im Endeffekt also das gleiche. Aber in meinen Methoden ist nun Overhead drin (Überprüfungen auf Bittiefe, auch virtuelle Methoden werden verwendet, etc.). Und genau diese Codestücke machen das Programm langsamer. Allerdings macht das ganze ohne sie keinen Sinn.
Es ist schwer das ganze zu beschreiben.
Aber vielleicht könnt ihr was zum Thema Profiler posten (gibts sowas kostenlos, was ist damit möglich etc.) oder ihr kennt Tutorials, in denen DirectX mit Klassen durchgearbeitet wird (es sollte aber zunächst DirectDraw verwendet werden, da sich mein Buch auch zunächst darauf bezieht).
Also zusammengefasst: meine Klassen machen nichts anderes als der Code im Buch, nur mit mehr Überprüfungen etc., da ich das ganze unabhängig von globalen Variablen und Defines machen will...
-
Ein Hinweis, was fuer einen Compiler du einsetzt, waer hilfreich um zu wissen was fuer ein Profiler du brauchst. Was ein Profiler macht, wird hier erklaert: http://de.wikipedia.org/wiki/Profiler_(Programmierung) (Grob gesagt: ein Profiler sagt dir, WO in deinem Programm die meiste Zeit verbraucht wird).
Wie Don06 schon gesagt hat, solltest du erstmal erklaeren, was du mit "langsamer laufen" meinst. Wenn du damit 1150 fps statt 1200 fps meinst: komplett vernachlaessigbar. Also: was meinst du mit "langsamer"?
Uhne da meine Glaskugel in letzter Zeit relativ trueb ist, kann ich dir leider nicht sagen, warum dein Programm so viel langsamer ist, ohne den Quellcode zu sehen (aber bitte poste nur die relevanten Teile, niemand wird sich hier durch Zig Zeilen Quellcode wuehlen). Nur eine Bemerkung nebenbei: Warum lockst du die Zeichenflaeche in der While-Schleife und nicht ausserhalb?
-
Mhh ok.
Also als Compiler nutze ich Visual C++ 2005 Express Edition.
Langsamer laufen ist bis jetzt nur ein Gefühl. Ich muss erst noch einen "Framemesser" einbauen, dann kann ich genauer sagen, wieviel langsamer es läuft.
Und zum Quelltext: kann ich gerne posten aber ich weiß im Moment noch nicht welche Stellen wirklich relevant sind und das ganze langsamer machen. Bzw. wenn ich was poste, könnte es schon länger werden...
Und zum Locken: Ich locke ja nur einmal, wenn ich die Pixel plotten will. Sprich lock, dann die Pixelplots, dann wieder unlock. Das sollte schon so passen.
Nun gut ich gucke mal was ich an relevantem Code posten könnte...
-
Cpp_Junky schrieb:
Welches Spiel soll denn heute CPU limitiert sein?
Speicher ja, aber CPU? Naja ich weiss nich...Nur noch die besten. Zum Beispiel wo ich mitarbeite. f'`8k
Gruß, TGGC (making great games since 1992)
-
Hi,
also hab mich heute mal dranbegeben und einen Framezähler in mein Programm mit Klassen und in das Originalprogramm eingebaut. Beide machen im Endeffekt das selbe, das Original ist nur viel kürzer und arbeitet ohne Klassen. Es greift im Endeffekt in der while Schleife in WinMain direkt auf die Surfacedaten zu und zwar über globale Variablen. Ich hab das ganze halt mit Klassen gemacht und viele Überprüfungen und Overhead dazugepackt, der die Verwendung der Klassen aber erheblich leichter macht.
Naja jetzt die Ergebnisse:
Originalprogramm: um die 6000 fps.
Mein Programm: um die 130 fps.
Macht es bei einem solchen Unterschied überhaupt Sinn, ein Klassenkonstrukt zu basteln um DirectX leichter und einfacher zu bedienen. Und wie macht das z.B. die Irrlichtengine?
Vielleicht habt ihr ja ein Tutorial oder so wo DirectX mit Klassen programmiert wird.
Ansonsten kann ich auch gerne Code posten damit ihr seht was ich an Overhead drin hab.EDIT:
Ein Nachtrag: Hab jetzt mal den Code aus dem Originalprogramm genommen und in meine while Schleife gesetzt. Habe nur zwei Zugriffe in der while Schleife über die Klassen und zwar um den Surfacepointer zu bekommen und ein Zugriff auf die Klasse des Framezählers.
Ergebnis: 3000 fps.
Kann es wirklich sein, dass zwei Zugriffe auf Methoden die Framezahl halbieren?
-
Hm,
ich schreib mal was ich gebastelt hab:
-eigene Exceptionklasse
-Mainklasse, kapselt DIRECTDRAW7 Objekt, erstellt es im Konstruktor und bietet Zugriff darauf etc.
-Palettenklasse, kapselt DIRECTDRAWPALETTE Objekt, PALETTEENTRIES werden in vector gespeichert und dann eingesetzt, Zugriffe, Veränderungen der Palette etc. über Methoden
-Surfaceklasse, Basisklasse für alle Surfaces, es können keine Objekte erstellt werden, da ich den Konstruktor protected gesetzt habe, kapselt DIRECTDRAWSURFACE7 Objekt sowie DDSURFACEDESC2, den Memorypitch und die Surfacedaten nach einem Lock, Lock, Unlock sowie Pixelplot über Methoden, Methoden alle als virtual deklariert
-PrimarySurfaceklasse, abgeleitet von Surfaceklasse, übernimmt alle Methoden, aber bietet die zusätzliche Möglichkeit, eine Palette einzusetzen.
-Colorklasse, speichert 8,16,24 oder 32 Bit Farbcode als ganzes sowie als R,G,B getrenntnoch folgen soll eigentlich: Doublebuffering, Colorkeying, Clipping, Offscreensurfaceklasse für Sprites, Bitmaps etc. und dazu natürlich dann Spriteklasse, Bitmapklasse etc.
So hatte ich mir den Aufbau überlegt. Für ein Spiel wollte ich dann eine Klassenstruktur oben drauf setzen. Playerklasse, Spielfeldklasse etc. je nachdem was ich für ein Spiel machen will.
Aber wenn das ganze jetzt so viel Ressourcen verbraucht (FPS siehe voriger Post), dann frage ich mich ob das überhaupt so viel Sinn macht (bzw. ob man das überhaupt so machen sollte mit den Klassen um die DirectX Objekte). Oder ob man direkt Playerklassen und so schreibt und in denen dann die Zugriffe auf die DirectXkomponenten koordiniert.
Hoffe ihr versteht jetzt mein Problem. Falls ihr noch Code sehen wollt, sagt Bescheid, dann poste ich was (ist aber dann etwas länger)...
