Quelles sont les implications de JIT (javascript / canvas) par rapport à AOT (Flash) en termes de performances de jeu basées sur un navigateur?

D'après mon expérience, même jusqu'à ce jour, je constate encore plus de décalage visuel dans le mouvement / l'animation d'entité dans les jeux basés sur JavaScript (Canvas) que dans les jeux basés sur Flash.

Pourquoi est-ce exactement la différence au niveau le plus basique entre un compilateur JIT vs AOT dans le scénario spécifique de JavaScript vs Flash.

Ce n'est pas la méthode de compilation qui retarde les jeux, c'est le garbage collector et le Flash garbage collector est distinct des navigateurs.

Je pense que je peux raisonnablement penser que vous exécutez Firefox, parce que le garbage collector de Firefox est le pire morceau de merde que vous pouvez obtenir, du point de vue du jeu. Si vous ouvrez un seul onglet et exécutez un jeu JavaScript léger dedans, il est généralement tolérable, voire imperceptible. Mais si vous ouvrez un tas d'onglets, exécutez quelque chose d'un peu plus exigeant ou utilisez Firebug, vous obtiendrez facilement des pointes de décalage régulières au-delà de 100 ms.

Je n'ai pas fait de tests approfondis depuis un certain temps, mais Chrome a toujours très bien réussi à cet égard, et IE9 et Safari semblent également faire un travail acceptable.

J'ai fait un outil pour tester le décalage JavaScript, vous pouvez jouer avec si vous le souhaitez: http://ebusiness.hopto.org/lagtest/

C'est difficile à dire sans regarder le code réel mais quelques points:

• Le flash existe depuis plus longtemps. Les personnes qui créent des outils et des bibliothèques pour cela ont plus d'expérience dans la gestion des animations. Je ne suis pas un grand fan des outils et de la technologie propriétaire, mais je ne frapperai jamais un développeur ActionScript qui sait ce qu'il fait.

• Les navigateurs JIT sont également relativement nouveaux pour les développeurs JS. Les meilleurs choix pour des initiatives de perfectionnement vraiment raffinées sont toujours quelque chose que nous essayons de définir en tant que communauté. Les définitions de fonction en ligne étaient autrefois une chose stupide à faire dans de nombreux cas. C'est maintenant un excellent moyen d'augmenter la performance dans de nombreux scénarios JIT.

• La normalisation pour une multitude de navigateurs ne doit pas nécessairement, mais a souvent pour résultat de ne pas tirer pleinement parti des capacités complètes d'un navigateur donné.

• (modifier: pas tout à fait raison sur celui-ci mais il pourrait y avoir un point ici - Erik) Le plug-in Flash est compatible avec les vecteurs et il est largement compris comment tirer le meilleur parti de cela. Il reste à voir si les schémas d'héritage nous feront une tonne de bien avec les objets de contexte de canevas, mais je doute que ce soit au même degré de victoire que vous sortirez du vecteur.

Une chose intéressante que je suis surpris que personne n'a encore mentionné est la différence dans les types de compilation JIT, car Flash est toujours compilé JIT, et, dans la plupart des navigateurs modernes, JavaScript aussi, mais Flash est un langage fortement typé, ce qui signifie il y a tout un éventail d'optimisations qu'il peut faire (comme émettre directement un appel à une méthode (quelque chose que JavaScript ne peut pas faire)), que JavaScript ne peut pas faire car il est typé dynamiquement. Vous pouvez remplacer la définition entière d'une fonction en JavaScript à tout moment que vous voulez, et cette nouvelle définition doit être appelée. (il est toujours possible pour JavaScript de faire un appel indirect qui ne serait pas beaucoup plus cher cependant) L'accès aux champs sur un champ est en fait un meilleur exemple que l'appel de méthode, car JavaScript ne peut même pas le faire indirectement,

Comme nous l'avons déjà mentionné, une autre différence de performances est le GC. Je soupçonne (je n'ai pas vérifié) que la plupart des navigateurs utilisent soit un GC de comptage de référence (car toute la mémoire allouée au GC pour une page peut être libérée lorsque la page est laissée, c'est en fait l'un des meilleurs endroits pour utiliser un GC de comptage de référence ), ou un GC à balayage conservateur (comme Boehm). Ce dernier peut être considérablement plus lent que le premier s'il n'est pas correctement mis en œuvre. (Boehm est un exemple d'une bonne implémentation) Flash d'autre part utilise un GC précis (beaucoup plus facile à faire dans un système fortement typé). Parce que Flash utilise un GC précis, il n'a pas la surcharge d'exécution du comptage de référence. (qui n'est pas énorme, mais qui est toujours là) Un bon exemple de GC précis est le SGen de Mono, qui compacte également les tas.

Ensuite vient le fait que JavaScript n'a pas été conçu avec l'animation à l'esprit. (comme cela a également été mentionné) Pour autant que je sache, aucun navigateur n'émettra d'instructions de style SSE pour les boucles d'animation, où les fonctions de rendu principales de Flash ont probablement été optimisées à la main pour des performances optimales. (à certains endroits, écrit en assemblage brut)

Dans l'ensemble, cela revient au fait qu'un langage dynamique sera toujours plus lent qu'un langage statiquement typé s'il doit être compilé en temps opportun afin de ne pas faire se plaindre l'utilisateur de sa lenteur.

À mon humble avis, cette différence vient du fait que Flash a été construit à partir du sol pour faire exactement cela, des animations. Flash implémente (même si mal à en juger par les principaux jugements) des techniques de visualisation plus fluide exécutées par défaut, alors que dans JS, vous devrez effectuer ces implémentations manuellement.

Il existe des exemples de grandes implémentations de JS / Canvas fonctionnant encore mieux que la plupart des jeux Flash que je vois. Tout revient au développeur qui les fabrique.

à part l'aspect GC, JIT de ces technologies, il y a un écart entre l'utilisation du matériel.

Dans la dernière version de Flash Player, Flash a commencé à recourir à l'accélération matérielle pour le rendu de ces images, ce qui rend le processus de rendu plus rapide et de meilleure qualité. tandis que d'autre part, les jeux pilotés par JS sur certains navigateurs (FF, CHROME) n'ont pas encore commencé. Il y avait une exception cependant, le navigateur IE9 a commencé à se ré-architecturer à partir de la couche d'abstraction matérielle, les navigateurs d'IE9 avaient fait d'énormes progrès dans l'utilisation de l'accélération matérielle, ainsi le rendu graphique sur ces navigateurs est définitivement meilleur et plus rapide que les autres navigateurs.