¿Qué implicaciones tiene JIT (javascript / canvas) frente a AOT (Flash) en términos del rendimiento del juego basado en el navegador?

En mi experiencia, incluso hasta el día de hoy, todavía veo más un retraso visual en el movimiento / animación de entidades en los juegos basados ​​en JavaScript (Canvas) que en los juegos basados ​​en Flash.

¿Por qué es esto? ¿Cuál es exactamente la discrepancia en el nivel más básico entre un compilador JIT vs AOT en el escenario específico de JavaScript vs. Flash?

No es el método de compilación lo que hace que los juegos se retrasen, es el recolector de basura, y el recolector de basura Flash está separado de los navegadores.

Creo que puedo razonar con bastante confianza que ejecutas Firefox, porque el recolector de basura de Firefox es la peor basura que puedes obtener, desde el punto de vista de los juegos. Si abre solo una pestaña y ejecuta un juego de JavaScript ligero en ella, generalmente es tolerable, incluso puede pasar desapercibido. Pero si abres un montón de pestañas, ejecutas algo un poco más exigente o usas Firebug, obtendrás picos de retraso regulares más allá de los 100 ms.

No he hecho ninguna prueba exhaustiva durante un tiempo, pero Chrome siempre lo ha hecho muy bien en este sentido, y tanto IE9 como Safari aparentemente también hacen un trabajo aceptable.

Creé una herramienta para probar el retraso de JavaScript, puedes jugar con él si quieres: http://ebusiness.hopto.org/lagtest/

Es difícil de decir sin mirar el código real, pero algunos puntos:

• Flash ha existido por más tiempo. Las personas que crean herramientas y bibliotecas para ello tienen más experiencia en el manejo de animación. No soy un gran admirador de las herramientas y la tecnología patentada, pero nunca llamaré a un desarrollador de ActionScript que sepa lo que está haciendo.

• Los navegadores JIT también son relativamente nuevos para los desarrolladores de JS. Las mejores opciones para iniciativas de rendimiento realmente refinadas siguen siendo algo que estamos resolviendo como comunidad. La función def en línea solía ser una tontería límite en muchos casos. Ahora es una excelente manera de aumentar el rendimiento en muchos escenarios JIT.

• La normalización para innumerables navegadores no tiene que hacerlo, pero a menudo resulta en no aprovechar al máximo las capacidades completas de un navegador dado.

• (editar: no está del todo bien en este caso, pero aún podría haber un punto aquí: Erik) El complemento Flash es amigable con los vectores y se entiende ampliamente cómo aprovechar al máximo eso. Queda por ver si los esquemas de herencia nos beneficiarán mucho con los objetos de contexto de lienzo, pero dudo que sea en el mismo grado de ganancia que se obtiene del vector.

Una cosa interesante que me sorprende que nadie haya mencionado todavía es la diferencia en los tipos de compilación JIT, porque Flash todavía está compilado JIT y, en la mayoría de los navegadores modernos, también lo es JavaScript, sin embargo, Flash es un lenguaje fuertemente tipado, lo que significa hay todo un reino de optimizaciones que puede hacer (como emitir una llamada a un método directamente (algo que JavaScript no puede hacer)), que JavaScript no puede hacer porque está escrito dinámicamente. Puede reemplazar la definición completa de una función en JavaScript en cualquier momento que desee, y esa nueva definición es lo que debe llamarse. (todavía es posible que JavaScript haga una llamada indirecta que no sería mucho más costosa). El acceso de campo en un campo es en realidad un mejor ejemplo que la llamada al método, porque JavaScript ni siquiera puede hacer esto indirectamente,

Otra diferencia en el rendimiento es, como ya se mencionó, el GC. Sospecho (no lo he comprobado) que la mayoría de los navegadores usan un GC de recuento de referencia (porque toda la memoria que el GC asignó para una página se puede liberar cuando se deja la página, en realidad es uno de los mejores lugares para usar un GC de recuento de referencia ) o un GC de exploración conservador (como Boehm). Este último puede ser considerablemente más lento que el primero si no se implementa correctamente. (Boehm es un ejemplo de una implementación correcta) Flash, por otro lado, utiliza un GC preciso (mucho más fácil de hacer en un sistema fuertemente tipado). Debido a que Flash utiliza un GC preciso, no tiene la sobrecarga de tiempo de ejecución del recuento de referencias. (que no es enorme, pero sigue ahí) Un buen ejemplo de un GC preciso es el SGen de Mono, que también compacta los montones.

Luego viene el hecho de que JavaScript no fue diseñado con la animación en mente. (como también se mencionó) Hasta donde yo sé, ningún navegador emitirá instrucciones de estilo SSE para los bucles de animación, donde, como las funciones principales de representación en Flash, probablemente se han optimizado a mano para un rendimiento máximo. (en algunos lugares se escriben en ensamblado sin procesar)

En general, todo se reduce al hecho de que un lenguaje dinámico siempre será más lento que uno estáticamente tipado si tiene que compilarse de manera oportuna para no hacer que el usuario se queje de su lentitud.

En mi humilde opinión, esa diferencia proviene del hecho de que Flash fue construido desde cero para hacer exactamente eso, animaciones. Flash implementa técnicas (aunque de forma inadecuada) para una visualización más fluida que se ejecuta de forma predeterminada, cuando en JS necesitaría realizar esas implementaciones manualmente.

Hay ejemplos de excelentes implementaciones de JS / Canvas que funcionan incluso mejor que la mayoría de los juegos Flash que veo. Todo llega al desarrollador haciéndolos.

Aparte del aspecto GC, JIT de estas tecnologías, existe una brecha entre el uso del hardware.

En la última versión de Flash Player, Flash ha comenzado a recurrir a la aceleración de hardware para renderizar esas imágenes, lo que hace que el proceso de renderizado sea más rápido y de mejor calidad. mientras que, por otro lado, los juegos impulsados ​​por JS en algunos navegadores (FF, CHROME) aún no han comenzado esto. Sin embargo, hubo una excepción: el navegador IE9 ha comenzado a rediseñarse a partir de la capa de abstracción de hardware, los navegadores de IE9 han progresado enormemente en el uso de la aceleración de hardware, por lo que la representación gráfica en estos navegadores es definitivamente mejor y más rápida que otros navegadores.