mardi 30 juin
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: LLVM 2.2 : Un concurrent pour GCC ?

Posté par patrick_g (page perso, ). Modéré le 18 février 2008.
0
Le compilateur LLVM (pour Low Level Virtual Machine) vient de sortir le 11 février dernier dans sa version 2.2 et s'affirme de plus en plus comme un concurrent possible pour le projet GNU GCC.

LLVM n'est pourtant pas tout à fait comparable au compilateur GCC. En effet GCC est un projet complet et monolithique car Richard Stallman a choisi explicitement de ne pas le rendre modulaire afin de ne pas permettre a des programmes propriétaires de s'interfacer avec lui.
LLVM au contraire est placé sous licence BSD et a choisi une conception très modulaire afin d'être réutilisé au maximum par tous. Il se limite à des fonctions d'optimisation et de génération de binaire ; il ne peut analyser lui-même le code source des programmes à compiler (c'est le projet Clang qui est prévu pour ça).

Il sera intéressant de voir ce qui va se passer sur le long terme dans l'écosystème du libre et si LLVM va être capable d'attirer des développeurs utilisant actuellement GCC.

> Lire la suite (173 commentaires, moyenne: 2,8).   [dépêche : 3673 caractères]

LLVM est une machine virtuelle de bas niveau écrite en C++ et qui utilise actuellement en frontal une version 4.0 de GCC. Cela signifie que GCC transforme le code source en une représentation intermédiaire qui est ensuite injectée dans LLVM afin de subir diverses analyses et optimisations. Il est prévu que cette dépendance envers GCC disparaisse le jour où le projet de frontal Clang sera considéré comme mature. Une comparaison entre Clang et GCC est disponible.
L'intérêt de cette séparation architecturale entre Clang et LLVM, outre son avantage en terme de simplicité, est que cela permet de "brancher" des modules d'analyse statique ou de refactoring du code. L'inclusion dans les environnement intégrés de développement (IDE) est également plus facile.

La version 2.2 de LLVM apporte plusieurs nouveautés :

Une présentation bien plus détaillée et technique de l'ensemble des nouveautés introduites par la version LLVM 2.2 est disponible sur le site du projet. En dépit de ces progrès le couple LLVM/Clang a encore énormément de chemin à faire avant de rattraper GCC.

La maturité et l'universalité (en terme de langages et d'architectures) de GCC en font un adversaire redoutable. On peut noter que le support C++ de Clang est très préliminaire et qu'il ne sera pas finalisé avant au moins deux ans. De plus la licence GPL de GCC garantit aux divers contributeurs que leur code ne pourra pas être "propriétarisé" par un concurrent. Cela explique que nombre de firmes (IBM, Red Hat ou Novell pour n'en citer que quelques unes) financent largement le développement de GCC. Néanmoins, on sent poindre chez plusieurs observateurs une inquiétude au sujet du conservatisme de GCC et la question de l'inclusion de greffons et de la modularisation de l'architecture ne tardera pas à réapparaître.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

llvm-gcc

Posté par loufoque () le 18/02/2008 à 19:07. (lien). Évalué à 2.

clang (nouveau frontend C/C++ pour LLVM) n'est pas utilisable, mais llvm-gcc (frontend C/C++ de GCC adapté à LLVM) l'est...

Les mauvaises décisions

Posté par √λιi () le 18/02/2008 à 19:27. (lien). Évalué à 9.

Richard Stallman a choisi explicitement de ne pas le rendre modulaire afin de ne pas permettre a des programmes propriétaires de s'interfacer avec lui.

Ou comment mélanger politique et technique se passe toujours très mal. Cette décision a eu pour implications : 1) rendre plus difficile l'ajout de nouveau languages, 2) motiver des gens pour faire une alternative a gcc.

Résultat, un compilateur sous BSD proprio compliant alors qu'on aurait pu avoir du gcc en GPL, certes soumis a quelques dérives et abus autour de la GPL, mais au moins sous la pierre angulaire de GNU : sa licence.

A chaque fois que quelqu'un fait des décisions de conception apportant des limitation techniques pour soit disant 'protéger' son application, ca se finit en drame. Je trouve ca bien triste de voir ca dans du libre.

Performances ?

Posté par el_mickey () le 18/02/2008 à 21:00. (lien). Évalué à 2.

Ca à l'air tout joli comme architecture.
Mais au niveau des performances ça donne quoi ? Parce que bon c'est quand même un des buts premiers des compilateurs et GCC n'est pas forcément non plus le plus rapide du monde. Si c'est pour avoir voir un compilateur mieux architecturé mais encore plus lent...

plusieurs projets...

Posté par Francois Revol (page perso, ) le 18/02/2008 à 22:33. (lien). Évalué à 4.

gcc n'est pas si monothique que ça... il a besoin de binutils pour générer des binaires.
Malheureusement il semble qu'ici aussi on ait droit à plusieurs projets séparés (pas au même endroit).

Je crains que celà n'implique les même problèmes qu'avec gcc+binutils dont il faut toujours chercher quelles versions fonctionnent ensemble, surtout si on doit utiliser une certaine version d'un des deux.

questions

Posté par Matthieu C () le 18/02/2008 à 22:35. (lien). Évalué à 6.

A la lecture de la news, j'ai quelques point que je ne comprend pas.

J'avais cru comprendre que LLVM transformait un code intermédiaire en assembleur.
Un frontend (gcc, clang) se chargeant de convertir le langage source utilisé dans ce langage intermédiaire.

Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?

On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.

On nous parle pas du tout de bibliothèque rattaché au langage.
Par exemple quelle libc llvm-gcc/clang supporte ?
Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?


PS :
Un inconvénient à LLVM est qu'il n'est pas bootstrapable facilement, c'est à dire qu'il aura toujours besoin que le système de destination ai déjà un compilo c++.


[1]
Le frontal utilisé passe de GCC 4.0 à GCC 4.2 afin d'améliorer les performances.

Re:

Posté par IsNotGood () le 19/02/2008 à 01:26. (lien). Évalué à 3.

> LLVM au contraire est placé sous licence BSD et a choisi une conception très modulaire afin d'être réutilisé au maximum par tous.

> De plus la licence GPL de GCC garantit aux divers contributeurs que leur code ne pourra pas être "propriétarisé" par un concurrent. Cela explique que nombre de firmes (IBM, Red Hat ou Novell pour n'en citer que quelques unes) financent largement le développement de GCC.

Tu ne crois pas que tu fais une contradiction ?

En passant, Linux est modulaire mais est très strict. La modularité de Linux en outrepassant la licence GPL est quasi uniquement pour les drivers. Il n'y a pas et n'aura pas de système de fichier proprio distribué avec Linux par exemple. Idem pour la VM, la pile tcp/ip, etc.
Donc gcc pourrait très bien être modulaire sans que son objectif de rester libre soit remis en cause. Il ne faut pas mélanger ces deux questions.


Globalement, ça commence à me chauffer les oreilles ces critiques ou remises en cause de gcc. Gcc est libre, s'il y a des problèmes techniques (et non politique, gcc doit rester libre et non être un truc proprio-friendly) il y aura un fork. Il y a déjà eu un fork de gcc ! C'était egcs (repris par quasiment toutes les distributions Linux).
S'il y a un vrai problème avec gcc, il y aura fork (comme c'est arrivé avec egcs). Pour l'instant il n'y a pas le début d'un ambrillon d'amorce de fork. Donc gcc n'est pas remise en cause. Qu'il y ait des concurrents à gcc, ne remet pas en cause gcc. Gnome a des concurrents (KDE, XFCE), ça ne remet pas en cause Gnome. Linux a des concurrents (*BSD, OpenSolaris), ça ne remet pas en cause Linux. Le libre n'interdit pas la diversité, fort heureusement. Le libre ce n'est pas dicter un produit pour tout le monde.
Enfin, c'est une petite erreur de mettre en concurrent "open source" et logicie libre. La GPL garantit que c'est et ça reste du logiciel libre. Une licence open source ne c'est pas le cas.

Enfin quel remise en cause ? Le but de gcc en prenant la licence GPL, n'est pas être le compilateur le plus populaire de la planète. Le but est d'être libre ET totalement libre (avoir un compilateur sans dépendre d'éléments proprio). Gcc est libre (comme depuis des années), donc gcc (sous GPL) a rempli cet object.
Que gcc soit aujourd'hui populaire est un "effet de bord".
Si gcc devient moins populaire par l'arrivée de solution plus proprio-friendly (open source mais pas free software), ça ne remet aucunement en cause gcc. Ce qui pourrait remettre en cause gcc, c'est l'arrivé d'un compilateur logiciel libre (sous GPL typiquement) et qui devient plus populaire que gcc (comme c'est arrivé avec egcs (que ça soit un fork de gcc ou non ne change rien).

Souvent les gens pensent que la BSD va amener des contributions des boites commerciales. Le choix de la BSD est souvent fait pour ça. Mais en moyenne ce n'est pas ce qu'on voit. On voyait ça il y a de nombreuses années, ce n'est plus le cas aujourd'hui.
Contrairement aux idées reçues (je ne dis pas ça pour patrick_g) la GPL est souvent appréciée par les boites commerciales. Elle est détestée par les boites qui veulent faire du proprio (MS déteste la GPL et aime la BSD). Une boite commerciale n'est pas toujours une boite qui veut faire du proprio. On peut se réjouir de constater que c'est de moins en moins le cas. On peut se réjouir de voir que logiciel libre n'est pas l'ennemi des boites commerciales.

Avec gcc (via la licence GPL) on a la garantit que gcc restera libre. Ce n'est pas le cas de llvm. Même si llvm devient meilleur que gcc, je resterai sous gcc.

Question bête...

Posté par Matthieu Lagouge (Jabber id, page perso, ) le 19/02/2008 à 02:57. (lien). Évalué à 3.

Bon, je ne comprends pas grand chose aux compilateurs, je sais juste que j'ai un code source au début et du binaire à la fin, les étapes intermédiaires, j'en ai qu'une très vague idée. (ceci est un avertissement).

Mais si GCC est si "tellement trop monolithique", et si Clang+LLVM, c'est ça la modularité et qu'on peut mettre plein de trucs comme on veut, comment donc font-ils pour utiliser un LLVM+GCC (ce dernier étant ultra monolithique et tout et tout, là il est bien utilisé en partie, non?)

Virtual Machine

Posté par Mildred (Jabber id, page perso, ) le 21/02/2008 à 11:50. (lien). Évalué à 3.

Je m'intéresse depuis un certain temps à LLVM notamment car il semble fournir une machine virtuelle. Mon but est de pouvoir avoir un environnement d'exécution restreint.

En gros, j'aimerais controller tous les appels a des bibliothèques extérieures ... Savez vous si (et comment) c'est possible ? J'ai longtemps cherché sur le site mais n'ai pas encore trouvé grand chose.

--
La Roue du Temps

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.5332s (dont 0.0442 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !