spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »dot«

Mir scheint du hast da irgendwo was falsch verstanden. Wieso genau sind die deiner Meinung nach "unnötiger Speicherverbrauch". Abgesehen davon, hab ich generell den Eindruck, dass du dir viel zu viele unnötige Gedanken um den Speicherverbrauch machst. Speicherverbrauch ist sicherlich nicht unwichtig, aber besonders hier vermutlich vollkommen irrelevant. Da sind andere Dinge wesentlich wichtiger für die Performance...

Nicht ganz, ich habe von Anfang an versucht mir eine vernünftige, effektive Art und Weise des Programmierens anzueignen, wenn ich das schon sehe wie groß manche Executables von Computerspielen sind, wird mir schlecht und dann wird auch meistens extrem viel RAM alloktiert, ganz einfach weil z.B. ein paar Leute zu Faul waren darauf zu achten ob sie Variablen benutzen die nur ein Byte groß sind oder ganze vier oder darauf zu achten ob man irgendwo noch Variablen einsparen kann, ohne, dass dies auf Kosten der Rechenzeit geschieht. Irgendwann rechnet sich das natürlich, bei sehr großen Arrays oder einer riesigen Menge von Variablen. Sieh dir mal Programme wie kkrieger an, die arbeiten wirklich effektiv zumindest was Festplattenspeicher angeht und auch wenn das natürlich auf die Rechenzeit schlägt aber es hat großes Potential und es gibt mit Sicherheit ähnliche Einsparungsmöglichkeiten was RAM und Rechenzeit betrifft. Wenn ich könnte würde ich sogar alles in Assembler machen, ich bin in dieser hinsicht eher ein Perfektionist auch wenn mich das Zeit kostet, ich verpöne so einen Stil eben, so wie andere Leute eben vielleicht einen anderen Stil verpönen.

Zitat von »dot«

Ja

	C-/C++-Quelltext
1 2 3 4 5 6 7 8 9	struct blub { int a; float b; }; // ... blub b = { 42, 3.14f };

Oha, das kann ich leider nicht so benutzen, so verschachtelt wie meine Strukturen sind.

Zitat von »dot«

C++ ist wesentlich mehr als "objektorientierter Kram". C++ bietet schon auch allein für prozedurale Programmierung extrem viele Vorteile. Der einzige vernünftige Grund, C zu benutzen, ist, wenn es für eine Zielplattform keinen brauchbaren C++ Compiler gibt...

Zurück zum Thema bitte, ich habe schon am Anfang gesagt, dass ich in diesem Thema keine solche Diskussion hervorrufen möchte. Wenn du trozdem darüber reden möchtest schreibe mir doch eine Nachricht oder eröffne ein Thema dazu.

Möglichst kleine exe-Dateien zu erstellen ist eher eine sportliche Disziplin und in der Realität nur für Virenprogrammierer interessant. Ob deine exe jetzt 20kb hat oder 5mb, macht doch bei heutigen Festplatten überhaupt keinen Unterschied mehr.
Zum Thema kleine Variablen hatten wir hier neulich einen netten Thread. Kurz gesagt ist es wahrscheinlich, dass der Compiler aus Gründen der Zugriffszeit trotzdem alles an 4 Byte ausrichtet und du letztendlich überhaupt nichts sparst. Ich bin eher dafür, robuste und schön strukturierte Programme zu schreiben, anstatt mich an Optimierungen von zweifelhaften Nutzen aufzuhalten.

In C++11 kann man Werte auch direkt zuweisen:
http://en.wikipedia.org/wiki/C%2B%2B11#O…ion_improvement (member initialization Beispiel)

Zitat von »S. P. Gardebiter«

Zitat von »dot«

Mir scheint du hast da irgendwo was falsch verstanden. Wieso genau sind die deiner Meinung nach "unnötiger Speicherverbrauch". Abgesehen davon, hab ich generell den Eindruck, dass du dir viel zu viele unnötige Gedanken um den Speicherverbrauch machst. Speicherverbrauch ist sicherlich nicht unwichtig, aber besonders hier vermutlich vollkommen irrelevant. Da sind andere Dinge wesentlich wichtiger für die Performance...

Nicht ganz, ich habe von Anfang an versucht mir eine vernünftige, effektive Art und Weise des Programmierens anzueignen, wenn ich das schon sehe wie groß manche Executables von Computerspielen sind, wird mir schlecht und dann wird auch meistens extrem viel RAM alloktiert, ganz einfach weil z.B. ein paar Leute zu Faul waren darauf zu achten ob sie Variablen benutzen die nur ein Byte groß sind oder ganze vier oder darauf zu achten ob man irgendwo noch Variablen einsparen kann, ohne, dass dies auf Kosten der Rechenzeit geschieht. Irgendwann rechnet sich das natürlich, bei sehr großen Arrays oder einer riesigen Menge von Variablen. Sieh dir mal Programme wie kkrieger an, die arbeiten wirklich effektiv zumindest was Festplattenspeicher angeht und auch wenn das natürlich auf die Rechenzeit schlägt aber es hat großes Potential und es gibt mit Sicherheit ähnliche Einsparungsmöglichkeiten was RAM und Rechenzeit betrifft. Wenn ich könnte würde ich sogar alles in Assembler machen, ich bin in dieser hinsicht eher ein Perfektionist auch wenn mich das Zeit kostet, ich verpöne so einen Stil eben, so wie andere Leute eben vielleicht einen anderen Stil verpönen.

Die extreme Größe von KKrieger entsteht natürlich durch solches Gefuchse um jedes einzelne Byte, das stimmt. Aber noch wesentlicher entscheider als das sind bei KKrieger prozedurale Texturen etc. Dort wird viel mehr Platz eingespart.

Was Performance allgemein angeht, muss ich aber sagen, es macht mehr Sinn sein Programm möglichst effizient (in Codingzeit) und übersichtlich fehlerfrei hinzuschreiben und sich dann mit einem Profiler anzusehen welche Stellen wirklich Performancekritisch sind und diese dann zu optimieren. Ein etwas überzeichnetes Beispiel: Es macht keinen Sinn auf Teufel komm raus eine Sortierfunktion in Assembler zu entwickeln wenn man dann nur einen Bubblesort hinbekommt, während der C Entwickler in der selben Zeit einen Quicksort implementiert. Der Quicksort in C spielt den Bubblesort in Assembler natürlich locker an die Wand.

Für Programmcode gilt typischerweise die 80-20 Regel: 80% der Zeit werden in 20% des Codes verbracht. D.h. wenn du wirklich 100% deines Codes so programmierst, muss ich dir leider sagen das du eine Menge Zeit verschwendest Code optimal zu halten der sich nachher gar nicht wirklich auf die Performance auswirkt - Zeit die dir bei den wichtigen 20% dann fehlt. Ausser natürlich, du hast ein unendliches Zeitbudget, dann kann es natürlich keine Zeit geben die dir fehlt. Aber sowas hat man selten.

Was std::string angeht. Nun, bei der STL als Bibliothek kommt mir persönlich die Galle hoch. Das da jemand beim ersten Kontakt davonläuft wundert mich nicht. Aber ich würde dann nicht sofort von Objektorientierung abraten, sondern alternative Bibliotheken aufzeigen. Die entsprechenden Datenstrukturen etc. in Qt finde ich sehr viel angenehmer. Und man muss nicht zwingend Qt auch mit GUI benutzen.

Zitat von »Jonathan_Klein«

Möglichst kleine exe-Dateien zu erstellen ist eher eine sportliche Disziplin und in der Realität nur für Virenprogrammierer interessant. Ob deine exe jetzt 20kb hat oder 5mb, macht doch bei heutigen Festplatten überhaupt keinen Unterschied mehr.
Zum Thema kleine Variablen hatten wir hier neulich einen netten Thread. Kurz gesagt ist es wahrscheinlich, dass der Compiler aus Gründen der Zugriffszeit trotzdem alles an 4 Byte ausrichtet und du letztendlich überhaupt nichts sparst. Ich bin eher dafür, robuste und schön strukturierte Programme zu schreiben, anstatt mich an Optimierungen von zweifelhaften Nutzen aufzuhalten.

In C++11 kann man Werte auch direkt zuweisen:
http://en.wikipedia.org/wiki/C%2B%2B11#O…ion_improvement (member initialization Beispiel)

Soweit ich weiß sorgen aber Datentypen wie z.B. int32_t dafür, dass ich wirklich einen signed integer habe der 4 byte groß ist. Ich kann mein Programm immernoch schön strukturieren und robust programmieren, auch wenn ich diese Einsparungen vornehme.
Würden mehr Leute ihre Programme optimieren, müsste man sich nicht alle paar Jahre neue Hardware anschaffen aber natürlich würde die Industrie nichts daran verdienen, immerhin will sie ja, dass wir uns neue kaufen. Deshalb lehne ich sowas allein schon aus ideologischen Gründen ab, weil es für mich äußerst unsauber und aufgrund der Folgen die es nach sich zieht auch eine eher Denkweise ist, die dem Kapitalismus in die Hände spielt.
Und danke für den C++11 Hinweis.

Zitat von »Legend«

Was Performance allgemein angeht, muss ich aber sagen, es macht mehr Sinn sein Programm möglichst effizient (in Codingzeit) und übersichtlich fehlerfrei hinzuschreiben und sich dann mit einem Profiler anzusehen welche Stellen wirklich Performancekritisch sind und diese dann zu optimieren. Ein etwas überzeichnetes Beispiel: Es macht keinen Sinn auf Teufel komm raus eine Sortierfunktion in Assembler zu entwickeln wenn man dann nur einen Bubblesort hinbekommt, während der C Entwickler in der selben Zeit einen Quicksort implementiert. Der Quicksort in C spielt den Bubblesort in Assembler natürlich locker an die Wand.

Für Programmcode gilt typischerweise die 80-20 Regel: 80% der Zeit werden in 20% des Codes verbracht. D.h. wenn du wirklich 100% deines Codes so programmierst, muss ich dir leider sagen das du eine Menge Zeit verschwendest Code optimal zu halten der sich nachher gar nicht wirklich auf die Performance auswirkt - Zeit die dir bei den wichtigen 20% dann fehlt. Ausser natürlich, du hast ein unendliches Zeitbudget, dann kann es natürlich keine Zeit geben die dir fehlt. Aber sowas hat man selten.

Da ich selber nur als Hobby Spiele programmiere, habe ich in der Tat ein unendliches Zeitbudget, daher entfällt dieses Argument auch. Allerdings muss ich sagen, dass der Vergleich nicht wirklich gut ist, immerhin sprach ich hier von Datentypen und lokalen Variablen. Das es mit Assembler nicht wirklich funktioniert, das ist mir klar, immerhin bin ich aber auch da abhängig von Bibliotheken und da dort viel von der Rechenzeit abfällt und es so gut wie garkeine Tutorials oder Hilfen gibt lohnt es sich nicht. Hinzu kommt noch, dass zusammen mit Windows ein äußerst hässlicher Macroassembler entsteht der wesentlich unübersichtlicher ist als konventioneller Assembler oder C/C++.

Edit: Ach übrigens, Compiler sind auch extrem ineffizient, mindestens 1/3 aller Maschinencode Instruktionen die sie produzieren sind unnötig und sinnfrei, darüber habe ich mich mal geärgert als ich eine bestehende exe disassembled habe.

Jep, beim Programmieren als Hobby hat man das unendliche Zeitbudget noch am ehesten, es ist ja nur begrenzt durch die eigene Geduld (und eigene Lebenserwartung). Bei einem Job würde dir das dann aber (zurecht) um die Ohren gehauen werden, denn da musst du irgendwann überhaupt fertig werden und wenn du Zeit hast zum optimieren, dann bekommen die wichtigen Stellen natürlich Priorität. Das heißt aber nicht sofort, dass die Programmierer einfach faul sind! Das war eben schon eine ziemlich böse Unterstellung von dir!

Und was Jonathan meinte: Eine Struct aus zwei Shorts muss nicht unbedingt weniger Platz benutzen als eine Struct aus einem Long und einem Short. CPUs kommen schlecht mit Addressen zurecht die nicht durch vier teilbar sind, deswegen wird der Compiler selbstständig einen kleinen Pufferbereich einschieben, damit der zweite Short auch bei einer durch vier teilbaren Addresse beginnt. Was du dagegen tun kannst? Structure packing auf 1 runterstellen. Dann bricht dir aber die Performance gerade deswegen zusammen.

Zitat von »Legend«

Jep, beim Programmieren als Hobby hat man das unendliche Zeitbudget noch am ehesten, es ist ja nur begrenzt durch die eigene Geduld (und eigene Lebenserwartung). Bei einem Job würde dir das dann aber (zurecht) um die Ohren gehauen werden, denn da musst du irgendwann überhaupt fertig werden und wenn du Zeit hast zum optimieren, dann bekommen die wichtigen Stellen natürlich Priorität. Das heißt aber nicht sofort, dass die Programmierer einfach faul sind! Das war eben schon eine ziemlich böse Unterstellung von dir!

Ich verstehe nicht wie vielleicht wenige Sekunden die man benötigen würde pro Datentyp um einen optimalen Datentyp zu wählen oder lokale Variablen weg zu lassen dazu führen würden, dass einem gleich das Ding um die Ohren gehauen wird. Besonders da ich von Anfang an so vorgehe und das nicht noch nachoptimiere. Ich habe nicht gesagt, dass alle Programierer faul sind aber ich kenne welche die es sind und die es nicht erklären können warum sie keinen optimalen Datentyp wählen, sondern es einfach nicht machen weil "so geht es ja auch", also komm runter.

Zitat von »Legend«

Und was Jonathan meinte: Eine Struct aus zwei Shorts muss nicht unbedingt weniger Platz benutzen als eine Struct aus einem Long und einem Short. CPUs kommen schlecht mit Addressen zurecht die nicht durch vier teilbar sind, deswegen wird der Compiler selbstständig einen kleinen Pufferbereich einschieben, damit der zweite Short auch bei einer durch vier teilbaren Addresse beginnt. Was du dagegen tun kannst? Structure packing auf 1 runterstellen. Dann bricht dir aber die Performance gerade deswegen zusammen.

Dann ist das aber nicht mein Fehler sondern der des Compilers, immerhin könnte man unter einer Adresse die durch vier teilbar ist auch zwei oder mehr Variablen die kleiner sind als Long unterbringen. Oder willst du mir erzählen, dass die paar Modulooperationen und Bitshifts die nötig wären um die Variablen wieder einzellnd in ein Register zu kriegen, die Rechenleistung dermaßen abbremsen? Compiler sind oft sehr ineffizient, wie ich bereits geschrieben habe, 1/3 Maschinencode Instruktionen zuviel ist schon was, das kannst du gleichsetzen mit: "Es ist mehr als 1/3 der Rechenleistung einsparbar.". Es gibt außerdem noch die High und Low Register sowie ein 16-bit Register und soweit ich weiß hat sich an der Architektur seit DOS Zeiten nicht sehr viel getan und da waren, auch noch gegen Ende der DOS Ära die Programme auf optimale Speichernutzung ausgelegt.

Zitat von »S. P. Gardebiter«

Würden mehr Leute ihre Programme optimieren, müsste man sich nicht alle paar Jahre neue Hardware anschaffen aber natürlich würde die Industrie nichts daran verdienen, immerhin will sie ja, dass wir uns neue kaufen.

Das ist schlicht falsch. Spiele und viel der Performance-lastigen Software wird immer so entwickelt, dass sie die aktuell beste Hardware nahezu voll ausnutzen oder sogar selbst dort nicht absolut perfekt (mit "maximalen" FPS - sprich 60) laufen. Warum auch nicht? Jemand mit perfekter Hardware will auch perfekte Ergebnisse. Resultat daraus ist aber, dass alle User mit mittlerer Hardware, die sich Software diese kaufen, feststellen, dass sie nicht das Maximum rausholen können. Also kaufen sie bessere Hardware. Da dies für *alle* User und alle Software-Hersteller gilt, entsteht daraus automatisch ein Kreislauf. Klar, die Hardware-Industrie könnte natürlich sagen: "Nö, wir entwickeln nichts besseres, wir bauen nur noch den alten Quark, kauft den und seid zufrieden.". Aber selbst das ginge nicht, weil man die alte Hardware natürlich oft parallel betreiben kann und damit automatisch wieder ein besseres System selbst erschafft, für welches die Software-Entwicklung dann abzielt und die Hardware-Entwickler nachziehen müssen.
Es ist also kein "Der User muss kaufen, weil die Industrie immer bessere Hardware herstellt", sondern es ist ein Kreislauf, bei welchem *jeder*, sowohl der User, als auch die Entwickler und Hardware-Hersteller stets nachziehen müssen. Es rennt also niemand voraus, sondern alle laufen sich im Kreis hinterher und werden automatisch schneller. Das geht gar nicht anders.
Das würde sich auch nicht ändern, wenn "mehr Leute ihre Programme optimieren" würden. Denn auch dann wäre eine mittelmäßige Hardware einer guten unterlegen und der User wäre damit irgendwann nicht mehr zufrieden und würde umsteigen. Außerdem ist auch mal irgendwo Schluss mit Optimierung. Gerade AAA-Games müssen sehr gut optimiert sein, weil sie sonst oft nicht mal auf mittelmäßiger Hardware überhaupt laufen würden.

Zitat von »S. P. Gardebiter«

wenn ich das schon sehe wie groß manche Executables von Computerspielen sind, wird mir schlecht und dann wird auch meistens extrem viel RAM alloktiert, ganz einfach weil z.B. ein paar Leute zu Faul waren darauf zu achten ob sie Variablen benutzen die nur ein Byte groß sind oder ganze vier oder darauf zu achten ob man irgendwo noch Variablen einsparen kann, ohne, dass dies auf Kosten der Rechenzeit geschieht. Irgendwann rechnet sich das natürlich, bei sehr großen Arrays oder einer riesigen Menge von Variablen. Sieh dir mal Programme wie kkrieger an, die arbeiten wirklich effektiv zumindest was Festplattenspeicher angeht

KKrieger verschwendet haufenweise RAM. Nur mal so nebenbei. Und so schön prozedurale Erstellung von Texturen und Sounds auch ist (nur so wurde es so klein), so lässt sich auf Dauer nicht produktiv Software oder gar Spiele entwickeln, die den Qualitätsansprüchen genügt. Generierte Texturen und Sounds werden nie das sein, was Grafiker oder Tonstudios produzieren können. Weder von der Geschwindigkeit der Herstellung, noch der Qualität.

Zitat von »S. P. Gardebiter«

Dann ist das aber nicht mein Fehler sondern der des Compilers, immerhin könnte man unter einer Adresse die durch vier teilbar ist auch zwei oder mehr Variablen die kleiner sind als Long unterbringen. Oder willst du mir erzählen, dass die paar Modulooperationen und Bitshifts die nötig wären um die Variablen wieder einzellnd in ein Register zu kriegen, die Rechenleistung dermaßen abbremsen?

Ja. Weil die Adresse nicht durch 4 teilbar ist, wird das Laden der Daten schonmal langsamer, z.B. Caching spielt hier rein. Wenn Du dann noch anfängst und aus jedem Laden einer Variable nicht 2 Takte, sondern 8 zu machen... ja nee, is sicher schneller. Pipelining kannste hier dann auch komplett in die Tonne treten, Du musst die Daten ja seriell aufbereiten. Das kann gar nicht schneller sein als mit Alignment. Nie im Leben.

Zitat von »S. P. Gardebiter«

Compiler sind oft sehr ineffizient, wie ich bereits geschrieben habe, 1/3 Maschinencode Instruktionen zuviel ist schon was, das kannst du gleichsetzen mit: "Es ist mehr als 1/3 der Rechenleistung einsparbar.". Es gibt außerdem noch die High und Low Register sowie ein 16-bit Register und soweit ich weiß hat sich an der Architektur seit DOS Zeiten nicht sehr viel getan und da waren, auch noch gegen Ende der DOS Ära die Programme auf optimale Speichernutzung ausgelegt.

Falsch. Mehr Code heißt nicht weniger Effizienz. Manchmal ist genau das Gegenteil der Fall. Wichtig sind hier Stichworte wie "Pipelining" und "Taktzeiten". Das kennt der Compiler prima, Du aber nicht. Nie im Leben wirst Du heute noch mit eigenem ASM-Code den VC-Compiler schlagen, wenn ihr beide die selbe Aufgabe vorgesetzt bekommt. Auf keinen Fall. Das galt früher mal, zu Pascal-Zeiten, aber heute nicht mehr. Ich zweifle sogar an, dass Du auch nur ansatzweise die heutigen Register alle kennst. AH und AL... man, das ist 15 Jahre her... Und da hat sich in der Architektur aber SEHR viel getan!

Mal ganz davon abgesehen, vielleicht 2MB an Verwaltungsdaten im RAM einzusparen bringt genau was, wenn man Sounds und Texturen verwendet, die mehrere hundert MB groß sind? Genau, gar nichts außer Performance-Verlust durch fehlendes Alignment.


PS: Ich habe bis in MMX2-Zeiten hinein sehr viel mit Assembler entwickelt, ich weiß also, worüber ich hier rede!

Zum ersten: Wenn ich in einem Bewerbungsgespräch hören würde das jemand für allen Code so vorgeht, würde ich ihn Fragen wie gut er es schafft Release Termine einzuhalten. Besonders das du pauschal für allen Code von Anfang so vorgehst lässt bei mir in dem Punkt Entwicklungstempo die Alarmglocken schrillen. Weil man typischerweise nicht die Zeit dafür hat. Und dann sollte der Entwickler abwägen können wo man die Zeit sinnvollerweise reinsteckt und sich dann um diese Stellen kümmern. Nachdem das ganze überhaupt mal läuft vorm Releasetag läuft, denn das ist natürlich Prio 1.

Zitat von »S. P. Gardebiter«

Zitat von »Legend«

Und was Jonathan meinte: Eine Struct aus zwei Shorts muss nicht unbedingt weniger Platz benutzen als eine Struct aus einem Long und einem Short. CPUs kommen schlecht mit Addressen zurecht die nicht durch vier teilbar sind, deswegen wird der Compiler selbstständig einen kleinen Pufferbereich einschieben, damit der zweite Short auch bei einer durch vier teilbaren Addresse beginnt. Was du dagegen tun kannst? Structure packing auf 1 runterstellen. Dann bricht dir aber die Performance gerade deswegen zusammen.

Dann ist das aber nicht mein Fehler sondern der des Compilers, immerhin könnte man unter einer Adresse die durch vier teilbar ist auch zwei oder mehr Variablen die kleiner sind als Long unterbringen. Oder willst du mir erzählen, dass die paar Modulooperationen und Bitshifts die nötig wären um die Variablen wieder einzellnd in ein Register zu kriegen, die Rechenleistung dermaßen abbremsen? Compiler sind oft sehr ineffizient, wie ich bereits geschrieben habe, 1/3 Maschinencode Instruktionen zuviel ist schon was, das kannst du gleichsetzen mit: "Es ist mehr als 1/3 der Rechenleistung einsparbar.". Es gibt außerdem noch die High und Low Register sowie ein 16-bit Register und soweit ich weiß hat sich an der Architektur seit DOS Zeiten nicht sehr viel getan und da waren, auch noch gegen Ende der DOS Ära die Programme auf optimale Speichernutzung ausgelegt.

Der Compiler wird das mit den Shifts oder der Benutzung von AH und AL machen, wenn du ihn mit einem Packing von 1 dazu zwingst. Wobei AL und AH nur mit chars ginge. Bei Shorts kommst du nur an den unteren Short über AX schnell ran. Den oberen Teil musst du dir aus EAX rausshiften.

Und in der Tat ja, das Shiften wird die Performance mehr behindern als der Speichermehrverbrauch, ausser deine Performance ist wirklich ganz krass memory bound! Aber das sollte man nicht als Schuss ins blaue annehmen von daher ist das kein Fehler des Compilers sondern eine Performanceoptimierung die der Compiler für dich durchführt!

Und Performance in der Zahl der Instruktionen messen zu wollen ist sehr gefährlich. Nicht alle Instruktionen benötigen die selbe Anzahl an Taktzyklen.

Und die optimale Speicherausnutzung gegen Ende der DOS Ära hat noch einen anderen Grund gehabt, der sich in der Tat erledigt hat: RAM war knapp und teuer. Da mag man zwar von halten was man will, aber der Punkt hat sich mittlerweile erledigt. Man sollte nur nicht mit dem Speicher so asen, dass das Interface CPU <-> RAM zum Bottleneck wird. Und da ist der erste und einfachste Punkt: Das Alignment beachten, damit die CPU effizient aus dem RAM laden kann.