spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Der "Overhead" von C++ ist nur vorhanden, wenn mans falsch macht. Das war das ja was dot gemeint hat. Wenn man C++ gut beherrscht, dann bekommt man damit genau so performanten Code hin wie wenn man C beherrscht.

Genau das ist was kontrovers diskutiert wird ob C++ wirklich schneller als C ist, das was ich gelesen habe, spricht eher dagegen als dafür. Zumindest ist einfacher mit C++ ineffizienten Code zu produzieren, ein Grund warum ich darauf verzichte alles unbedingt mit typischen C++ Elementen lösen zu wollen. Es gibt da im Internet ein haufen Foren, Blogs, Seiten etc. die sich damit beschäftigen.

Hallo

ich habe mich mal durch den thread hier gequält.

zum einen sprichst du (S. P. Gardebiter) den energieverbrauch an. auf der einen seite frisst heutige hardware weniger als noch vor 10 jahren und zum anderen würdest du den stromverbrauch auch in die höhe treiben, um ein möglichst effizientes Programm rauszubekommen. Oder optimirst du ohne pc?

zum anderen warum nutzt du nicht assembler wenn du so ein geschwindigkeitfetischist bist? soweit ich weis ist es schneller als C/c++

MfG
Sr

ich suchte mal nach dem Artikel und dem Code von diesem C vs C++ test und angeblich soll es der hier sein: http://people.redhat.com/bkoz/benchmarks…/oopack_v1p8.cc
Ich glaube jeder kann sich jetzt ganz schnell ein Bild davon machen, warum C ach soviel besser ist (schonmal Autos verglichen wobei bei dem einen der Innenraum mit Pflastersteinen befüllt war?) .
Ein Vergleich zwischen "manuellen" ASM und Compiler fände ich schon ganz interessant. Wie wär es z.B. für eine Fakultätsberechnung? Das ist recht einfach, wenn auch weit von der Realität und ihren Unwegsamkeiten entfernt.
P.S: ein Musterbeispiel (und erster Treffer bei google) für einen falschen Alarm in Sachen "compiler überflüssige instruktionen" und sehr "kluger" manueller Optimierung http://www.mikrocontroller.net/topic/251475 (Spoiler für lesefaule: Variablentyp war ungünstig gewählt).

Zitat von »S. P. Gardebiter«

mov edx, [ebp+0008]
mov eax, [edx+0078]
add eax, 01
mov ecx, [ebp+0008]
mov [ecx+0078], eax
mov edx, [ebp+0008]
cmp dword ptr [edx+0078], 08

Nie im Leben ist das von VC++ oder g++ oder gcc ausgespuckter und optimierter Code. Das ist höchstens Debug-Code ohne jedwede Optimierung. Oder da weiß jemand nicht, wie er die Flags des Compilers richtig setzen muss. Sorry, aber ich habe noch nie solchen Unfug von VC++ generiert gesehen. Es würde nämlich nichtmal die beiden Befehle
mov eax, [edx+0078]
add eax, 01
nacheinander schreiben, weil das Pipeline-Stalls verursachen würde. Sorry, aber dieses Beispiel kaufe ich Dir nicht ab.


OOP vs Prozedural:
Ja, man *kann* definitiv OOP-Varianten wesentlich langsamer schreiben, als Prozedurale. Es geht genauso aber auch andersrum. Wenn ich diese Unfugsbehauptung also beweisen *will*, dann geht das natürlich.
Gerade bei Verarbeitung tausender Daten in Matrizen brauch ich mich nicht wundern, dass eine Array-Variante mit perfektem Cache-Verhalten besser ist als eine im RAM zerhackstückte Verteilung der Daten. Das ist aber kein Problem von OOP, sondern von falscher Verwendung von OOP zum Missbrauch eines fehlerhaften Beweises. In diesem Fall gilt wohl eher "quo errat demonstrator" statt "quod erat demonstrandum".

Ich kann mich BlueCobold da nur anschließen. Ist dieser Code zufälligerweise beim Debuggen mit Visual Studio in der Disassembly-Ansicht hochgekommen? Im Debug-Build wundert der Code mich nicht. Das aber auch aus gutem Grund, mit Optimierungen kann man kaum noch vernünftig Debuggen.

Zitat von »dot«

Ich kann dir nur empfehlen, dich mal vorurteilsfrei und wirklich ernsthaft mit C++ zu beschäftigen, anstatt einfach irgendwelche Meinungen aus irgendwelchen Foren oder Blogs anzunehmen, ohne jemals selbst wirklich gesehen zu haben, wozu die Sprache fähig ist. In ein paar Jahren wirst du die Sache dann vermutlich anders sehen, wenn du es zulässt...

Ich weiß wie objektorientierte Programmierung funktioniert, ich habe selber schon mit ihr gearbeitet, ich glaube nicht, dass da C++ eine große Ausnahme darstellt. Das habe ich aber auch schon mehrmals gesagt. Klassen haben oft mehr als einen Konstruktor und sie haben auch einen Destruktor, meistens werden Klassen mit private Variablen erstellt und diese dann über Funktionen eingelesen oder überschrieben, hinzu kommt noch, dass sie auf einem Heap gespeichert werden. Letztendlich sitzen wir dann da mit bei weitem mehr Funktionsaufrufen und einem Heap, der in der Regel langsamer arbeitet als ein Stack. Warum sollte ich also als einzellner Programmierer, obwohl es mir doch überhaupt keine Zeit spart in den meisten fällen auf globale Variablen für ein kleines bis mittelgroßes Spiel ohne 3D Graphik verzichten und stattdessen Klassen benutzen obwohl sie mir in den meisten Fällen überhaupt nichts bringen und wahrscheinlich sogar langsamer sind? Stell dir mal vor ich habe ein Structarray mit 10000 Elementen, jetzt sage mir, was ist schneller wenn ich einige Variablen aller 10000 Elemente gleich auf einen bestimmten Wert setze oder wenn erst noch 10000 Funktionsaufrufe gemacht werden müssen? Noch dazu ist es mehr Code den ich in diesem Fall schreiben müsste, mit einer größeren Gefahr, dass ich mir selber irgendwann in die Füße schieße. Für GUIs und große Projekte mag das alles ganz nett sein aber ich brauche es zu einem großen Teil nicht.

Natürlich ist das auch alles noch eine Frage des Programmierstils aber ich wurde gefragt warum ich nicht Klassen anstatt Structs nehme, ich könnte natürlich auch alle Structs in Klassen umwandeln mit ausschließlich public Variablen. Das bringt mir aber garnichts, mein Code wird sogar länger weil ich voher noch Konstruktoren benutzen muss und am Ende Dekonstruktoren und er wird auch langsamer.

Zitat von »dot«

Ein paar Bücher, die ich dazu sehr empfehlen kann, wären:

The C++ Programming Language
Effective C++
Modern C++ Design

Ich werd die mir mal angucken, falls ich mich nochmal genauer mit dem Kram beschäftigen muss, was ich sicher werde, wenn ich ein Problem finde, welches hervorragend geeignet ist mit Klassen gelöst zu werden.

Zitat von »sr-programmierung«

zum einen sprichst du (S. P. Gardebiter) den energieverbrauch an. auf der einen seite frisst heutige hardware weniger als noch vor 10 jahren und zum anderen würdest du den stromverbrauch auch in die höhe treiben, um ein möglichst effizientes Programm rauszubekommen. Oder optimirst du ohne pc?

Dass neue Hardware weniger frisst, halte ich für ein Gerücht, mein PC hat ein 450 Watt Netzteil, ich hatte mal einen alten 133er, der hatte glaub ich ein 100 Watt Netzteil, kann auch sein, dass es 50 oder 100 mehr waren. Aufjedenfall ist das Blödsinn, alte Desktop PCs hatten einen viel geringen Verbrauch als neue. Richtig ist aber auch, dass die Technologie immer besser wird und richtig moderne PCs sich den alten auch hin und wieder mal annäheren.

Bei dieser Logik, gibt es auch ein Gegenargument, es wird wahrscheinlich wesentlich mehr Leute geben, die das Programm benutzen als die, die es entwickeln.
Außerdem ging es bei der Stromgeschichte immernoch um ein bestimmtes Zitat, nämlich um das hier: "Wo Leistung im Überfluss ist, kann man keine Verschwenden.", habe ich in diesem Thread aber auch schonmal geschrieben.

Zitat von »sr-programmierung«

zum anderen warum nutzt du nicht assembler wenn du so ein geschwindigkeitfetischist bist? soweit ich weis ist es schneller als C/c++

Ja, das ist es in der Regel auch, wenn man etwas Ahnung hat. Allerdings ist der Aufwand äußerst groß und mit Microsoft kann man nur diesen hässlichen Macroassembler benutzen, der absolut eklige Syntax hat. Noch dazu gibt es keine Tutorials, habe ich aber in diesem Thread auch schon geschrieben.

Zitat von »LetsGo«

Es steht dir natürlich frei welche Sprache du verwendest, jede hat seine Vor und Nachteile und ist je nach Anwendung sinnvoller.
Bei zunehmend größeren Projekten hat es Vorteile sich an OO Sprachen mit großen Bibliotheken zu halten, da die Algorithmen nach mathematischen Regeln optimiert werden, soetwas bekommt man als Hobbyprogrammierer nicht hin. Zudem ist es übersichtlicher und die Optimierungstools sind mächtig. Dass irgendwelche Kleinigkeiten dabei auf Grund der Abstraktion auch mal mehr Resourcen fressen mag sein, fällt aber immer weniger ins Gewicht. Dazu hat man noch den Vorteil, dass Änderungen im Nachhinein leichter fallen.

Dass es bei zunehmend größeren Projekten oft Vorteile mit sich bringt, da habe ich nie in Abrede gestellt, allerdings gibt es auch für prozedurale Sprachen genug Bibliotheken die mithalten können. Soweit ich weiß ist OpenGL z.B. komplett in C geschrieben.

Zitat von »LetsGo«

Das Argument vom Strom sparen ist beim PC irrelevant (1/3 mehr Befehle sind unrealistisch). Das mag bei einzelnen Methoden vllt passiern aber ist sicher nicht die Regel (Virtuelle Funktionen wären ein gutes Bsp).

nochmal, beim Strom ging es um folgendes Zitat: "Wo Leistung im Überfluss ist, kann man keine Verschwenden.", ich wiederhole mich langsam, weil ihr euch meine Postings nicht genau durchlest.
Es ging mir allgemein um Resourcenverschwendung, die de facto da ist. Wenn du mir das mit den 1/3 mehr Befehle nicht glaubst, steht es dir frei das entsprechende Programm selber zu disassemblieren und selbst zu sehen.

Zitat von »LetsGo«

Der von dir erwähnte Speicherplatz für Zeiger wird zusätzlich gebraucht ja, aber nur während der Gültigkeit und vorallem ist der Speicherplatzbedarf so gering, dass man es gar nicht in Worte ausdrücken kann. (32 oder 64 bit). Vorallem ist doch Zeigerarithmetik wirklich das, was C so effizient macht (Und auch Assembler). Es werden eben keine temporären lokalen Kopien im Stack abglegt, dafür hat man eben eine große Fehleranfälligkeit, wenn man mal was verpeilt.

Ja, das ist richtig aber mit Zeigern zu arbeiten ist eben Fehleranfälliger und macht es auch nicht unbedingt einfacher. In der Regel setzt der Compiler dies aber auch von selber um, denn oft wird einfach nur der Basepointer verwendet, zumindest in dem Programm was ich mir damals angesehen habe. Du vergisst allerdings, dass Zeiger wesentlich sinnvoller sind wenn es um einen dynamischen Speicher geht, bei einem statischen Speicher kommt man in der Regel auch ohne Zeiger aus.

Zitat von »LetsGo«

An den Unis, HS in Firmen überall wird gepredigt: Vermeide globale Variabeln, nutze moderne Paradigmen (OO) usw. Warum? Weil es um Zeit und Geld geht.

Weil Unis die Leute darauf vorbereiten sollen, wie in Unternehmen gearbeitet wird. Das Unternehmen objektorientierte Programmierung bevorzugen liegt ganz klar daran, dass in größeren Projekten gearbeitet wird und man so Leuten einfacher ihr Feld zuweisen kann, in dem sie tätig sind und Programmieren. Bei einem großen Team wird das Programm so schneller fertig gestellt.

Zitat von »LetsGo«

Du hast was bei dem Wiki Zitat weggelassen um dein Argument zu untermauern, ist aber wichtig:

Nicht ganz, ich habe das mit den mobilen Geräten weggelassen und das derartige Aglorithmen auf solchen Geräten nur einen Bruchteil ausmachen, denn ich rede momentan von einem PC, nicht von einem Mobilgerät.

Zitat von »LetsGo«

Übrigends: Ich bin heute schon ein wenig genervt, falls ich etwas zu direkt ausgedrückt haben sollte im Post davor, sry. Und ich hab alles gelesen, zumindest überflogen.

Es ging mir nicht um die direkt Ausdrucksweise, sondern darum, dass mir vorgewurfen wurde, ich habe nach Tipps gefragt und nun würde ich diese nicht annehmen, das habe ich aber nicht und ich würde hier diskutieren unzwar am Thema vorbei und das obwohl ich die Diskussion nicht angefangen habe. Darum ging es mir.

Zitat von »Nox«

ich suchte mal nach dem Artikel und dem Code von diesem C vs C++ test und angeblich soll es der hier sein: http://people.redhat.com/bkoz/benchmarks…/oopack_v1p8.cc
Ich glaube jeder kann sich jetzt ganz schnell ein Bild davon machen, warum C ach soviel besser ist (schonmal Autos verglichen wobei bei dem einen der Innenraum mit Pflastersteinen befüllt war?) .

Das ist nicht der, das ganze war in einem Buch von einem gewissen Alexander Chatzigeorgiou und das Buch hieß "Performance and power evaluation of C++ object-oriented programming in embedded processors.", Seite 195-201.

Zitat von »Nox«

P.S: ein Musterbeispiel (und erster Treffer bei google) für einen falschen Alarm in Sachen "compiler überflüssige instruktionen" und sehr "kluger" manueller Optimierung http://www.mikrocontroller.net/topic/251475 (Spoiler für lesefaule: Variablentyp war ungünstig gewählt).

Mag sein, dass es auch solche gibt, ich redete hier aber von einem sehr großen Programm, nicht von einem kleinen Mikrocontroller Programm.

Zitat von »BlueCobold«

Nie im Leben ist das von VC++ oder g++ oder gcc ausgespuckter und optimierter Code. Das ist höchstens Debug-Code ohne jedwede Optimierung. Oder da weiß jemand nicht, wie er die Flags des Compilers richtig setzen muss. Sorry, aber ich habe noch nie solchen Unfug von VC++ generiert gesehen. Es würde nämlich nichtmal die beiden Befehle
mov eax, [edx+0078]
add eax, 01
nacheinander schreiben, weil das Pipeline-Stalls verursachen würde. Sorry, aber dieses Beispiel kaufe ich Dir nicht ab.

Dekompilier es selber, ansonsten kann ich dir auch nicht weiterhelfen, ich kann hier auch jedem X-Beliebigen unterstellen er würde lügen.
Hinzu kommt noch, dass der Kerl erstens mehr als 5 Jahre an dem Ding gearbeitet hat und voher schon mindstens 3 bis 4 Jahre programmiert hat unzwar mit C++, da willst du mir doch nicht erzählen, er weiß nicht wie man Compilerflags setzt oder?
Noch dazu befindet sich in der exe folgender String: "Microsoft Visual C++ Runtime Library" und wenn du mir nicht glauben willst dann guck doch selber nach.

Zitat von »BlueCobold«

Ja, man *kann* definitiv OOP-Varianten wesentlich langsamer schreiben, als Prozedurale. Es geht genauso aber auch andersrum. Wenn ich diese Unfugsbehauptung also beweisen *will*, dann geht das natürlich.
Gerade bei Verarbeitung tausender Daten in Matrizen brauch ich mich nicht wundern, dass eine Array-Variante mit perfektem Cache-Verhalten besser ist als eine im RAM zerhackstückte Verteilung der Daten. Das ist aber kein Problem von OOP, sondern von falscher Verwendung von OOP zum Missbrauch eines fehlerhaften Beweises. In diesem Fall gilt wohl eher "quo errat demonstrator" statt "quod erat demonstrandum".

Natürlich gibts genug Beispiele wo objektorientierter Code Sachen kann, die prozeduraler Code nicht kann oder er schneller ist. Ich wurde aber darauf z.B. hingewiesen warum ich nicht Klassen anstatt Structs benutze, das empfinde ich als ineffektiv und oft brauch man den objekt orientierten Ansatz garnicht und kommt mit dem prozeduralen entweder mindstens genauso gut aus oder er ist sogar schneller. (Auch beim Code schreiben) Ich versteh nur nicht warum man überall immer OOP verwenden will und alles damit lösen will, es jedem aufzwingen will es möglichst oft zu verwenden, auch da wo es absolut garnicht unnötig ist, alles verkompiliziert und eventuell auch langsamer läuft, deshalb verwende ich es sparsam und da wo ich meine, dass es sinnvoll ist.

Zitat von »Legend«

Ich kann mich BlueCobold da nur anschließen. Ist dieser Code zufälligerweise beim Debuggen mit Visual Studio in der Disassembly-Ansicht hochgekommen? Im Debug-Build wundert der Code mich nicht. Das aber auch aus gutem Grund, mit Optimierungen kann man kaum noch vernünftig Debuggen.

Ist zwar nicht komplett auszuschließen, halte ich aber zu 99% für unwahrscheinlich. Ich werde mal sehen ob ich das irgendwie in Erfahrung bringen kann und werde evtl. mal selber Programme von mir disassemblieren und gucken.

Zitat von »S. P. Gardebiter«

Zitat von »sr-programmierung«

zum einen sprichst du (S. P. Gardebiter) den energieverbrauch an. auf der einen seite frisst heutige hardware weniger als noch vor 10 jahren und zum anderen würdest du den stromverbrauch auch in die höhe treiben, um ein möglichst effizientes Programm rauszubekommen. Oder optimirst du ohne pc?

Dass neue Hardware weniger frisst, halte ich für ein Gerücht, mein PC hat ein 450 Watt Netzteil, ich hatte mal einen alten 133er, der hatte glaub ich ein 100 Watt Netzteil, kann auch sein, dass es 50 oder 100 mehr waren. Aufjedenfall ist das Blödsinn, alte Desktop PCs hatten einen viel geringen Verbrauch als neue. Richtig ist aber auch, dass die Technologie immer besser wird und richtig moderne PCs sich den alten auch hin und wieder mal annäheren.

Bei dieser Logik, gibt es auch ein Gegenargument, es wird wahrscheinlich wesentlich mehr Leute geben, die das Programm benutzen als die, die es entwickeln.
Außerdem ging es bei der Stromgeschichte immernoch um ein bestimmtes Zitat, nämlich um das hier: "Wo Leistung im Überfluss ist, kann man keine Verschwenden.", habe ich in diesem Thread aber auch schonmal geschrieben.

die eigentliche Aussage sollte aber sein:
neue Hardware verbraucht weniger Strom, als alte Hardware mit gleicher Leistung
der alte Intel Pentium III in meinem alten Rechner hätte zwar was die Leistungsaufnahme angeht eventuell in einem Mobilgerät verbaut werden können, allerdings hätte er eine weit geringere Rechenleistung erbracht
außerdem kommt es bei der Leistungsaufnahme eines Prozessors meines Wissens auch auf den Fertigungsprozess an (30 nm, 22 nm, ...), welcher stetig weiterentwickelt wird

Zitat von »S. P. Gardebiter«

Zitat von »LetsGo«

Es steht dir natürlich frei welche Sprache du verwendest, jede hat seine Vor und Nachteile und ist je nach Anwendung sinnvoller.
Bei zunehmend größeren Projekten hat es Vorteile sich an OO Sprachen mit großen Bibliotheken zu halten, da die Algorithmen nach mathematischen Regeln optimiert werden, soetwas bekommt man als Hobbyprogrammierer nicht hin. Zudem ist es übersichtlicher und die Optimierungstools sind mächtig. Dass irgendwelche Kleinigkeiten dabei auf Grund der Abstraktion auch mal mehr Resourcen fressen mag sein, fällt aber immer weniger ins Gewicht. Dazu hat man noch den Vorteil, dass Änderungen im Nachhinein leichter fallen.

Dass es bei zunehmend größeren Projekten oft Vorteile mit sich bringt, da habe ich nie in Abrede gestellt, allerdings gibt es auch für prozedurale Sprachen genug Bibliotheken die mithalten können. Soweit ich weiß ist OpenGL z.B. komplett in C geschrieben.

auch mein Gedächtnis sagt mir das, allerdings:
OpenGL gibt es seit 1992 (siehe Wikipedia)
C++ gibt es seit 1990 (soweit ich das auf Anhieb finden konnte, ebenfalls Wikipedia)
daraus kann man schlussfolgern, dass es historisch bedingt ist, dass für OpenGL C und nicht C++ verwendet wurde (eine Programmiersprache muss erst einmal ausreichend Verbreitung finden und das dauert schon einige Zeit)
und aufgrund der angestrebten Abwärtskompatibilität wird sich daran nichts ändern

Zitat von »S. P. Gardebiter«

Zitat von »LetsGo«

Das Argument vom Strom sparen ist beim PC irrelevant (1/3 mehr Befehle sind unrealistisch). Das mag bei einzelnen Methoden vllt passiern aber ist sicher nicht die Regel (Virtuelle Funktionen wären ein gutes Bsp).

nochmal, beim Strom ging es um folgendes Zitat: "Wo Leistung im Überfluss ist, kann man keine Verschwenden.", ich wiederhole mich langsam, weil ihr euch meine Postings nicht genau durchlest.
Es ging mir allgemein um Resourcenverschwendung, die de facto da ist. Wenn du mir das mit den 1/3 mehr Befehle nicht glaubst, steht es dir frei das entsprechende Programm selber zu disassemblieren und selbst zu sehen.

bezüglich des Punkts der unnötigen Instruktionen sollten beide Seiten neue Beweise auffahren
so wie ich es verstanden habe, ist das Dissassambilat (?) bereits einige Zeit alt und es kann nicht mit Sicherheit gesagt werden, dass es sich eventuell um eine nicht optimierte Debugversion handelt
als "Beweis" dafür wurde das typische Verhalten des Compilers genannt
du könntest beispielsweise exemplarisch Code schreiben, bei dem dies auftritt, damit man das genannte Problem nachvollziehbar wird
die andere Seite könnte C++ und C Code (objektorientiert und prozedural) schreiben, die das gleiche Problem lösen und diese miteinander vergleichen

Zitat von »S. P. Gardebiter«

Zitat von »BlueCobold«

Ja, man *kann* definitiv OOP-Varianten wesentlich langsamer schreiben, als Prozedurale. Es geht genauso aber auch andersrum. Wenn ich diese Unfugsbehauptung also beweisen *will*, dann geht das natürlich.
Gerade bei Verarbeitung tausender Daten in Matrizen brauch ich mich nicht wundern, dass eine Array-Variante mit perfektem Cache-Verhalten besser ist als eine im RAM zerhackstückte Verteilung der Daten. Das ist aber kein Problem von OOP, sondern von falscher Verwendung von OOP zum Missbrauch eines fehlerhaften Beweises. In diesem Fall gilt wohl eher "quo errat demonstrator" statt "quod erat demonstrandum".

Natürlich gibts genug Beispiele wo objektorientierter Code Sachen kann, die prozeduraler Code nicht kann oder er schneller ist. Ich wurde aber darauf z.B. hingewiesen warum ich nicht Klassen anstatt Structs benutze, das empfinde ich als ineffektiv und oft brauch man den objekt orientierten Ansatz garnicht und kommt mit dem prozeduralen entweder mindstens genauso gut aus oder er ist sogar schneller. (Auch beim Code schreiben) Ich versteh nur nicht warum man überall immer OOP verwenden will und alles damit lösen will, es jedem aufzwingen will es möglichst oft zu verwenden, auch da wo es absolut garnicht unnötig ist, alles verkompiliziert und eventuell auch langsamer läuft, deshalb verwende ich es sparsam und da wo ich meine, dass es sinnvoll ist.

bezüglich der Getter und Setter gab es bereits ein anderes Thema
zusätzliche Funktionsaufrufe hat man durch Objektorientierung nicht grundsätzlich bzw. gar nicht (siehe dazu auch den verlinken Beitrag)
man hat die Methoden und die Variablen, auf denen sie arbeiten, beisammen
dadurch, dass man im Kontext eines Objekts eine Methode aufrufen kann, und keine Referenz/keinen Pointer/wasauchimmer auf die zu verwendenden Daten mitgeben muss, ist der Code wesentlich lesbarer


bezüglich des Verhaltens der Hersteller in Hinsicht auf Optimierung:
würden die Hersteller ihre Spieler stärker optimieren (sofern möglich), dann würden die Kosten für die Spiele ungemein steigen, was die Spieler wiederum nicht nachvollziehen könnten
zudem geht der Spielehersteller nicht nach dem Leitsatz "wie kann ich den Spieler am besten zu neuer Hardware zwingen", sondern eher nach dem Leitsatz "was kann ich mit aktueller Hardware alles anstellen" vor (würde ich zumindest behaupten)
allerdings steckt in diesem Teil viel zu viel Vermutung, da man nie sagen kann, wie gut etwas bereits optimiert wurde und wie sehr sich etwas noch optimieren ließe (und welchen Zeitaufwand dies bedeuten würde)

weiterhin sollte man den wirtschaftlichen Aspekt nicht außer acht lassen
wenn ein Spiel noch vor Weihnachten Released werden soll (also für das Weihnachtsgeschäft), dann muss die Entwicklung selbst eine bestimmte Anzahl an Tagen vorher fertig sein, damit Trailer erstellt, Datenträger beschrieben etc. werden können
wenn das Spiel bis zu diesem Zeitpunkt gerade so fertig wird, dann ist einfach keine Zeit mehr für Optimierungen da (dürfte schon beschrieben worden sein)
wenn das Spiel also 2 Wochen vor Weihnachten erscheinen soll, würde eine um 2 Wochen verlängerte Entwicklung zwecks Optimierung bedeuten, dass das Spiel erst nach Weihnachten erscheint
und mir ist wirklich kein Projekt bekannt, in dem auch so kein Termindruck herrschte


zum Zitat "Ressourcen im Überfluss":
der Rechner bei mir auf Arbeit hat einen 2-Kerner mit 2,8 GHz und ~ 3,5 GB Arbeitsspeicher
das ist ein PC aus dem mittleren Leistungsbereich (oder gar dem unteren?)
Spiele, die also 2 GB Arbeitsspeicher belegen (und das dürften Spiele für einen höheren Bereich sein), dürften also nicht so viel Arbeitsspeicher verschwenden, als dass ein Mittelklasse PC sie nicht ausführen könnte
1 TB Festplatte ist auch nicht die Welt (3 TB für insgesamt 150 €), weshalb auch eine Größe von 10 oder 20 GB auf der Festplatte (wieder Werte von Spielen, die eher für höherklassige Geräte entwickelt werden) nicht das Problem sind

die Leistungsaufnahme als Kriterium zu nennen, ist eher unsinnig, wenn von nicht-mobilen Geräten gesprochen wird
den meisten Spielern ist es egal, ob der Prozessor 10% mehr oder weniger Strom verbraucht während sie am Spielen sind
den meisten ist eine hohe Framerate wichtig, aber ich bezweifle, dass durch gute Optimierung die Framerate um 30 % gesteigert werden könnte (obwohl eine Framerate äquivalent zur Bildwiederholrate des Bildschirms optimal wäre, aber naja...)



@dot:
könntest du die Diskussion, die nichts mit dem eigentlichen Thema zu tun hat, auslagern?