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

8

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?

Antonio
fuente
2
El código flash en el navegador no se compila con anticipación; Flash Player incluye una máquina virtual para interpretar el código. La única plataforma que Flash admite a través de la compilación AOT es iOS.
jhocking

Respuestas:

4

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/

aaaaaaaaaaaa
fuente
De hecho, utilizo Chrome debido a la razón exacta que mencionas anteriormente, casi arrojé la recolección de basura a la mezcla anterior, pero quería mantener la pregunta enfocada. Incluso en Chrome, la recolección de basura aún hace que este desfase visual comparativo parpadee. Entonces, desde una perspectiva ingenua, ¿cuál es la solución a este problema (además de "una mejor recolección de basura")?
Anthony
@Anthony Funny, no veo este problema en Chrome en absoluto, ¿obtienes algo más que barras verdes si ejecutas mi lagtest? Por supuesto, siempre puede escribir un programa que simplemente demore demasiado en ejecutarse en algún momento, ¿está seguro de que ese no es el problema?
aaaaaaaaaaaa
FF ha sido inquietantemente frágil durante los últimos años. No estoy seguro de qué se trata, pero las versiones constantes que no hacen más que obligar a los autores de complementos a adaptarse / actualizarse, mientras que los errores graves se ignoran, huelen a ágil o scrum mal aplicado. Es una maldita vergüenza.
Erik Reppen
3

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.

Erik Reppen
fuente
Necesito leer personalmente algo de la terminología, pero esta también es una gran respuesta.
Anthony
1
Creo que estaba equivocado sobre el lado del vector. Canvas tiene métodos API basados ​​en vectores incorporados. Creo que me corrigieron mal en eso recientemente por alguien que acaba de hacer suposiciones erróneas sobre el hecho de que siempre está generando mapas de bits. He estado leyendo los Gráficos JavaScript sobrealimentados de O'Reilly en el tren y lo recomiendo encarecidamente.
Erik Reppen
3

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.

Rey orvid
fuente
Java también está fuertemente tipado y tiene un alto rendimiento cuando realiza los puntos de referencia. Todavía apostaría por los desarrolladores de Node.js frente a los desarrolladores de Java en un concurso de rendimiento para una aplicación web básica del lado del servidor, asumiendo un nivel de talento mediocre. Los tipos fuertes frente a los débiles son una compensación de diseño, no una garantía de que su aplicación se ejecutará más rápido cuando se deja a manos humanas que hacen cosas estúpidas cuando hay mucho más código para hacer malabares. No es que yo recomendaría escribir un motor 3D en JS, Flash o Java.
Erik Reppen
0

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.

Galvas
fuente
0

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.

zinc
fuente
Como nota al margen, en chrome / ff puede forzar la aceleración de hardware (webgl), ya sea a través de la configuración del código y / o la configuración del navegador, la ligera ventaja está disponible. En cualquier caso, mi suposición es que la implementación en Chrome / FF es aún más inmadura que en IE 9+
Anthony
@ Anthony sí, definitivamente de acuerdo. En la actualidad, en el ámbito de la API de gráficos, DX está excediendo bastante OPENGL, y de ninguna manera que Chrome u otros navegadores pueden funcionar mejor que IE9, al menos por un período corto.
Zinc