Mikrooptimierung - BAD vs. Spieleentwicklung

In der Spieleentwicklung gibt es viel C / C ++, in Geschäftsanwendungen C #. Ich habe C / C ++ - Entwickler gesehen, die sich besorgt darüber äußerten, wie eine einzelne Codezeile in Assembly übersetzt wird. In .NET gehen manche nur selten in die IL.

In C # ist "Mikrooptimierung" verpönt, selten und in der Regel Zeitverschwendung. Dies scheint bei der Spieleentwicklung nicht der Fall zu sein.

Was genau schafft diese Inkonsistenz? Übersteigen Spiele ständig die Grenzen der Hardware? Wenn ja, sollten wir mit der Verbesserung der Hardware damit rechnen, dass höhere Sprachen die Spieleindustrie übernehmen?

Ich bin nicht auf der Suche nach einer Debatte über die Machbarkeit von C # als Spieleentwickler. Ich weiß, dass es zu einem gewissen Grad getan wurde. Fokus auf Mikrooptimierung. Insbesondere der Unterschied zwischen Game Dev vs Applications dev.

UPDATE
Mit Spiel meine ich moderne, groß angelegte Entwicklung. ZB MMORPGs, Xbox, PS3, Wii ...

In Geschäftsanwendungen ist die CPU nicht immer der Engpass. Eine Geschäftsanwendung würde die meiste Zeit darauf warten. Z.B:

1. Warten auf Ergebnisse der Datenbankabfrage
2. Warten auf Abschluss der Webanforderung
3. Warten auf Benutzer, um eine Benutzeroberflächenaktion auszuführen

Das ist der Grund, warum Code, der die Verarbeitungsleistung optimiert, nicht zu viel Wert hinzufügt.

Hauptüberlegung ist:

1. Zeit zum Markt
2. Einfachheit, kann jemand anderes den Code verstehen und pflegen

In Geschäftsanwendungen ist es sehr selten, dass Mikrosekunden eine Rolle spielen. In Spielen ist es eine Tatsache des Lebens.

Wenn Sie möchten, dass ein Spiel mit 60 Bildern pro Sekunde läuft, haben Sie ~ 16,67 Millisekunden Zeit, um alles zu tun, was für dieses Bild getan werden muss - Eingabe, Physik, Gameplay-Logik, Audio, Netzwerk, KI, Rendering und so weiter. Wenn Sie Glück haben, laufen Sie mit 30 fps und haben luxuriöse 33,3 Millisekunden. Wenn ein Frame zu lange dauert, leiden Ihre Reviews, Ihre Spieler füllen Internetforen mit Galle und Sie verkaufen nicht so viel, wie Sie möchten (ganz zu schweigen von dem Schlag für Ihren professionellen Stolz) und wenn Sie wirklich Pech haben finden Sie Ihr Team Codierung Geschäftsanwendungen für den Lebensunterhalt.

Natürlich kümmern sich Spieleentwickler nicht um jede einzelne Zeile, da Sie mit Erfahrung und einem anständigen Profiler lernen, um welche Zeilen Sie sich kümmern müssen. Andererseits berühren diese Sorgen manchmal Dinge, die in der Geschäftswelt wahrscheinlich eher als Nanooptimierungen als als als Mikrooptimierungen zu betrachten sind.

Erwarten Sie nicht, dass eine höhere Sprache C ++ aus der Tür wirft, bis eine vergleichbare und vorhersehbare Leistung geboten wird.

Okay, Sie haben gesehen, wie C- und C ++ - Entwickler von einzelnen Zeilen besessen waren. Ich wette, sie sind nicht von jeder Zeile besessen.

Es gibt Fälle, in denen Sie die maximale Leistung wünschen, und dazu gehören viele Spiele. Spiele haben immer versucht, die Leistungsgrenzen zu überschreiten, um auf der gleichen Hardware besser auszusehen als die Konkurrenz. Dies bedeutet, dass Sie alle üblichen Optimierungstechniken anwenden. Beginnen Sie mit Algorithmen und Datenstrukturen und ziehen Sie von dort aus ein. Mithilfe eines Profilers können Sie feststellen, wo die meiste Zeit benötigt wird und wo die Mikrooptimierung einiger Zeilen erhebliche Vorteile bringt.

Dies liegt nicht daran, dass die Sprachen die Menschen dazu zwingen, sondern daran, dass die Menschen Sprachen basierend auf dem auswählen, was sie tun möchten. Wenn Sie das letzte Stück Leistung aus einem Programm herausholen möchten, schreiben Sie kein C # und kompilieren nicht in die CLR und hoffen, dass der JIT-Compiler (oder was auch immer) gute Arbeit leistet. Sie schreiben es in etwas, das Sie weitgehend steuern können die Ausgabe. Sie werden C oder C ++ (und wahrscheinlich eine eingeschränkte Teilmenge von C ++) verwenden und die Ergebnisse der Assembler-Ausgabe und des Profilers untersuchen.

Es gibt viele Leute, die C und C ++ verwenden und sich nicht zu viele Gedanken über die Details der Übersetzung machen, solange es schnell genug zu sein scheint.

Übersteigen Spiele ständig die Grenzen der Hardware?

Ja, das tun sie.

Wenn ja, sollten wir mit der Verbesserung der Hardware damit rechnen, dass höhere Sprachen die Spieleindustrie übernehmen?

Nicht wirklich - denn wenn sich die Hardware verbessert, erwarten die Verbraucher, dass sich auch die Spiele verbessern. Sie erwarten nicht, dass die gleiche Qualität des Spiels effizienter entwickelt wird, da die Entwickler eine höhere Sprache verwendeten. Sie erwarten, dass ihnen von jeder neuen Plattform die Socken weggeblasen werden.

Natürlich gibt es etwas Bewegung. Als ich ein Junge war und mich zum ersten Mal für Spieleentwicklung interessierte, war es eine handschriftliche Zusammenstellung oder zum Teufel. Dies war die Commodore 64-Ära. Heutzutage ist C ++ natürlich die Verkehrssprache der meisten Spieleentwickler. Tatsächlich haben wir sogar Fortschritte bei der Verwendung von C ++ für Engine-Code und einer höheren Skriptsprache für Game-Logik-Code gesehen. zB LUA oder die Unreal-Engine hat eine eigene UnrealScript-Sprache.

In C # ist "Mikrooptimierung" verpönt, selten und in der Regel Zeitverschwendung. Dies scheint bei der Spieleentwicklung nicht der Fall zu sein.

Wenn Sie Ihre Anwendung nur mit High-Level-Code und Bibliothekscode zusammenstellen können, ist dies sicherlich Zeitverschwendung. Schreiben Sie es in einer interpretierten Sprache, wenn Sie dies wünschen. wird keinen großen Unterschied machen. Wenn Sie versuchen, eine hochmoderne globale Beleuchtungs-Engine zu implementieren, die dynamische Szeneninhalte im laufenden Betrieb in Echtzeit wie in CryEngine 3 voxelt , können Sie sich natürlich der Notwendigkeit einer Mikrooptimierung nicht entziehen .

"Spiel" ist ein umfassender Begriff. Wenn Sie zum Beispiel ein MMORPG hätten, würden kleinere Optimierungen viele Spieler beeinflussen.

Spieler sind und waren wahrscheinlich schon immer daran gewöhnt, dass in Echtzeit eine vergleichsweise große Menge von Dingen gleichzeitig passiert. Sicher; Zu einer Zeit war es das Ziel, einen reaktionsfähigen Pacman oder Tetris zu haben. Aber sie mussten immer noch reagieren. Heutzutage 3DMMORPGs über Paket-Drop-Netzwerkverbindungen.

Ich verstehe das sicher optimieren wollen.

Spiele machen ständig enorme Mengen an Hintergrundverarbeitung. Geschäftsanwendungen nicht.

Ich fand den Begriff "Mikrooptimierung" immer mehrdeutig. Wenn einige Änderungen des Speicherlayouts und der Zugriffsmuster auf Befehlsebene von einem disziplinierten Fachmann, der ihre Hotspots ohne Reduzierung der algorithmischen Komplexität misst, etwas 80-mal schneller machen, ist das eine "Mikrooptimierung"? Für mich ist das eine "Mega-Optimierung", um in einem realen Anwendungsfall etwas 80-mal schneller zu machen. Die Leute neigen dazu, über diese Dinge zu sprechen, da solche Optimierungen mikroskopische Auswirkungen haben.

Ich arbeite nicht mehr in gamedev, aber ich arbeite in VFX in Bereichen wie der Pfadverfolgung und ich habe viele Implementierungen von BVHs und KD-Bäumen gesehen, die ~ 0,5 Millionen Strahlen pro Sekunde in einer komplexen Szene verarbeiten (und das ist mit Multithread-Auswertung). Grob gesagt sehe ich selbst bei Multithread-Auswertung eine einfache Implementierung eines BVH in einem Raytracing-Kontext mit weniger als 1 Million Strahlen / Sekunde. Ausgenommen, Embree verfügt über einen BVH, der mit derselben Hardware über 100 Millionen Strahlen in derselben Szene verarbeiten kann.

Das liegt ausschließlich an den "Mikrooptimierungen", die Embree 200-mal schneller macht (gleicher Algorithmus und Datenstruktur), aber der Grund dafür ist natürlich, dass die Entwickler bei Intel Profis sind, die sich auf ihre Profiler und Messungen stützen und wirklich die Bereiche abgestimmt, die wichtig sind. Sie haben den Code nicht aus Versehen geändert und Änderungen vorgenommen, die zu einer Verbesserung um 0,000000001% geführt haben, was zu einer erheblichen Beeinträchtigung der Wartbarkeit geführt hat. Dies waren sehr genaue Optimierungen, die in vernünftigen Händen angewendet wurden - sie waren möglicherweise mikroskopisch in Bezug auf den Fokus, aber makroskopisch in Bezug auf die Wirkung.

Natürlich mit den Anforderungen an die Echtzeit-Framerate von Spielen, je nachdem, wie hoch oder niedrig Sie mit der Game Engine arbeiten (selbst Spiele, die mit UE 4 erstellt wurden, werden häufig zumindest teilweise in High-Level-Skripten implementiert). B. nicht die kritischsten Teile der Physik-Engine), werden Mikrooptimierungen in bestimmten Bereichen zu einer praktischen Anforderung.

Ein weiterer sehr grundlegender Bereich, der uns täglich umgibt, ist die Bildverarbeitung, z. B. das Verwischen hochauflösender Bilder in Echtzeit und möglicherweise das Ausführen anderer Effekte als Teil eines Übergangs, den wir wahrscheinlich alle irgendwo gesehen haben, möglicherweise sogar eines Betriebssystemeffekts. Sie können solche Bildoperationen nicht unbedingt von Grund auf neu implementieren, indem Sie alle Pixel eines Bildes durchlaufen und solche Echtzeitergebnisse bei übereinstimmenden Bildraten erwarten. Wenn es sich um eine CPU handelt, geht es normalerweise um SIMD und etwas Mikro-Tuning, oder um GPU-Shader, für deren effektives Schreiben in der Regel eine Denkweise auf Mikroebene erforderlich ist.

Wenn ja, sollten wir mit der Verbesserung der Hardware damit rechnen, dass höhere Sprachen die Spieleindustrie übernehmen?

Ich bezweifle eher, dass die Weiterentwicklung der Hardware dies allein bewirken könnte, da mit dem Fortschritt der Hardware auch die Anleitungen und die Technologie (z. B .: Physik auf der GPU) sowie die Techniken und Kundenerwartungen für das, was sie sehen möchten, und die Konkurrenz in Möglichkeiten, mit denen Entwickler häufig wieder auf Low-Level gehen, wie es auch bei Web-Entwicklern der Fall ist, die jetzt Low-Level-GLSL-Shader in WebGL schreiben (Web-Entwicklung dieser besonderen Art ist wahrscheinlich sogar auf niedrigerem Niveau als vor ein oder zwei Jahrzehnten). Da GLSL eine C-ähnliche Sprache mit extrem niedrigen Sprachniveaus ist, hätte ich vor ein oder zwei Jahrzehnten nie gedacht, dass einige Webentwickler solche GPU-Shader mit niedrigen Sprachniveaus schreiben würden.

Wenn es eine Möglichkeit für leistungskritische Bereiche geben soll, zu höheren Sprachen überzugehen, muss dies mehr von der Software und den Compilern und Tools kommen, die wir meiner Meinung nach zur Verfügung haben. Das Problem ist für mich in absehbarer Zeit, dass die Hardware nicht leistungsfähig genug ist. Es hat mehr damit zu tun, wie wir nicht bei jeder Änderung und Weiterentwicklung Wege finden können, um am effektivsten mit ihm zu sprechen, ohne uns wieder in die eigene Sprache zu begeben. Tatsächlich ist es das schnelle Tempo, mit dem sich die Hardware ändert, was die High-Level-Programmierung für diese Bereiche meines Erachtens ziemlich schwer fassbar macht, da unsere Hardware hypothetisch für die folgenden Jahrzehnte nicht mehr aus heiterem Himmel voranschreitet.

Komischerweise muss ich heutzutage, wenn ich in wirklich leistungskritischen Bereichen arbeite, etwas niedriger denken, als ich angefangen habe (obwohl ich in der Borland Turbo C DOS-Ära angefangen habe). Denn der CPU-Cache war damals fast nicht vorhanden. Es waren meist nur DRAM und Register, was bedeutete, dass ich mich mehr auf die algorithmische Komplexität konzentrieren und verknüpfte Strukturen wie Bäume sehr einfach schreiben konnte, ohne die Leistung zu beeinträchtigen. Heutzutage dominieren die Details auf niedriger Ebene des CPU-Cache mein Denken fast so sehr wie der Algorithmus selbst. Ebenso haben wir Multi-Core-Maschinen, die uns über Multithreading und Atomics und Mutexes und Thread-Sicherheit und gleichzeitige Datenstrukturen nachdenken lassen müssen in, nicht so menschlich intuitiv) als als ich anfing.

Seltsamerweise scheint mir das jetzt sehr wahr zu sein. Ich glaube, ich bin heute mehr von den zugrunde liegenden und niedrigen Komplexitäten und Details der Hardware betroffen als vor 30 Jahren, und versuche mein Bestes, um die Nostalgiebrille abzunehmen. Natürlich hätten wir uns hier ein bisschen über Montage unterhalten und uns mit einigen wichtigen Details wie XMS / EMS befassen müssen. Aber zum größten Teil würde ich sagen, dass ich damals weniger Komplexität und Kenntnisse über Hardware und Compiler benötigte als heute, wenn ich in leistungskritischen Bereichen arbeite. Und das scheint beinahe für die gesamte Branche zu gelten, wenn wir das Schreiben beiseite legenif/else leicht lesbarere Aussagen und Überlegungen, wie viel die Menschen heutzutage im Allgemeinen über die Details der Hardware auf niedrigerer Ebene nachdenken (von mehreren Kernen über GPUs über SIMD bis hin zum CPU-Cache und die internen Details darüber, wie ihre Compiler / Interpreter / Bibliotheken funktionieren und so weiter).

High Level! = Weniger effizient

Zurück zu dieser Frage:

Wenn ja, sollten wir mit der Verbesserung der Hardware damit rechnen, dass höhere Sprachen die Spieleindustrie übernehmen?

Für mich geht es nicht um Hardware. Es geht um Optimierer und Tools. Als ich anfing, schrieben die Leute praktisch alle Konsolenspiele in Assembler, und es gab einen echten Leistungsvorteil, insbesondere angesichts des Mangels an hochwertigen Compilern, die 6502 generieren.

Da die Optimierung von C-Compilern intelligenter wurde, erreichten sie einen Punkt, an dem der in C geschriebene Code auf höherer Ebene mit dem Code der besten Assembler-Experten in vielen Bereichen (wenn auch nicht immer) konkurrierte und diesen sogar übertraf das machte es so, dass es damals ein Kinderspiel war, C für mindestens den Großteil der Codierung für ein Spiel zu übernehmen. Und eine ähnliche Verschiebung passierte allmählich irgendwann mit C ++. Die Übernahme von C ++ war langsamer, da ich denke, dass die Produktivitätssteigerung beim Übergang von Assembly zu C wahrscheinlich zu einer einstimmigen Einigung führen könnte, wenn Gaming-Fans nicht-triviale Spiele ausschließlich in ASM schreiben, anstatt von C zu C ++ zu wechseln.

Diese Verschiebungen sind jedoch nicht darauf zurückzuführen, dass die Hardware leistungsfähiger geworden ist, sondern dass die Optimierungsfunktionen für diese Sprachen weitgehend auf eine niedrigere Ebene (obwohl nicht immer vollständig, es gibt einige unklare Fälle) überholt sind.

Wenn Sie sich ein hypothetisches Szenario vorstellen können, in dem wir Code in der höchsten denkbaren Codestufe schreiben könnten, ohne sich Gedanken über Multithreading oder GPUs oder Cache-Fehler oder ähnliches zu machen (möglicherweise nicht einmal spezifische Datenstrukturen), und das Optimierungsprogramm war wie künstliche Intelligenz schlau und könnte die effizientesten Speicher-Layouts finden, die unsere Daten neu anordnen und komprimieren, herausfinden, dass sie hier und da eine GPU verwenden, hier und da einen Code parallelisieren, eine SIMD verwenden, sich vielleicht selbst profilieren und ihre IR weiter optimieren, wie wir Menschen Wenn Sie auf Profiler-Hotspots reagieren und dies auf eine Weise tun, die die besten Experten der Welt übertrifft, ist es selbst für diejenigen, die in den leistungskritischsten Bereichen arbeiten, ein Kinderspiel, dies zu übernehmen ... und das ist ein Fortschritt aus lächerlich klugen Optimierern, nicht schnellerer Hardware.

In C # ist "Mikrooptimierung" verpönt, selten und in der Regel Zeitverschwendung. Dies scheint bei der Spieleentwicklung nicht der Fall zu sein.

Sie haben hier ein terminologisches Problem. Sie verwenden die Wörter korrekt, aber Spieleentwickler und Geschäftsleute verwenden denselben Begriff auf zwei sehr unterschiedliche Arten.

Für Unternehmen bedeutet "Mikrooptimierung", einen sehr kleinen Schritt im gesamten Geschäftsprozess zu beschleunigen, der von der Software implementiert wird. Der Grund, warum es verpönt ist, ist in der Regel einer der folgenden:

1. Zusätzliches Geld für die Erzielung des gleichen Geschäftswerts in wenigen Sekunden schnellerer Geschwindigkeit. Das in den Geschwindigkeitsverbesserungen eingesparte Geld stammt aus einem anderen Geldpool (der Zeit des Benutzers), sodass das Unternehmen im Allgemeinen nicht von dem Aufwand profitiert, den es verursacht, sondern der Kunde auf Kosten des Unternehmens.
2. In der Regel haben Business-Programmierer eine schlechte Übersicht über den gesamten Geschäftsprozess, sodass eine Optimierung eines einzelnen Schritts möglicherweise keine positiven Auswirkungen auf den gesamten Prozess hat. Wenn Sie beispielsweise 3% des Prozesses um das 10-fache beschleunigen, haben Sie den gesamten Prozess um 2,7% beschleunigt.
3. In der Regel verfügt ein Unternehmen über eine große Liste verbleibender Arbeiten, die einen gewissen geschäftlichen Wert aufweisen, und würde das Hinzufügen dieses Werts priorisieren, anstatt den gleichen Wert in (wahrscheinlich) kürzerer Zeit zu liefern.

Spieleentwicklung ist ein anderes Biest. "Mikrooptimierung" spart eine kleine Menge Zeit in einer Funktion oder Routine.

1. Spielesysteme neigen dazu, an den Renderzyklus gebunden zu sein. Derzeit liegt der goldene Standard bei 60 Bildern pro Sekunde. Daher muss alles, was berechnet werden soll, in 1/60 Sekunde auf dem Bildschirm gerendert werden.
2. Dies bedeutet, dass im Laufe eines Spiels häufig dieselben Routinen Tausende bis Hunderttausende Male aufgerufen werden. Somit wird eine 10-fache Verbesserung einer einzelnen Funktion um das Mehrfache ihres Nutzens vergrößert.
3. Das Nichterreichen der Rendering-Rate wirkt sich auf die Darstellung des Spiels aus. Das Video wird abgehackt, die Charaktere werden mit Sprüngen und Sprüngen animiert, anstatt mit fließenden Bewegungen. Dies bringt den Spieler sofort aus dem Spiel und in den Bereich, in dem der Wert des Spiels in Frage gestellt wird.

Im Geschäftsleben interessiert es niemanden, ob die Form eines 4-Stufen-Geschäftsprozesses in 0,6 Sekunden oder 0,5 Sekunden vorliegt. Während des Spielens ist es wichtig, ob eine Routine, die 200 ms dauert, in 100 ms ausgeführt werden kann.

Es dreht sich alles um den Wert, der dem Kunden geliefert wird, die Bedürfnisse des Kunden und das Kosten-Nutzen-Verhältnis der Änderung.

Dies hängt damit zusammen, warum dieses Tool für einen bestimmten Auftrag ausgewählt wurde.

Golfer werden über die Richtung und Kraft besessen sein, die sie mit einem Putter ausüben, nicht so sehr, wenn sie den Fahrer benutzen.

Warum? Weil sie verschiedene Arten von Aufnahmen sind. Für eine Fahrt möchten Sie es mit maximaler Entfernung in das Fairway bekommen. Für einen Putt möchten Sie ihn genau in das Loch bekommen.

Gleiches gilt hier. Spieleentwickler entscheiden sich für C ++, da sie die Leistung verschiedener Vorgänge steuern können. Wenn Sie das gewählt haben, werden Sie es nutzen wollen.

Die meisten Geschäftsanwendungen werden als interne Tools geschrieben. Die Erwartungen an die Benutzerfreundlichkeit dieser Tools sind viel geringer als bei Software, die an Massenkunden verkauft wird. Es ist durchaus üblich, dass eine firmeninterne Geschäftsanwendung Menüs und Dialoge enthält, die langsam auf Mausklicks reagieren, Fenster, die verzögert neu gezeichnet werden, oder sogar eine in Swing geschriebene Benutzeroberfläche (der Horror!). Dies hat eine Reihe von Gründen (es ist wichtiger, dass die Software anpassbar ist, als dass sie sehr "bissig" ist). Die Benutzer der Software haben keine Wahl, ob sie die betreffende Software verwenden oder nicht, die Leute, die die Software herstellen Entscheidung zur Installation der Software nicht selbst verwenden ...). Die Konsequenz daraus ist, dass die Entwickler dieser Tools nicht viel Zeit damit verbringen, die Reaktionsfähigkeit der Anwendung zu optimieren. Aber achten Sie sehr auf die Erweiterbarkeit und die Anzahl der Funktionen. Unterschiedlicher Kundenstamm => unterschiedliche Designziele => unterschiedliche Methodik.

Beachten Sie, dass eine Geschäftsanwendung, die sich an eine breite Zielgruppe richtet, wie z. B. Excel, stark optimiert ist.