Tests intéressants. Pour ma part, le problème qui me saute aux yeux est tout de même de tout baser sur un unique compilateur. Je pense à cette liste, sûrement non exhaustive, d'inconvénients:
- Tu as testé sur quelques exemples, mais comme tu le dis, à ce que je comprends, llvm est expérimental. Peut-être que sur des bouts de code utilisant des fonctionnalités de langage très particulières, llvm peut montrer des limites? Cela n'est qu'une hypothèse basé sur le fait que llvm est apparemment expérimental (cf tes dires) et que les dévs eux-même semblent surtout destiner ce compilo/VM à des chercheurs (cf. section "LLVM Audience" de la page "Features" du site, où la plupart des lignes désignent chercheurs ou développeurs, hormis la dernière pour un certain type d'utilisateurs finaux).
- Et si le développement de LLVM s'arrête? Ton idée est entièrement dépendante de ce produit. Tout autre gestionnaire de paquet marche avec n'importe quel compilateur.
- Apparemment LLVM ne supporte vraiment que C et C++ pour l'instant (et qques autres en développement). C'est beaucoup étant donné que ce sont les langages les plus utilisés, historiquement. Mais on sait que de nos jours, il y a foultitude plus de langages et que ces autres langages sont de plus en plus utilisés, étant donné qu'on considère de plus en plus le gain de temps apporté par les langages de haut niveau.
Une "solution" serait que les programmes utilisant un langage non supportés seraient en binaire dans tes repositories, et ceux en C/C++ en bytecode. Néanmoins je ne connais pas les statistiques sur le pourcentage de programme non C/C++, mais cela ne m'étonnerait pas que ce soit plus de la moitié des programmes existants. Et dans ce cas, on réduit énormément les intérêts principaux de ton gestionnaire de paquet et de ses dépôts de programme très petits.
Évidemment si à l'avenir, LLVM se met à supporter tous les langages (boulot titanesque), cela n'est plus un problème.
Sinon une petite question: puisque LLVM est avant tout une VM, peut-être n'y aurait-il même pas besoin de compiler en langage machine les programmes chargés, non? Si on considère que qqun utilisant ton gestionnaire de fichier a de toutes façons LLVM d'installé, il peut directement exécuter les fichiers en bytecode, d'où gain de place, de temps, etc. Ensuite je ne sais pas, peut-être que les programmes interprétés ne sont pas suffisamment performants, mais j'ai l'impression de comprendre tout de même que LLVM (qui se définit comme Low Level Virtual Machine) prétend avoir des binaires interprétés plutôt performants. Donc peut-être est-il intéressant de s'arrêter à ce niveau (bytecode) de compilation?
Quoiqu'il en soit, tiens nous au courant des avancées de l'idée...
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Intéressant
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 2.
- Tu as testé sur quelques exemples, mais comme tu le dis, à ce que je comprends, llvm est expérimental. Peut-être que sur des bouts de code utilisant des fonctionnalités de langage très particulières, llvm peut montrer des limites? Cela n'est qu'une hypothèse basé sur le fait que llvm est apparemment expérimental (cf tes dires) et que les dévs eux-même semblent surtout destiner ce compilo/VM à des chercheurs (cf. section "LLVM Audience" de la page "Features" du site, où la plupart des lignes désignent chercheurs ou développeurs, hormis la dernière pour un certain type d'utilisateurs finaux).
- Et si le développement de LLVM s'arrête? Ton idée est entièrement dépendante de ce produit. Tout autre gestionnaire de paquet marche avec n'importe quel compilateur.
- Apparemment LLVM ne supporte vraiment que C et C++ pour l'instant (et qques autres en développement). C'est beaucoup étant donné que ce sont les langages les plus utilisés, historiquement. Mais on sait que de nos jours, il y a foultitude plus de langages et que ces autres langages sont de plus en plus utilisés, étant donné qu'on considère de plus en plus le gain de temps apporté par les langages de haut niveau.
Une "solution" serait que les programmes utilisant un langage non supportés seraient en binaire dans tes repositories, et ceux en C/C++ en bytecode. Néanmoins je ne connais pas les statistiques sur le pourcentage de programme non C/C++, mais cela ne m'étonnerait pas que ce soit plus de la moitié des programmes existants. Et dans ce cas, on réduit énormément les intérêts principaux de ton gestionnaire de paquet et de ses dépôts de programme très petits.
Évidemment si à l'avenir, LLVM se met à supporter tous les langages (boulot titanesque), cela n'est plus un problème.
Sinon une petite question: puisque LLVM est avant tout une VM, peut-être n'y aurait-il même pas besoin de compiler en langage machine les programmes chargés, non? Si on considère que qqun utilisant ton gestionnaire de fichier a de toutes façons LLVM d'installé, il peut directement exécuter les fichiers en bytecode, d'où gain de place, de temps, etc. Ensuite je ne sais pas, peut-être que les programmes interprétés ne sont pas suffisamment performants, mais j'ai l'impression de comprendre tout de même que LLVM (qui se définit comme Low Level Virtual Machine) prétend avoir des binaires interprétés plutôt performants. Donc peut-être est-il intéressant de s'arrêter à ce niveau (bytecode) de compilation?
Quoiqu'il en soit, tiens nous au courant des avancées de l'idée...
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]