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

8

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.

Anthony
la source
2
Le code Flash dans le navigateur n'est pas compilé à l'avance; Flash Player comprend une machine virtuelle pour interpréter le code. La seule plate-forme prise en charge par Flash via la compilation AOT est iOS.
jhocking

Réponses:

4

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/

aaaaaaaaaaaa
la source
J'utilise en fait du chrome pour la raison exacte que vous énoncez ci-dessus, j'ai presque jeté la collecte des ordures dans le mélange ci-dessus, mais je voulais garder la question ciblée. Même dans Chrome, la récupération de place provoque toujours le flash de ce comparatif de décalage visuel. Donc, d'un point de vue naïf - quelle est la solution à ce problème (à part juste "une meilleure collecte des ordures")?
Anthony
@Anthony Drôle, je ne vois pas du tout ce problème dans Chrome, obtenez-vous autre chose que des barres vertes si vous exécutez mon lagtest? Bien sûr, vous pouvez toujours écrire un programme qui prend trop de temps à exécuter à un moment donné, vous êtes sûr que ce n'est pas le problème?
aaaaaaaaaaaa
FF a été d'une fragilité inquiétante au cours des deux dernières années. Je ne sais pas de quoi il s'agit, mais les versions constantes qui ne font que forcer les auteurs de plug-ins à s'adapter / mettre à niveau tandis que les bogues graves sont ignorés comme une agile mal appliquée ou une mêlée. C'est vraiment une honte.
Erik Reppen
3

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.

Erik Reppen
la source
J'ai besoin de lire personnellement certaines terminologies, mais c'est aussi une excellente réponse.
Anthony
1
Je pense que je me trompais sur le côté vecteur de celui-ci. Canvas a des méthodes d'API vectorielles intégrées. Je pense que j'ai été mal corrigé récemment par quelqu'un qui a fait des hypothèses erronées sur le fait que vous sortez toujours des bitmaps. J'ai lu les graphiques JavaScript suralimentés d'O'Reilly dans le train et je le recommande vivement.
Erik Reppen
3

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.

Orvid King
la source
Java est également fortement typé et très performant lorsque vous effectuez les tests de performance. Je parierais toujours sur les développeurs Node.js contre les développeurs Java dans un concours de performance pour une application Web côté serveur de base en supposant juste au-dessus des niveaux de talent médiocres. Les types forts contre les types faibles sont un compromis de conception, pas une garantie que votre application fonctionnera plus rapidement lorsqu'elle est laissée à des mains humaines qui font des choses stupides quand il y a beaucoup plus de code à jongler. Non pas que je recommanderais d'écrire un moteur 3D en JS, Flash ou Java.
Erik Reppen
0

À 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.

Galvas
la source
0

à 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.

zink
la source
Juste comme une note latérale, dans chrome / ff, vous pouvez forcer l'accélération matérielle (webgl), que cela soit fait via le code et / ou les paramètres de configuration du navigateur, le léger avantage est disponible. En tout cas, mon hypothèse est que l'implication dans chrome / ff est toujours plus immature que dans IE 9+
Anthony
@Anthony oui, définitivement d'accord. De nos jours dans le domaine de l'API graphique, DX dépasse largement OPENGL, et aucun moyen que Chrome ou d'autres navigateurs ne puissent faire mieux qu'IE9, au moins pour une courte période.
zinking