Atkatla schrieb:
Dann ignorierst du aber das Wort "premature" in dem Zitat absichtlich. Es geht um verfrühte (premature) Optimierungen, die im Laufe der weiteren Entwicklungen ohnehin hinfällig werden oder Szenarien abdecken, die dann nie eintreten werden. Diese sind unnötig.
Ich ignoriere es nicht.
Vielmehr bin ich davon überzeugt, dass dieses das Prinzip nur aufweichte, da zu dem Zeitpunkt eine Software oft genug ohne Performance-Optimierung gar nicht betrieben werden konnte. Damals hätte niemand so ein Statement ohne dem "premature" Zusatz beachtet. Heute sieht es dahingehend ganz anders aus und man kann das Prinzip, um das mMn. unnötige Wort entschlaken um eine eindeutigere, bessere Version zu erhalten.
Deine weiteren Argumente kann ich nicht ganz nachvollziehen, da:
"Im Laufe der weiteren Entwicklung hinfällig" -> bedeutet gleichzeitig, dass eine zwingende Notwendigkeit besteht, ergo keine Optimierung in diesem Sinne. Sofern man überhaupt annehmen kann, so genau über die Zukunft bescheid zu wissen. Oder eine einfache Anforderung, und so eine umzusetzen kann ja wohl kaum unter "Optimierung" fallen.
"oder Szenarien die dann nie eintreten werden" -> Ob etwas eintritt oder nicht kann man nie wissen, das sind Glaskugelwissenschaften. Und wenn etwas gemacht wird was schlichtweg nicht notwendig ist, dann fällt es wohl auch kaum unter den Begriff "Optimierung", oder nicht?
Das sind keine Optimierungen, premature hin oder her, sondern einfach nur schlechtes Software Engineering
Ich habe gerade versucht niederzuschreiben was ein valider Fall einer Optimierung wäre, das ist nicht ganz so trivial wie ich es mir erhofft hatte, dennoch denke ich dass ich bei einer ganz guten Beschreibung gelandet bin:
- Wird die Abstraktionsstufe einer Lösung reduziert und somit spezifischer im Kontext einer bestimmten Plattform oder Domäne mit dem Zweck die vorhandenen Ressourcen auf Kosten einer höheren Komplexität besser nutzen zu können, so spricht man von Optimierung.
- Falls eine Optimierung nicht Aufgrund einer bekannten Performance-Anforderung oder der Verletzung einer solchen durch die Umsetzung einer Nicht-Performance-Anforderung geschieht, so spricht man von einer "premature" Optimierung
Es sollte bedacht werden, dass solche Anforderungen nur selten gerechtfertigt werden können, z.B. in Real-Time-Szenarien, in denen harte Zeitbudgets existieren (60FPS in Videospielen, 200ms Response time in User Interfaces), in Wettbewerb-Szenarien (der Kontrahent bietet die gleiche Software aber in schneller), oder schlichtweg weil die CPU-Zeit mehr Geld kostet als man sich leisten kann (IBM
wink wink).
Atkatla schrieb:
Raytracing vs kein Raytracing ist eine technologische Entscheidung, die du ja bereits viel früher treffen musst. Hier wäre "premature" wenn du Raytracing-Code optimierst, obwohl noch nicht festgelegt wurde, ob das Produkt überhaupt Raytracing einsetzt oder nicht.
Nope, ist es nicht. Es gibt nur einen einzigen Vorteil kein Raytracing einzusetzen, Performance. Darauf zu verzichten bedeutet Unmengen an zusätzlicher Arbeit ohne sonstige Vorteile.
Es ist mit Abstand die einfachste Methode Belichtung im 3D Raum darzustellen.
Das wusste man schon immer, und es gab unzählige Versuche Raytracing unter anderem in Videospielen unterzubringen. Bis vor kurzen Stand es komplett außer Frage, dass ein PC genug Leistung für Echtzeit-Raytracing liefern könnte. Vor dem Erscheinen der RTX-GPUs war es auch oft die Frage, ob Raytracing jemals Rasterization sinnvoll ersetzen kann. Selbst heute ist beim Raytracing vieles noch Fake, es werden hybride Modelle mit Rasterization eingesetzt, Neuronale Netze zum Denoising verwendet und auf multiple Bounces verzichtet. Um wirklich pures, echtes Raytracing einzusetzen bräuchten wir GPU-Leistung um etwa Faktor 100-1000 größer als was uns heute zur Verfügung steht. Dann wäre die Beleuchtung in Spielen für die Entwickler praktisch "kostenlos" und beinahe "perfekt". Ein heiliger Gral der Videospielentwicklung
Solange da aber die großen Hersteller nicht in die Pötte kommen bleibt mir da relativ wenig übrig.
