J'ai toujours trouvé le terme «micro-optimisation» assez ambigu. Si certains changements au niveau de l'instruction de la disposition de la mémoire et des modèles d'accès rendent quelque chose 80 fois plus rapide d'un professionnel discipliné mesurant leurs points d'accès sans réduction à la complexité algorithmique, est-ce une "micro-optimisation"? Pour moi, c'est une "méga-optimisation" pour rendre quelque chose 80 fois plus rapide dans un cas d'utilisation réel. Les gens ont tendance à parler de ces choses comme ces optimisations ont des effets microscopiques.
Je ne travaille plus dans gamedev mais je travaille dans VFX dans des domaines comme le traçage de chemin, et j'ai vu de nombreuses implémentations d'arbres BVH et KD qui traitent ~ 0,5 million de rayons par seconde sur une scène complexe (et c'est avec évaluation multithread). En gros, j'ai tendance à voir une implémentation simple d'un BVH dans un contexte de raytracing à moins de 1 million de rayons / sec, même avec une évaluation multithread. Sauf qu'Embree a un BVH qui peut traiter plus de 100 millions de rayons sur la même scène avec le même matériel.
Cela est entièrement dû aux "micro-optimisations" qu'Embree est 200 fois plus rapide (même algorithme et structure de données), mais bien sûr, la raison pour laquelle c'est tellement plus rapide est que les développeurs d'Intel derrière lui sont des professionnels qui s'appuient sur leurs profileurs et leurs mesures et vraiment réglé les domaines qui comptaient. Ils ne changeaient pas le code de bon gré des intuitions et ne commettaient pas de modifications qui ont apporté des améliorations de 0.000000001% au prix d'une dégradation significative de la maintenabilité. Il s'agissait d'optimisations très précises appliquées entre des mains judicieuses - elles pouvaient être microscopiques en termes de focalisation mais macroscopiques en termes d'effet.
Naturellement avec les exigences de taux de trame en temps réel des jeux, selon le niveau ou le niveau bas dans lequel vous travaillez avec le moteur de jeu (même les jeux créés avec UE 4 sont souvent implémentés au moins partiellement dans un script de haut niveau, mais pas, disons, les parties les plus critiques du moteur physique), les micro-optimisations deviennent une exigence pratique dans certains domaines.
Un autre domaine très basique qui nous entoure quotidiennement est le traitement d'image, comme le flou d'images haute résolution en temps réel et peut-être leur faire d'autres effets dans le cadre d'une transition que nous avons probablement tous vu quelque part, peut-être même un effet de système d'exploitation. Vous ne pouvez pas nécessairement implémenter de telles opérations d'image à partir de zéro en bouclant tous les pixels d'une image et vous attendre à de tels résultats en temps réel à des fréquences d'images correspondantes. Si c'est un processeur, nous examinons généralement SIMD et certains micro-réglages, ou nous examinons les shaders GPU qui nécessitent généralement une sorte de mentalité au niveau micro pour écrire efficacement.
Si oui, à mesure que le matériel s'améliore, devrions-nous nous attendre à ce que des langages de niveau supérieur prennent le contrôle de l'industrie du jeu?
Je doute plutôt que les progrès du matériel à eux seuls puissent le faire, car au fur et à mesure que le matériel progresse, les instructions et la technologie (ex: physique sur GPU), les techniques et les attentes des clients pour ce qu'ils veulent voir et la concurrence des moyens qui font souvent revenir les développeurs à bas niveau, comme dans le cas même des développeurs Web qui écrivent maintenant des shaders GLSL de bas niveau dans WebGL (le développement Web de ce type particulier est sans doute encore plus bas qu'il y a une décennie ou deux, car GLSL est un langage de type C extrêmement bas, et je n'aurais jamais imaginé il y a une décennie ou deux que certains développeurs Web accepteraient d'écrire de tels shaders GPU de bas niveau).
S'il doit y avoir un moyen pour les domaines critiques pour les performances de passer à des langages de niveau supérieur, cela devra provenir davantage des logiciels, des compilateurs et des outils dont nous disposons à mon avis. Dans un avenir prévisible, le problème n'est pas que le matériel ne soit pas assez puissant. Cela a plus à voir avec la façon dont nous ne pouvons pas trouver les moyens de lui parler le plus efficacement chaque fois qu'il change et avance sans revenir à sa propre langue. C'est en fait le rythme rapide auquel le matériel change qui rend la programmation de haut niveau plutôt insaisissable pour ces domaines comme je le vois, car si hypothétiquement notre matériel a cessé d'avancer à l'improviste pendant les décennies suivantes,
Curieusement ces jours-ci, quand je travaille dans de véritables domaines critiques pour les performances, je dois penser un peu plus bas que j'ai commencé (même si j'ai commencé à l'ère Borland Turbo C DOS). Parce qu'à l'époque, le cache du processeur était presque inexistant. Il s'agissait principalement de DRAM et de registres, ce qui signifiait que je pouvais me concentrer davantage sur la complexité algorithmique et écrire des structures liées comme des arbres de manière très simple sans trop affecter les performances. De nos jours, les détails de bas niveau du cache CPU dominent ma pensée presque autant que l'algorithme lui-même. Et de même, nous avons des machines multi-cœurs qui doivent nous faire penser au multithreading et à l'atomique et aux mutex et à la sécurité des threads et aux structures de données simultanées, etc. dans, pas si intuitivement humainement) que quand j'ai commencé.
Curieusement, cela me semble très vrai maintenant. Je pense que je suis plus impacté par les complexités et les détails sous-jacents et de bas niveau du matériel aujourd'hui qu'il y a 30 ans, faisant de mon mieux pour enlever les lunettes de nostalgie. Bien sûr, nous aurions pu parler un peu d'assemblage ici et avoir dû traiter de quelques détails sanglants comme XMS / EMS. Mais pour la plupart, je dirais qu'il y avait moins de complexité et de sensibilisation au matériel et au compilateur dont j'avais besoin à l'époque qu'à l'heure actuelle lorsque je travaille dans des domaines critiques pour les performances. Et cela semble presque vrai pour l'ensemble de l'industrie si nous mettons de côté comme l'écritureif/else déclarations d'une manière légèrement plus lisible par l'homme et considérer combien de personnes en général ces jours-ci pensent davantage aux détails de niveau inférieur du matériel (de plusieurs cœurs aux GPU à SIMD au cache CPU et les détails internes de la façon dont leurs compilateurs / interprètes / les bibliothèques fonctionnent, etc.).
Niveau élevé! = Moins efficace
Pour en revenir à cette question:
Si oui, à mesure que le matériel s'améliore, devrions-nous nous attendre à ce que des langages de niveau supérieur prennent le contrôle de l'industrie du jeu?
Pour moi, ce n'est pas une question de matériel. Il s'agit d'optimiseurs et d'outils. Quand j'ai commencé, les gens écrivaient pratiquement tous les jeux de console en assemblage, et il y avait un véritable avantage en termes de performances, surtout compte tenu du manque de compilateurs de qualité générant 6502.
L'optimisation des compilateurs C est devenue plus intelligente dans leurs optimisations, puis ils ont commencé à atteindre un point où le code de niveau supérieur écrit en C rivalisait et parfois même surpassait le code écrit par les meilleurs experts de l'assemblage dans de nombreux domaines (mais pas toujours), et cela a fait en sorte qu'il était alors évident d'adopter le C pour au moins la majeure partie du codage d'un jeu. Et un changement similaire s'est progressivement produit à un moment donné avec C ++. L'adoption de C ++ a été plus lente car je pense que l'augmentation de la productivité du passage de l'assemblage au C pourrait probablement atteindre l'accord unanime de gamedevs écrivant des jeux non triviaux entièrement en ASM par opposition au passage du C au C ++.
Mais ces changements ne sont pas dus au fait que le matériel est devenu plus puissant que les optimiseurs pour ces langages qui sont devenus de plus bas niveau (bien que pas toujours entièrement, il y a des cas obscurs) obsolètes.
Si vous pouvez imaginer un scénario hypothétique où nous pourrions écrire du code dans le code de plus haut niveau imaginable, sans se soucier du multithreading ou des GPU ou des échecs de cache ou quelque chose comme ça (peut-être même pas des structures de données spécifiques), et l'optimiseur était comme l'intelligence artificielle intelligent et pourrait comprendre les dispositions de mémoire les plus efficaces en réarrangeant et en compactant nos données, comprendre qu'il pourrait utiliser un GPU ici et là, paralléliser du code ici et là, utiliser un SIMD, peut-être se profiler et continuer à optimiser son IR comme nous les humains répondre aux hotspots du profileur, et cela l'a fait d'une manière qui bat les meilleurs experts du monde, alors ce serait une évidence pour même ceux qui travaillent dans les domaines les plus critiques pour les performances de l'adopter ... et c'est une avancée provenant d'optimiseurs ridiculement intelligents, pas de matériel plus rapide.