Discussion :

[kimjoa]

et tu a une demo du player ayant moi meme fait un player en js j'aurait voulu comparer le js generé et aussi le dart créé

J'aime bien dart, le langage est assez séduisant, mais il s'éloigne trop du javascript pour que la compilation soit clean. Il ont fait des progrès depuis novembre dernier, mais c'est pas encore ça. Quelques bench , mais qui date.... Les prochains bench seront sans doute plus satisfaisant.

J'ai compilé l'exemple fournit par l'éditeur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import 'dart:html';
 
num rotatePos = 0;
 
void main() {
  query("#text")
    ..text = "Click me!"
    ..on.click.add(rotateText);
}
 
void rotateText(Event event) {
  rotatePos += 360;
  query("#text").style
    ..transition = "1s"
    ..transform = "rotate(${rotatePos}deg)";
}

A noter les deux points, vraiment pratique !

Le résultat est un fichier de 127 ko ....
Mais c'est pas vraiment le poids qui pose problème, la base du code js servant au binding sera dilué par la taille du projet.
En examinant vite fait le code produit, je me suis rendu compte qu'un appel de fonction en dart, pouvait correspondre en javascript à 4 ou 5 appels voir plus.
De ce point de vue typescript s'en sort bien mieux avec une génération vraiment très propre.

[PasteFinger]

Pour que Dart soit adopté, il faudrait qu'il offre des performances très supérieures à Javascript !

[_skip]

Ce sera surement possible s'il tourne dans dartvm car dart n'a pas toute une série des biais de javascript qui rendent le "jit" difficile à optimiser.

En revanche, traduit en javascript... Je comprend que ça devra s'améliorer. Même si je pense que la vitesse d'exécution ne repose pas forcément sur le code lui-même, la plupart des manipulations de tous les jours (sauf bien sûr les jeux, les canvas) sont déjà rapides, donc même 2-5 fois plus lentes ce serait encore plus rapide que l'utilisateur. Sans compter que les "opérations lentes" comme les appels ajax iront toujours à la même vitesse.

Je suis pas sûr que ce soit bloquant cette affaire de performance JS moins bonne si de l'autre côté on gagne suffisamment en maintenance et en productivité.

[pierre-y]

Bonsoir,

En lisant la discussion j'ai deux questions qui me tique :

premièrement : Est ce qu'une modification en profondeur de javascript est réellement nécessaire?

Deuxièmement : si oui, pourra t'elle voir le jour autrement que par un pluging (un peut comme unity3d ou adobe player mais libre) par exemple étant sonné la concurrence que les firme se livre entre elle pour imposer leur programme? Je vois mal Dart par exemple être accepté sans bronché par microsoft et apple et ceci même dans l'hypothèse ou il serait parfait.

Bonne soirée,

[rt15]

premièrement : Est ce qu'une modification en profondeur de javascript est réellement nécessaire?

Le javascript a été conçût pour ajouter un soupçon de dynamicité au HTML. Le problème est qu'il est utilisé de façon intensive de nos jours, dans des applications de plus en plus complexes et sur des appareils plus ou moins puissants comme les smartphones. Il s'agit d'un langage de script et de haut niveau donc ses performances à l'exécution ne pourraient pas être pires, malgré les efforts des navigateurs. Côté développement, son modèle objet original déroute certains développeurs, et il n'est pas du tout rigoureux.

Cela dit l'approche de google et M$ ne me paraissent pas optimale, que ce soit à ajouter un autre moteur de script au navigateur (Pour exécuter directement du dart), ou pour générer du javascript à partir d'un autre langage.

Côté navigateur, il serait bien plus efficace et optimisé qu'ils exécutent un langage intermédiaire type byte code, facilement compilable en langage machine du processeur de la machine.

Côté développeur, on devrait pouvoir utiliser le javascript, pourquoi pas... Mais pas seulement. Tout autre langage, par exemple plus stricte, devrait pouvoir être utilisé aussi. Et tout ces autres langages pourraient se compiler vers un byte code au final envoyé au navigateur.

En fin de compte cela revient au modèle java, compile once, run everywhere. Et ce modèle à justement beaucoup plus de sens dans un navigateur que pour des logiciels desktop, où il est souvent intéressant voir obligatoire d'intégrer le logiciel à l'OS.

Deuxièmement : si oui, pourra t'elle voir le jour autrement que par un pluging (un peut comme unity3d ou adobe player mais libre) par exemple étant sonné la concurrence que les firme se livre entre elle pour imposer leur programme? Je vois mal Dart par exemple être accepté sans bronché par microsoft et apple et ceci même dans l'hypothèse ou il serait parfait.

Évidement, pour remplacer le javascript dans tous les navigateurs, ou du moins apporter une nouvelle toute nouvelle version de javascript, il faut que rapidement, les principaux navigateurs (Chrome, Firefox, Internet Explorer, Opera, Safari) supporte cette nouvelle fonctionnalité.

Ce qui pourrait aider, bien sûr, c'est que cette nouvelle technologie soit poussée par le w3c... On voit ce que ça donne avec le HTML5.

Mais il ne faut pas être négatif : si la techno commence à devenir à la mode (Ce qui veut pas dire qu'elle est bonne), elle peut tout à fait être prise en charge relativement rapidement. Prenons le cas de javascript lui même qui vient de netscape ou de XMLHttpRequest et donc AJAX qui vient de internet explorer.

[Uther]

premièrement : Est ce qu'une modification en profondeur de javascript est réellement nécessaire?

Tout dépend ce que l'on veut en faire :
- Pour continuer a faire de simple manipulation du DOM : probablement pas.
- Pour faire des applications complexes en offrant un minimum de cadrage aux programmeurs : oui, mais les surcouches déjà existantes comme GWT, Coffescript, Typescript, ... permettent déjà de le faire.
- Pour faire des applications avec des performances comparables au natif : oui.

Deuxièmement : si oui, pourra t'elle voir le jour autrement que par un pluging (comme adobe player mais libre) par exemple étant sonné la concurrence que les firme se livre entre elle pour imposer leur programme? Je vois mal Dart par exemple être accepté sans bronché par microsoft et apple et ceci même dans l'hypothèse ou il serait parfait.

C'est en effet là tout le problème. Google avec son travail solitaire va avoir du mal à convaincre les autres acteurs du web d'y adhérer.

Quant au plug-in je pense que ça serait difficilement défendable car c'est contraire à la tendance actuelle qui est au contraire de se débarasser des plugins pour se contenter du standard.

[Cyrano]

premièrement : Est ce qu'une modification en profondeur de javascript est réellement nécessaire?

J'avais déjà donné un élément de réponse sur ce point l'an dernier :

...Le grand truc actuellement, c'est le SaaS et Google n'est pas en reste à ce chapitre avec entre autres choses les Google Docs. Mais ce sont des application qui font appel à du JavaScript et les projets d'évolution des applications chez Google doivent commencer à titiller les limites du JavaScript. Donc l'idée d'un nouveau langage, outre des performances meilleures, présentera à n'en pas douter des possibilités inenvisageables en JavaScript.

Et comme vient de le souligner également Uther, pour de simples manipulations de base, c'est un peu sans intérêt, donc ça ne concernera pratiquement aucun petit site perso.

Deuxièmement : si oui, pourra t'elle voir le jour autrement que par un pluging (un peut comme unity3d ou adobe player mais libre) par exemple étant sonné la concurrence que les firme se livre entre elle pour imposer leur programme? Je vois mal Dart par exemple être accepté sans bronché par microsoft et apple et ceci même dans l'hypothèse ou il serait parfait.

Là, ça va dépendre des éditeurs de navigateurs. Il y a fort à parier que ni Microsoft ni Apple ne vont se précipiter dans la voie ouverte par Google. Par ailleurs, j'ai cru comprendre que Microsoft travaillerait actuellement sur un système similaire, mais bien entendu propre à Microsoft. Donc ça risque d'être une nouvelle compétition.
Ça risque aussi de dépendre pas mal des éditeurs de solutions en ligne et des besoins techniques que ça représente. Si les applications proposées présentent des fonctionnalités qui ne peuvent fonctionner qu'avec un langage comme Dart, on peut penser qu'ils pousseront à la roue pour que les navigateurs intègrent Dart, à moins que les versions générée en JavaScript soient vraiment encore assez efficaces, mais ça j'y crois moins. Ce qui décidera donc les uns et les autres à se tourner vers une solution commune, ce seront à mon avis d'abord les utilisateurs qui demanderont de plus en plus de fonctionnalités dans les applications en ligne, fonctionnalités qu'il sera difficile de construire en JavaScript sans créer des usines à gaz invraisemblables.

Le succès de Dart pourrait passer par Mozilla pour déclencher le mouvement : c'est aussi une question de popularité des navigateurs utilisés sur le marché et ce qu'en font les utilisateurs. Or avec Chrome et Firefox en locomotive, si Dart fonctionne vraiment bien, ça pourrait inciter les autres à suivre et à implémenter Dart dans leur propre navigateur, donc en fin de compte, Internet Explorer, Opera et Safari pourraient un jour intégrer Dart... on peut rêver

[Uther]

Le succès de Dart pourrait passer par Mozilla pour déclencher le mouvement

N'y compte pas trop.
Mozilla a clairement indiqué qu'il ne prévoyait pas de supporter Dart. Ils comptent se limiter à améliorer les performances de Javascript.

[Invité]

et tu a une demo du player ayant moi meme fait un player en js j'aurait voulu comparer le js generé et aussi le dart créé

Je n'est pas vraiment de version stable, c'était surtout un "test".
j'essai actuellement de coder un projet perso avec Symfony et utiliser Dart en remplacement de Js afin de vraiment comparer la différence en mode projet.

[...]
Tout autre langage, par exemple plus stricte, devrait pouvoir être utilisé aussi. Et tout ces autres langages pourraient se compiler vers un byte code au final envoyé au navigateur. [...]

J'aime beaucoup cette idée, c'est vraiment très pertinent.


Pour ma part, ce que j' apprécie dans le projet Dart en lui même, c'est la question de fond qu'il soulève. D'un côté dart, de l'autre TypeScript, ainsi que toutes les librairies JS (jQuery, YUI...), révèle que JavaScript atteint ses limites.

Javascript n'est pas un langage conçu pour le développement de Wep App. Donc soit celui-ci reste dans sa trame actuelle (petite manipulation de DOM, Ajax, deux trois autres interactions), soit il est amené à évoluer en profondeur.

Je ne pense pas que celui-ci soit amené à beaucoup évolué, et si c'est le cas, j’espère vraiment que ça ne prendra pas 7 ans comme pour l'HTML5....

Les point positif de Dart, pour ma part, et sa modernité, certes une nouvelle Api est à apprendre, mais un langage objet, c'est un langage objet, ils ont tous les mêmes bases, la même approche, c'est un réel confort pour le développeur.
Gagner en homogénéité c'est gagner en maintenabilité et productivité, aujourd'hui je fais encore beaucoup de JavaScript, mais plus le temps passe et plus j'ai l'impression de le subir. Je conçois difficilement l'idée de développer des milliers de lignes pour une application avec un langage aussi permissif, je ne parviens pas à faire suffisamment confiance à ce langage.

[LLB]

Côté navigateur, il serait bien plus efficace et optimisé qu'ils exécutent un langage intermédiaire type byte code, facilement compilable en langage machine du processeur de la machine

En vrai, ça n'apporte pas grand-chose. Si tu veux, tu peux aussi considérer Dart comme un bytecode et avoir ton langage préféré qui compile vers Dart. Les raisons détaillées se trouvent là : http://www.dartlang.org/articles/why-not-bytecode/
(si besoin, je peux expliquer davantage)

[Uther]

J'ai lu cet article mais il se base principalement sa critique sur le bytecode Java, qui même s'il est actuellement utilisé par plusieurs langages, a clairement été conçu a l'origine dans l'optique de supporter seulement Java.
Si on compare a un bytecode conçu pour être utilisé par de multiples langages, par exemple le LLVM IR, la majorité des problèmes avancés disparaissent.

Si on considère Dart comme un bytecode (d'ailleurs autant le faire avec Javascript), on tombe justement en plein dans les problèmes mentionnés dans l'article, et en plus on oblige l'interpréteur a se farcir une analyse lexicale/syntaxique supplémentaire ainsi qu'une bonne partie des optimisations.

[LLB]

Si on compare a un bytecode conçu pour être utilisé par de multiples langages, par exemple le LLVM IR, la majorité des problèmes avancés disparaissent.

Mais d'autres apparaissent.

On a un choix à faire : veut-on un bytecode bas-niveau (LLVM) ou plus haut-niveau (.NET, JVM) ?

Si on part sur du bas-niveau, on a un système de typage très simple, pas d'orienté-objet, pas de convention d'appel définie (chaque compilo peut choisir la sienne), etc. C'est très flexible et on peut avoir beaucoup de langages qui compilent vers ce byte-code. Chaque langage construit son système de typage par dessus, etc. J'aime beaucoup LLVM, mais ça détruit quasiment toute interopérabilité entre les langages. Si j'écris une bibliothèque dans un langage, comment fera quelqu'un d'autre pour l'utiliser dans un autre langage ? Ce n'est pas possible si les deux langages ont des conventions d'appel différentes. Comment passer un argument à une fonction, si les deux langages n'ont pas le même système de typage, si chaque langage doit définir ses vtables pour implémenter l'objet, etc. ? Même les types de base peuvent être implémentés différemment, les entiers (natifs, 64 bits, bigints ?), les strings (utf-8, utf-16, terminés par un 0 ?), les flottants (simple, double, decimal 128 bits ?). Et qu'en est-il du format des exceptions ?
Mais en fait, si on veut interagir avec le navigateur, le dom, les fonctions prédéfinies, il faut un truc un peu plus haut-niveau que LLVM.

Prenons .NET (j'ai travaillé sur plusieurs compilos .NET) : ça a été conçu pour être multi-langage. Oui, c'était un objectif depuis le tout début. Ils ont plutôt bien réussi en faisant du bytecode orienté-objet d'assez haut-niveau : avec le système de type commun, on peut passer des objets d'un langage à l'autre (bon, ça dépend aussi du langage, certains ajoutent une trop grosse surcouche), hériter d'une classe définie dans un autre langage, récupérer une exception lancée dans un autre langage, etc. C'est en quelque sorte ce qu'il faudrait pour un bytecode commun dans un navigateur. Mais ce n'est pas parfait, certains langages sont difficiles à implémenter (Haskell, etc.), et on retrouve les arguments contre le bytecode Java.

Si on considère Dart comme un bytecode (d'ailleurs autant le faire avec Javascript), on tombe justement en plein dans les problèmes mentionnés dans l'article, et en plus on oblige l'interpréteur a se farcir une analyse lexicale/syntaxique supplémentaire ainsi qu'une bonne partie des optimisations.

L'analyse syntaxique est rapide. La majorité des optimisations sont faites dans la VM de toute façon. Par exemple, les compilos pour .NET (C#, F# et et probablement les autres aussi) n'optimisent quasiment rien en pratique, c'est le JIT qui s'occupe de l'inlining, de dérouler les boucles, etc. Pour LLVM, c'est pareil : les développeurs de compilo utilisent LLVM en bonne partie pour ne pas avoir à faire toutes ces optimisations classiques et indépendantes du langage.
Le gain de temps me semble donc assez négligeable.

Ah, et puis : débugguer du code dans le navigateur est beaucoup plus simple quand le navigateur a accès au code, qu'il comprend le code et les types utilisés, et peut proposer une console pour exécuter du code. Note aussi que la fonction eval est difficile à offrir quand le navigateur ne connait que le bytecode.

[rt15]

Avoir des librairies avec une interface de bas niveau, c'est au contraire un avantage fondamental quand on souhaite pouvoir les attaquer facilement depuis n'importe quel langage.
Faisons le parallèle avec le desktop. Si M$ avait choisit que les API de Windows soient uniquement en .NET... La JVM serait par exemple assise au dessus d'une autre VM ! Les objets java devraient être traduis vers des objets .NET au sein de la JVM... Ça ferait un de ces boxons. Et imaginez les perfs... D'ailleurs on y arrive presque avec WinRT qui veut imposer du COM v2.0.

Autre exemple : combien d'appli C, C++ ou java appel des librairies .NET ?? Ça se voit jamais. Le plus simple dans ces cas là est bien souvent de passer par des sockets, et là on parle plus vraiment de librairie... Mais combien d'appli .NET appellent des librairies en C ? Des tas. Certaines appli .NET sont bourrées de PInvoke. Pour le java c'est globalement la même chose. On a parfois besoins de faire des dll et de les appelées par JNI quand la JVM ne propose pas ce qui est souhaité. Mais créé des objets java depuis le C se fait aussi très rarement quoique ce soit possible, mais lourd. Bilan, les librairies avec une ABI de bas niveau sont largement utilisées, celle avec un ABI de haut niveau le sont nettement moins.

Alors oui, le DOM devrait à mon sens être proposé sous formes de fonctions très bas niveau. Libre à chacun de construire tout ce qu'il veut par dessus. C'est le rôle d'une librairie de haut niveau de cacher ces détails. Libre à chacun d'utiliser ou d'écrire une surcouche adaptée au langage. Combien de wrappers vers des librairies bas niveau C sont dans la nature ? Combien de sandwichs à n'en plus finir dans les logiciels actuel ? Combien y a-t-il de couche dans une techno comme XNA ? Et généralement les couches bas niveau sont en bas, les couches haut niveau sont en haut. Le navigateur est supposé être la base, il doit proposer une couche bas niveau.

Bien sûr resterait le problème qu'une librairie écrite en "Java pour browser" ne serait pas utilisable depuis du "javascript pour browser" à l'opposé du .NET ou une librairie écrite en VB.NET est utilisable depuis du C#... Alors, oui, là il faut que les concepteurs de ses langages se mettent d'accord sur une ABI. Mais ils sont libres de le faire comme il le souhaite, ce n'est pas le byte code qui va les limiter avec un entier signé sur 32 bits et pas autre chose.

Ensuite, concernant l'analyse syntaxique rapide...

En règle générale, une compilation complète se fait en une série d'étape :
Le source code en lui même est "lu" par un analyseur lexical. Cet analyseur ne fait que transformer le texte en "tokens" qu'il envoie ce qu'il lit à un parser. Cette partie là est facilement implémentable à l'aide d'équivalent de lex et yacc. Ce qui ne veut pas dire que c'est rapide à l'exécution. En effet, il peut y avoir tout bêtement des commentaires, des noms de variables à rallonges, les instructions sont désordonnées, les données tel que le texte sont mélangées aux instructions d'exécutions, il y a des tas de fichiers... Bref, un code source, c'est pas déjà pas très facile à lire.

Ensuite, le boulot du parser va généralement être de construire un arbre lexical. Cet arbre représente le déroulement des instructions.

Toute cette première partie du compilo est dans le cas de gcc, ce qu'on appelle un front-end. Et dans le cas de gcc, il y a différents front-end pour différents langages, avec au final souvent production d'une forme intermédiaire : un arbre lexical ou d'un genre de graph.

Ça pas ce qu'il y a de plus rapide... Car un arbre pleins de feuilles c'est assez lourd à créer et à manipuler. En général, c'est à cet étape qu'une première passe d’optimisation est fait. Par exemple, c'est là que si à un endroit il y a 3 feuilles : "2" "+" "2", il va remplacer le tout par une feuille "4". Il va aussi chercher les valeurs utilisées de manière redondante pour ne les avoir qu'une seule fois au final. C'est généralement là aussi qu'il y a détection du code mort. Bref, la plupart des optimisations sont réalisées à cette étape et elles sont tout à fait indépendante de la plateforme cible. Et je serais surpris que le compilo C# ne fasse rien de similaire avant de produire le byte code...

L'étape finale consiste souvent à générer directement le code cible à partir de l'arbre. C'est le rôle du back-end. Et là aussi, pour gcc, il y a différents back-end pour différentes plateformes.

Dans le cas ou le code cible est en fait lui aussi un code intermédiaire, à l'exécution, c'est généralement un nouveau compilo JIT qui va prendre le relais. Mais ce qu'il a à manger, c'est un byte code bien aligné, pas du source, et sur lequel les optimisations indépendantes de la plateforme ont déjà été faites.

Alors pourquoi ne pas envoyer au navigateur directement le byte code, ou au moins l'arbre de la représentation intermédiaire, déjà optimisé de manière indépendante de la plateforme ?

Les temps d'analyse du source et d'optimisation génériques ne sont dans certains cas pas du tout négligeable. Suffit de comparer les temps de compilation de X lignes de C++ avec la compilation de X lignes de C. Le back-end du compilo est probablement le même, pourtant le "haut niveau" du C++, on le sent passer.

Concernant le dernier argument sur le débogage... Pour les langage compilés, on a des débogueurs qui marche pas trop mal me semble. Pas souvent que l'on ait à déboguer du MSIL ou du byte code java. Suffit que les navigateurs permettent à un débogueur de se connecter.

[LLB]

Faisons le parallèle avec le desktop. Si M$ avait choisit que les API de Windows soient uniquement en .NET... La JVM serait par exemple assise au dessus d'une autre VM ! Les objets java devraient être traduis vers des objets .NET au sein de la JVM... Ça ferait un de ces boxons. Et imaginés les perfs...

Ça ferait un boxon et ce serait lent si Windows utilisait du bytecode pour son API... donc, tu proposes d'utiliser du bytecode dans le navigateur à la place de Dart. OK.
Cela dit, la comparaison ne tient pas : dans Windows, ils ont optimisé pour les performances (dont les binaires natifs), tandis que dans un navigateur on veut de la portabilité et de la sécurité. Les perfs ne viennent qu'après. On ne veut pas envoyer de code natif au navigateur.

En règle générale, une compilation complète se fait en une série d'étape :
Le source code en lui même est "lu" par un analyseur lexical. Cet analyseur ne fait que transformer le texte en "tokens" qu'il envoie ce qu'il lit à un parser. Cette partie là est facilement implémentable à l'aide d'équivalent de lex et yacc. Ce qui ne veut pas dire que c'est rapide à l'exécution. En effet, il peut y avoir tout bêtement des commentaires, des noms de variables à rallonges, les instructions sont désordonnées, les données tel que le texte sont mélangées aux instructions d'exécutions, il y a des tas de fichiers...

C'est une blague ?
Écris un hello world en C, compile-le. Ajoute 2000 lignes de commentaires, compile à nouveau. Tu as remarqué une différence de temps de compilation ? À moins d'être resté bloqué en 1970 ou d'avoir un problème de disque, non. Recommence ce test en ajoutant des variables à ralonge. Recommence encore en ajoutant des espaces, etc. Non, ignorer des commentaires ne prend pas de temps significatif...
D'ailleurs, les commentaires sont rarement vus, puisque les développeurs Javascript aiment minifier leur code. Et les commentaires sont supprimés non pas pour le compilateur, mais pour réduire la taille du fichier (pour le réseau).
En passant : avoir les noms de variable dans le bytecode serait utile pour le débogage.

Toute cette première partie du compilo est dans le cas de gcc, ce qu'on appelle un front-end. Et dans le cas de gcc, il y a différents front-end pour différents langages, avec au final souvent production d'une forme intermédiaire : un arbre lexical ou d'un genre de graph.

Ça pas ce qu'il y a de plus rapide... Car un arbre pleins de feuilles c'est assez lourd à créer et à manipuler.

La construction de l'AST est triviale, et le coût est faible par rapport à tout ce que le compilo fait par la suite, qui nécessite également des graphes à construire et à manipuler.

Il va aussi chercher les valeurs utilisées de manière redondante dans pour ne les avoir qu'une seule fois au final. C'est généralement là aussi qu'il y a détection du code mort. Bref, la plupart des optimisations sont réalisées à cette étape et elles sont tout à fait indépendante de la plateforme cible.

C'est faux. Enfin, c'est vrai pour les compilos traditionnels, mais ce n'est plus tout à fait le cas depuis les JIT.

Et je serais surpris que le compilo C# ne fasse rien de similaire avant de produire le byte code...

Il fait quelques optimisations simplistes. C'est vrai, il simplifie les expressions triviales à ce moment là (ton 2+2=4). Cette simplification n'est pas vraiment là pour optimiser, mais parce que c'est obligatoire d'après les specs : c'est nécessaire pour afficher certains warnings et messages d'erreur. Le compilo détecte aussi le code mort, mais le but est de réduire la taille du binaire généré. D'ailleurs le JIT supprime lui aussi le code mort. Les optimisations du compilo C# restent des optimisations triviales et (à ma connaissance) ne fait pas d'optimisation cross-module.
Le compilo F# fait encore moins d'optimisations (sauf que lui sait faire de l'inlining de lambdas d'un fichier à l'autre, mais c'est vraiment une spécificité de F#).

90% des optimisations sont faites dans le JIT. Par exemple, l'inlining de fonctions se fait dans le JIT parce que 1) l'inlining se fait ou non suivant la taille des instructions générées (le compilo C# ne peut pas deviner) et 2) ça dépend de la machine cible (on inline pas la même chose en 32 bits ou en 64 bits par exemple). C'est le JIT qui déroule les boucles. C'est le JIT qui choisit s'il faut vérifier l'indice avant un accès dans un tableau (ou qui prouve que l'indice est forcément valide). C'est le JIT encore qui fait l'expansion et la spécialisation des generics.

L'étape finale consiste souvent à générer directement le code cible à partir de l'arbre. C'est le rôle du back-end.

Oui, et c'est autrement plus coûteux que d'ignorer les commentaires ou de traiter des noms de variables à rallonge. Transformation du code en forme SSA, propagation des constantes, optimisations des boucles (fusionner deux boucles ou au contraire couper une boucle en deux), allocation des registres avec coloriage de graphe, choisir les instructions en fonction de l'architecture cible, réordonner les instructions pour améliorer le parallélisme, etc.

Si tu veux avoir un aperçu de ce que fait LLVM, voici une liste des passes : http://llvm.org/docs/Passes.html

Alors pourquoi ne pas envoyer au navigateur directement le byte code, ou au moins l'arbre de la représentation intermédiaire, déjà optimisé de manière indépendante de la plateforme ?

Soit tu as un bytecode spécialisé, et dans ce cas ça revient presque au même que de travailler sur le langage source.
Soit tu veux un bytecode générique qui convienne à tous les langages (en vrai, ça n'existe pas) et dans ce cas tu n'as pas autant de performance qu'une VM spécialisée pour un langage.
Par exemple, LLVM est mal adapté aux langages dynamiques, d'où l'intérêt d'avoir Parrot.

Les temps d'analyse du source et d'optimisation génériques ne sont dans certains cas pas du tout négligeable. Suffit de comparer les temps de compilation de X lignes de C++ avec la compilation de X lignes de C.

C'est un cas extrême, puisque les templates sont exécutés à la compilation et génèrent du code. Dans les autres langages, les génériques n'ont pas ce souci. Ce serait donc idiot de mettre les templates de C++ dans Dart et de les implémenter comme en C++ (c'est le boulot du JIT, ça). C# et Go sont bien plus rapides à compiler que C++.

Concernant le dernier argument sur le débogage... Pour les langage compilés, on a des débogueurs qui marche pas trop mal me semble. Pas souvent que l'on ait à déboguer du MSIL ou du byte code java. Suffit que les navigateurs permettent à un débogueur de se connecter.

Si on résume, tu proposes qu'ils codent une VM performante et générique (ce qui n'existe pas actuellement). Ensuite, pour chaque langage, il faudrait faire un compilo qui fasse une tonne d'optimisations, une bibliothèque standard (c'est beaucoup de boulot ça) et un débogueur qui s'attache sur chaque navigateur. Tu n'as pas l'impression que ça représente 10 fois plus de boulot, pour un résultat très incertain ?

[Uther]

Je me permet de remonter le sujet, vu que l'on discutait de l’intérêt d'un bytecode commun, et que ça rentre dans le sujet.

Il semble maintenant se dégager une nouvelle voie qui semble réunir pas mal d'avantage : asm.js.

asm.js est un sous ensemble restreint du Javascript qui écarte tous les éléments complexes qui limitent les possibilités d'optimisation, comme le recours au typage dynamique.
Les interpréteurs adaptés à traiter ce type de code seront ainsi capable, de compiler de manière optimale comme un vrai bytecode. Ceux qui ne le sont pas l’exécuteront normalement.
L'idée est de permettre de faire un programme dans le langage que l'on souhaite et le compiler ça avec un compilateur de type emscriptem qui saura produire du javascript compatible asm.js.

Au final on reviens a l'idée du bytecode commun, mais on garde la compatibilité. La branche nightly de Firefox, commence déjà a supporter asm.js et les performances semblent selon, les premiers test seulement 2 fois inférieures au C. Ça parait assez encourageant.

[Cedric Chevalier]

dart2js traduit du code Dart en JavaScript
qui serait plus performant que son équivalent idiomatique, le langage de Google évolue

Une nouvelle version du compilateur dart2js est disponible. Pour rappel, ce dernier permet de convertir en JavaScript du code Dart.

Le nouveau dart2js permet de produire du code JavaScript plus compact et rapide grâce notamment à une innovation inédite appelée « global type inferencing ». Avec cette dernière, le compilateur en analysant entièrement du code Dart, produit un équivalent JavaScript plus compact et performant, dans lequel sont éliminées les lignes contenant les mots clés « Bailout », « typeof » ajoutées par l’ancien compilateur. De plus, ce nouveau compilateur change les boucles While en boucles For et les appels de fonctions sont remplacés par les champs d’accès.

Par ailleurs, on note également que dart2js gère mieux les dépassements de capacité de liste. En effet, là où JavaScript retourne une valeur indéfinie, Dart lève une exception qui sera utilisée par le compilateur pour générer un code qui avertirait le programmeur si celui-ci voulait avoir accès à un élément d’une liste de rang supérieur à sa taille totale.

En outre, des bancs d’essai ont été réalisés avec du code JavaScript généré par ce nouveau compilateur et leur équivalent idiomatique dans le moteur JavaScript V8 de Google. Il en ressort que le code généré par le compilateur est un poil plus performant que son équivalent idiomatique.

Nicolas Geoffray, contributeur du projet dart2js montre dans une vidéo de nombreux exemples de code Dart traduit en JavaScript par l’ancien compilateur et le nouveau avec son innovation inédite.

[ame="http://www.youtube.com/watch?v=rbLkYlbEZ1E"]Dart2js[/ame]

L’objectif de Google avec Dart est de proposer une alternative au langage JavaScript, qui offre la même flexibilité que celui-ci, mais qui se distingue par son typage fort et optionnel. Il est vu comme un JavaScript-killer. Mozilla propose également asm.js, un sous-ensemble restreint du JavaScript qui écarte tous les éléments complexes qui limitent les possibilités d'optimisation. Quant à Microsoft, TypeScript a été développé comme un sur-ensemble de JavaScript pour l’optimiser.

Preuve que JavaScript a de gros manquements, mais demeure cependant un langage clé ?

Le projet Dart sur GitHub

Source : Google

[jmnicolas]

De plus, ce nouveau compilateur change les boucles While en boucles For

Je saisis pas en quoi une boucle for serait plus performante qu'une boucle while c'est pas du tout le même usage

Si quelqu'un veut bien m'expliquer.

[_skip]

En fait, je ne sais pas si ce point précis est une question de performance. Je pense surtout au fait qu'avant une boucle for en dart était réécrite sous forme de while avec la syntaxe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
while(true) {
 
  if( [conditionSortie] ) {
     break;
  }
}

Ca pouvait être assez peu lisible, maintenant est-ce que question performance ça change réellement? Je sais pas, cela dépendrait surtout de l'intelligence de l'interpréteur / Jitter...

EDIT: Je viens de voir qu'il y a un exemple précis sur le site de dart où on voit une transformation selon le nouveau modèle comparé à l'ancien, et c'est formulé de manière plus performante.

[LSMetag]

Enfin une version comparable à du natif !
Je vais de ce pas m'y mettre !

[Uther]

Justement non, on voit bien que le dart compilé en javascript a des performances inférieures au Dart classique, qui est lui même inférieur à du C/C++