Quais implicações JIT (javascript / canvas) vs. AOT (Flash) têm em termos de desempenho de jogos baseados em navegador?

Na minha experiência, até o dia de hoje, ainda vejo mais um atraso visual no movimento / animação da entidade em jogos baseados em JavaScript (Canvas) do que em jogos baseados em Flash.

Por que isso - qual é exatamente a discrepância no nível mais básico entre um compilador JIT vs AOT no cenário específico de JavaScript vs. Flash.

Não é o método de compilação que atrasa os jogos, é o coletor de lixo e o coletor de lixo Flash é separado dos navegadores.

Acho que posso raciocinar com confiança que você executa o Firefox, porque o coletor de lixo do Firefox é a pior porcaria que você pode obter, do ponto de vista de jogos. Se você abrir apenas uma guia e executar um jogo JavaScript leve nela, é geralmente tolerável, talvez até imperceptível. Mas se você abrir várias guias, execute algo um pouco mais exigente ou use o Firebug, e você obterá facilmente picos de atraso regulares além de 100 ms.

Eu não faço nenhum teste extenso há algum tempo, mas o Chrome sempre se saiu muito bem nesse sentido, e o IE9 e o Safari aparentemente também fazem um trabalho aceitável.

Eu criei uma ferramenta para testar o atraso do JavaScript, você pode jogar com ele se quiser: http://ebusiness.hopto.org/lagtest/

É difícil dizer sem olhar o código real, mas alguns pontos:

• O flash existe há mais tempo. As pessoas que criam ferramentas e bibliotecas para ele têm mais experiência em lidar com animação. Não sou muito fã das ferramentas e da tecnologia proprietária, mas nunca vou bater em um desenvolvedor do ActionScript que sabe o que está fazendo.

• Os navegadores JIT também são relativamente novos para desenvolvedores de JS. As melhores escolhas para iniciativas de aperfeiçoamento realmente refinadas ainda são algo que estamos escolhendo como comunidade. Defs de função embutida costumavam ser uma coisa burra na fronteira em muitos casos. Agora é uma ótima maneira de aumentar o desempenho em muitos cenários de JIT.

• A normalização para muitos navegadores não precisa, mas geralmente resulta em não aproveitar ao máximo os recursos completos de um determinado navegador.

• (editar: não está bem neste, mas ainda pode haver um ponto aqui - Erik) O plug-in Flash é compatível com vetores e é amplamente entendido como tirar o máximo proveito disso. Ainda não se sabe se os esquemas de herança nos farão muito bem com os objetos de contexto da tela, mas duvido que seja o mesmo grau de vitória que você obtém do vetor.

Uma coisa interessante que me surpreende que ninguém tenha mencionado ainda é a diferença nos tipos de compilação JIT, porque o Flash ainda é compilado por JIT e, na maioria dos navegadores modernos, o JavaScript também é, no entanto, o Flash é uma linguagem fortemente tipada, o que significa existe todo um campo de otimizações que ele pode fazer (como emitir uma chamada para um método diretamente (algo que o JavaScript não pode fazer)), que o JavaScript não pode fazer porque é digitado dinamicamente. Você pode substituir toda a definição de uma função em JavaScript a qualquer momento, e essa nova definição é como deve ser chamada. (ainda é possível para o JavaScript fazer uma chamada indireta que não seria muito mais cara). O acesso ao campo em um campo é realmente um exemplo melhor do que a chamada de método, porque o JavaScript não pode fazer isso indiretamente,

Outra diferença no desempenho é, como já mencionado, o GC. Eu suspeito (não verifiquei) que a maioria dos navegadores usa um GC de contagem de referência (porque toda a memória que o GC alocado para uma página pode ser liberada quando a página é deixada, é realmente um dos melhores lugares para usar um GC de contagem de referência ) ou um GC de varredura conservador (como Boehm). O último pode ser consideravelmente mais lento que o primeiro, se não for implementado corretamente. (Boehm é um exemplo de implementação correta) O Flash, por outro lado, usa um GC preciso (muito mais fácil de fazer em um sistema fortemente tipado). Como o Flash usa um GC preciso, ele não possui a sobrecarga do tempo de execução da contagem de referência. (que não é enorme, mas ainda está lá) Um bom exemplo de um GC preciso é o SGen da Mono, que também compacta os montes.

Depois, chega o fato de que o JavaScript não foi projetado com a animação em mente. (como também foi mencionado) Até onde eu sei, nenhum navegador emitirá instruções no estilo SSE para os loops de animação, onde as funções principais de renderização no Flash provavelmente foram otimizadas manualmente para obter o desempenho máximo. (em alguns lugares sendo gravados em montagem bruta)

Em suma, tudo se resume ao fato de que uma linguagem dinâmica sempre será mais lenta que a de um tipo estaticamente, se tiver que ser compilada em tempo hábil, para não fazer o usuário reclamar da lentidão.

IMHO que diferente vem do fato de que o Flash foi construído do zero para fazer exatamente isso, animações. O Flash implementa técnicas (apesar de mal julgadas importantes) para uma visualização mais suave em execução por padrão, quando em JS você precisaria fazer essas implementações manualmente.

Existem exemplos de ótimas implementações de JS / Canvas rodando ainda melhor que a maioria dos jogos em Flash que eu vejo por aí. Tudo vem para o desenvolvedor fazê-los.

além do GC, aspecto JIT dessas tecnologias, existe uma lacuna entre o uso de hardware.

na versão mais recente do flash player, o flash começou a recorrer à aceleração de hardware para renderizar essas imagens, o que torna o processo de renderização mais rápido e com melhor qualidade. enquanto, por outro lado, os jogos controlados por JS em alguns navegadores (FF, CHROME) ainda não começaram. Porém, houve uma exceção: o navegador IE9 começou a re-arquitetar a partir da camada de abstração de hardware; os navegadores do IE9 fizeram um tremendo progresso no uso da aceleração de hardware; portanto, a renderização de gráficos nesses navegadores é definitivamente melhor e mais rápida do que outros navegadores.