Eu sempre achei o termo "micro-otimização" bastante ambíguo. Se algumas mudanças no nível da instrução no layout da memória e nos padrões de acesso tornam algo 80 vezes mais rápido de um profissional disciplinado que mede seus pontos de acesso sem reduzir a complexidade algorítmica, isso é uma "micro-otimização"? Para mim, é uma "mega otimização" para tornar algo 80 vezes mais rápido em um caso de uso do mundo real. As pessoas tendem a falar sobre essas coisas, como essas otimizações têm efeitos microscópicos.
Não estou mais trabalhando no gamedev, mas trabalho em VFX em áreas como rastreamento de caminhos, e já vi muitas implementações de árvores BVHs e KD por aí que processam ~ 0,5 milhão de raios por segundo em uma cena complexa (e isso é com avaliação multithread). Grosso modo, eu costumo ver uma implementação direta de uma BVH em um contexto de rastreamento de raios abaixo de 1 milhão de raios / s, mesmo com avaliação multithread. Exceto Embree tem um BVH que pode processar mais de 100 milhões de raios na mesma cena com o mesmo hardware.
Isso se deve inteiramente às "micro-otimizações" de que o Embree é 200 vezes mais rápido (mesmo algoritmo e estrutura de dados), mas é claro que o motivo é muito mais rápido, porque os desenvolvedores da Intel por trás dele são profissionais que se apóiam em seus perfis, medições e realmente sintonizou as áreas que importavam. Eles não estavam mudando o código de uma maneira ou de outra, cometendo alterações que fizeram 0,000000001% de melhorias com o custo de manutenção significativamente degradante. Essas foram as otimizações muito precisas aplicadas em mãos criteriosas - elas podem ter sido microscópicas em termos de foco, mas macroscópicas em termos de efeito.
Naturalmente, com os requisitos de taxa de quadros em tempo real dos jogos, dependendo de como você trabalha com alto nível ou baixo nível com o mecanismo de jogo (mesmo os jogos feitos com UE 4 são geralmente implementados pelo menos parcialmente em scripts de alto nível, mas não, digamos, as partes mais críticas do mecanismo de física), as micro-otimizações se tornam um requisito prático em determinadas áreas.
Outra área muito básica que nos cerca diariamente é o processamento de imagens, como desfocar imagens de alta resolução em tempo real e talvez fazer outros efeitos nelas como parte de uma transição que provavelmente já vimos em algum lugar, talvez até um efeito do sistema operacional. Você não pode necessariamente implementar essas operações de imagem do zero, percorrendo todos os pixels de uma imagem e esperar resultados em tempo real com taxas de quadros correspondentes. Se é CPU, geralmente observamos o SIMD e alguns micro-ajustes, ou observamos os shaders de GPU, que tendem a exigir um tipo de mentalidade de nível micro para escrever com eficiência.
Em caso afirmativo, à medida que o hardware melhora, devemos esperar que idiomas de nível superior assumam o controle da indústria de jogos?
Duvido que apenas os avanços do hardware possam fazer isso, porque, à medida que o hardware avança, o mesmo acontece com as instruções e a tecnologia (ex: física na GPU), técnicas e expectativas dos clientes quanto ao que eles querem ver e competição. maneiras pelas quais os desenvolvedores frequentemente voltam a entrar em nível mais baixo novamente, como no caso dos desenvolvedores da Web que agora escrevem shaders GLSL de baixo nível no WebGL (o desenvolvimento da Web desse tipo específico é provavelmente ainda mais baixo do que há uma ou duas décadas atrás, como o GLSL é uma linguagem do tipo C de nível extremamente baixo, e eu nunca imaginaria uma década ou duas atrás que alguns desenvolvedores da Web aceitariam escrever tais shaders de GPU de baixo nível).
Se houver uma maneira de as áreas críticas de desempenho mudarem para linguagens de nível superior, terá que vir mais do software, compiladores e ferramentas que temos disponíveis a meu ver. O problema para mim em um futuro próximo não é o hardware não ser suficientemente poderoso. Tem mais a ver com a forma como não conseguimos encontrar maneiras de falar com mais eficiência a cada vez que ela muda e avança sem voltar ao seu próprio idioma. Na verdade, é o ritmo acelerado em que o hardware muda que torna a programação de alto nível ilusória para essas áreas, como eu o vejo, pois se, hipoteticamente, nosso hardware parar de avançar do nada nas décadas seguintes,
É engraçado nos dias de hoje, quando estou trabalhando em áreas genuínas de desempenho crítico, preciso pensar em um nível mais baixo do que comecei (apesar de ter começado na era do Borland Turbo C DOS). Porque naquela época o cache da CPU era quase inexistente. Era basicamente apenas DRAM e registros, o que significava que eu poderia me concentrar mais na complexidade algorítmica e escrever estruturas vinculadas como árvores de uma maneira muito direta, sem sofrer muito impacto no desempenho. Atualmente, os detalhes de baixo nível do cache da CPU dominam meu pensamento quase tanto quanto o próprio algoritmo. Da mesma forma, temos máquinas com vários núcleos que precisam nos fazer pensar em multithreading, atômica e mutexes, segurança de threads e estruturas de dados simultâneas, e assim por diante, o que eu diria que é, em muitos aspectos, um foco de nível muito mais baixo (como in, não tão humanamente intuitivo) do que quando comecei.
Estranhamente, isso me parece muito verdadeiro agora. Acho que estou mais impactado pelas complexidades e detalhes subjacentes e de baixo nível do hardware hoje do que há 30 anos, tentando o meu melhor para tirar os óculos de nostalgia. É claro que talvez tenhamos conversado um pouco sobre montagem aqui e tivemos que lidar com alguns detalhes sangrentos, como o XMS / EMS. Mas, na maioria das vezes, eu diria que havia menos complexidade e conhecimento de hardware e compilador que eu exigia naquela época do que hoje quando trabalho em áreas críticas de desempenho. E isso quase parece verdadeiro para toda a indústria se deixarmos de lado como escreverif/else instruções de uma maneira um pouco mais humanamente legível e considere o quanto as pessoas em geral hoje em dia estão pensando mais nos detalhes de nível inferior do hardware (de vários núcleos a GPUs, a SIMD no cache da CPU e os detalhes internos de como seus compiladores / intérpretes / bibliotecas funcionam e assim por diante).
Alto nível! = Menos eficiente
Voltando a esta pergunta:
Em caso afirmativo, à medida que o hardware melhora, devemos esperar que idiomas de nível superior assumam o controle da indústria de jogos?
Para mim, não é sobre hardware. É sobre otimizadores e ferramentas. Quando eu comecei, as pessoas praticamente escreveram todos os jogos de console em assembly, e havia uma vantagem de desempenho genuína, especialmente devido à falta de compiladores de qualidade gerando 6502.
À medida que a otimização dos compiladores C ficou mais inteligente em suas otimizações, eles começaram a chegar a um ponto em que o código de nível superior escrito em C estava rivalizando e, ocasionalmente, até superando o código escrito pelos melhores especialistas em montagem em muitas áreas (embora nem sempre), e isso fez com que fosse então um acaso adotar C para pelo menos a maior parte da codificação de um jogo. E uma mudança semelhante aconteceu gradualmente em algum momento com o C ++. A adoção do C ++ foi mais lenta, pois acho que o aumento da produtividade de ir de assembly para C provavelmente poderia chegar a um acordo unânime dos gamedevs que escrevem jogos não triviais inteiramente no ASM, em vez de passar de C para C ++.
Mas essas mudanças não vieram do hardware se tornar mais poderoso, mas os otimizadores dessas linguagens tornando o nível mais baixo em grande parte (embora nem sempre inteiramente, há alguns casos obscuros) obsoletos.
Se você pode imaginar um cenário hipotético em que poderíamos escrever código no código de mais alto nível imaginável, sem se preocupar com multithreading ou GPUs ou falhas de cache ou algo assim (talvez nem mesmo estruturas de dados específicas), e o otimizador era como inteligência artificial inteligente e capaz de descobrir os layouts de memória mais eficientes, reorganizando e compactando nossos dados, calculando que ele poderia usar alguma GPU aqui e ali, paralelizar algum código aqui e ali, usar algum SIMD, talvez criar um perfil próprio e continuar otimizando ainda mais seu IR como seres humanos respondendo a pontos críticos de criação de perfil, e isso foi feito de uma maneira que supera os melhores especialistas do mundo, seria um acéfalo para quem trabalha nas áreas mais críticas de desempenho adotá-lo ... e isso é um avanço provenientes de otimizadores ridiculamente inteligentes, e não de hardware mais rápido.