Quelques expériences de Dart avec LLVM donnent des résultats prometteurs
Quelques expériences de Dart avec LLVM donnent des résultats prometteurs
qui pourraient être améliorés avec des optimisations du ramasse-miettes ajouté
Dart est l’un des nombreux langages de programmation développés par Google. Il avait pour objectif premier de remplacer JavaScript dans les navigateurs (certaines versions préliminaires de Chrome avaient une machine virtuelle Dart), puis ses objectifs ont évolué pour être plus consensuels : un remplaçant potentiel de Java, mais avec toujours en tête l’idée de générer du code JavaScript très efficace. Le langage a donc un système de type dynamique et optionnel (les types des variables ne sont connus qu’à l’exécution), mais en limitant ses capacités dynamiques à la portion congrue (pas de fonction eval, pas d’ajout de propriétés à un objet après sa création).
Des ingénieurs de Google ont tenté une expérience : remplacer la machine virtuelle derrière l’implémentation standard de Dart par LLVM et une compilation avant l’exécution, voir si cela permettrait d’améliorer la performance à l’exécution, notamment — LLVM est l’infrastructure de compilation derrière Clang, notamment. La tâche n’est pas aisée a priori : la machine virtuelle de Dart effectue déjà un gros travail de compilation du code à la volée avec des optimisations. LLVM n’est pas non plus prévu pour des langages avec ramasse-miettes, qui perturbent ses routines d’optimisation du code.
De manière générale, une idée reçue est que l’implémentation d’un langage a droit à soit un ramasse-miette précis et efficace, soit un haut niveau d’optimisation du code. En effet, le ramasse-miette parcourt régulièrement les pointeurs sur de la mémoire allouée pour vérifier qu’elle est toujours utile ; après une passe d’optimisation, le code a tellement changé d’apparence qu’il est impossible de s’y retrouver. Une technique pour contourner le problème est de stocker les pointeurs dans une zone particulière, mais cela met en échec bon nombre d’optimisations possibles du code.
Il y a peu, LLVM a intégré une nouvelle fonctionnalité expérimentale, les points d’état, qui sert justement à laisser le compilateur effectuer ses optimisations sans perturber le fonctionnement d’un ramasse-miettes. Le principe est de marquer explicitement les modifications du code au ramasse-miettes, de telle sorte que, en cas de déplacement d’un objet en mémoire, tous les pointeurs concernés peuvent être mis à jour (plus d’informations dans la documentation de LLVM).
L’expérience s’est basée sur le code de Dartino, qui utilisait déjà LLVM pour optimiser du code Dart. Cependant, Dartino n’utilisait pas de ramasse-miettes, cette implémentation se limitait à lamentablement planter en cas de manque de mémoire. L’opération principale a été d’ajouter un ramasse-miettes à l’exécution et de le faire travailler de pair avec les optimisations. (Voir les détails d’implémentation.) Les résultats sont prometteurs : la performance est similaire à Flutter, qui a le même objectif (compiler du code Dart), tout en utilisant une infrastructure plus générique. Très peu de travail spécifique à Dart a été requis côté LLVM — certaines modifications pourraient augmenter la performance drastiquement, cependant. Des améliorations du ramasse-miettes pourraient aussi améliorer fortement la situation, les algorithmes actuellement utilisés pour cette expérience n’étant pas au même niveau que Flutter.
Globalement, l’objectif de cette « petite » expérience est atteint : oui, il est possible de mélanger LLVM, des optimisations très pointues du code, avec un ramasse-miettes, avec une performance tout à fait respectable.
Source : Dart-on-LLVM.
ERP x RSE mobile first: architecture modulaire, CMS: Dart TS ou JS? Ou NativeScript?
Salut!
S'il te plait toi qui utilise Dart et Angular, peux tu me conseiller?
J'essaie de faire un outil de gestion pour familles, et réseau social interne et intra familles: regarde www.tribeez.com , modulaire, avec à terme un appstore de module ou apps ou plugin pour qu'une famille taille sur mesure ton portail (à la ExOplatform par exemple, ou Odoo (ERP), etc.). Sans oublier le réseau social.
Nous avons commencé en React sur Firebase. Mais l'équipe de dev va grandir (de 1 il y a 3 mois nous serons 4 la semaine prochaine puis etc.) et pas que des top gun. Et des partenaires extérieurs sont intéressés pour d'autres usages, nous cherchons une architecture façon CMS et ses plugins ou chacun puisse ensuite personnaliser son portail à l'usage de ses clients: colocataires, famille, groupe d'amis, entreprises, etc.
React me semble très riche dynamique et à la pointe, mais manque de cadre pour que tous respectent un urbanisme facilement. Angular (4 maintenant), complet et cadré, semble être une solution. En JS, TS ou Dart? Avec toujours Firebase et consorts derrière ou avec quel autre solution?
Nous visons "mobile first", et bien sûr un seul codebase pour toutes les plateformes iOS Android et Web responsive sinon ça va devenir ingérable... (là, j'ai pas encore bien compris ce que NativeScript offre alors qu'il y a déjà JS TS et Dart dans Angular... et Dart pour Fuschia arrive... pffff...)
Et productivité maximale car ça avance vraiment pas...
Enorme merci pour tes conseils!
