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.