Compilateur GCC vs CLANG

[everest31]

Bonjour a tous et encore une fois bonne année

Voila je viens poser ma question ici pour avoir des retours d'expérience avec le compilateur CLANG pour vos projets C/C++ ?

En regardant un peu sur le net, on voit que le débat fait rage entre pro gcc et pro clang outre le problème que pose les dernieres versions de gcc avec sa licence GPLv3.

Pour ma part je me concentre plus sur le code produit par les deux compilateurs à niveau d'optimisation et option de compilation equivalente.

Le binaire produit par Clang est-il vraiment plus propre et plus rapide ou non ?

A mon niveau j'ai fait quelques tests et la seule chose qui m'est apparut c'est un gain de poids des binaires.
Je suis parti d'un noyau standard Freebsd 9.1 d'un poids de 129,4Mo.
J'ai recompiler avec GCC et une optimisation au niveau architecture plus quelques trucs résultat 128.5Mo
La même chose avec Clang, 126,3Mo.

On gagne globalement un peu plus de 2Mo sur l'ensemble d'un noyau soit dans les 2%

par contre au niveau perf du code je sais pas trop comment tester s'il y a vraiment une meilleure opti des binaires.

Merci d'avance de vos retours

[Le Farfadet Spatial]

Salut à tous !

Le message date un peu, mais je réponds tout de même.

Envoyé par everest31

par contre au niveau perf du code je sais pas trop comment tester s'il y a vraiment une meilleure opti des binaires.

Comment faire ? Hé bien, il s’agit d’une analyse comparative, soit en anglais « benchmarking ». Il existe des outils pour cela, par exemple la suite Phoronix (qui a l’avantage d’être libre).

Justement, en parlant de Phoronix, le site a publié une comparaison entre GCC et CLang en mai 2012. En termes de performances, il en ressort un léger avantage pour GCC, mais pas réellement significatif. En termes de taille des exécutables, tes tests donne un léger avantage, mais pas réellement significatif, à CLang.

Ce qu’il faut en conclure, à mon sens, c’est que GCC et CLang sont des solutions comparables. Il y a deux compilateurs libres de très grande qualité l’un comme l’autre. De plus, la compétition informelle dans laquelle ils se trouvent fait que l’un et l’autre s’améliore. Tout cela au bénéfice des utilisateurs.

Du coup, impossible de dire qui est le meilleur, ça vaut le coup de tester les deux. Dans un projet concret, hé bien, le choix de l’un plutôt que l’autre est probablement surtout une question d’habitude.

À bientôt.

Le Farfadet Spatial

[acx01b]

Bonjour,

Je ne sais pas si ça compte, mais j'ai la nette impression que le code source de gcc (pas le code produit quand on compile nos sources) est vraiment "crade", et je ne vois pas trop comment des nouveaux développeurs peuvent s'intégrer au projet gcc et le faire évoluer. Pour moi c'est très simple : gcc risque de mourir progressivement.

A l'inverse, j'ai l'impression que toutes les parties de CLang qui ont été réécrites sont beaucoup plus propres, modulaires : au moins on comprend ce qu'une fonction, un module, un fichier de CLang prend en entrée, et produit en sortie après quel traitement.

Ce n'est pas du tout, mais vraiment pas du tout, le cas pour GCC. Selon moi dans GCC il y a un gros problème : on ne voit pas ce que les fonctions/fichiers/modules prennent en entrée et produisent en sortie.
Sans parler des fichiers sources utilisés par plusieurs modules (gcc, cc1, collect2..) : on ne sait pas vraiment quel bout de fichier est utilisé par quel module.
Et enfin, les différents étapes de la compilation sont très mal séparées dans GCC. Voici ce que j'ai compris :

En gros :
- Gcc parse le code C
- en même temps il parse les directives préprocesseurs (les structures qui gèrent le préprocesseur sont les mêmes que celles qui gèrent les token, et elles ne sont pas commentées)
- en parsant le code préprocessé, on produit un arbre d'instruction : un tree donc la structure est très obscure et très mal commentée/expliquée. En fait il y a des tentatives d'explication de la structure 'tree' sur le site 'gcc internals', mais honnêtement c'est mal fait, il manque notamment le code exemple pour imprimer le 'tree' d'une manière lisible, et pour faire le lien avec tous les fichiers dump que l'on peut faire avec gcc. Sans parler du fait qu'il est difficile de garder une trace du code source dans les 'node' du 'tree' produit, alors que pour comprendre il serait agréable de lier l'arbre syntaxique avec l'arbre d'instruction, même si pour optimiser la mémoire il ne faut bien évidemment pas le faire dans la version release.
- juste quand on a fini de parser une fonction, il y a un appel de fonction qui n'est même pas commenté qui compile directement le 'tree' produit (qui le transforme en assembleur).

Comprendre tout ça , ça m'a pris des dizaines d'heures. Pourquoi ce n'est pas expliqué tout simplement dans la doc de GCC ? GCC ne veut pas de nouveaux développeurs ?

Un projet Open-source a de l'avenir seulement si son code source est compréhensible. Sinon, il n'est pas vraiment ce qu'on peut appeler "open-source".


Enfn, je me dis que Google a fait du super boulot avec V8 son moteur/compilateur/interpréteur Javascript (utilisé dans chrome/chromium). Vous ne pensez pas que gcc et CLang risquent d'être très vite dépassés par le compilateur que Google aurait tout intérêt à sortir ?

[Le Farfadet Spatial]

Salut à tous !

Envoyé par acx01b

Pour moi c'est très simple : gcc risque de mourir progressivement.

Depuis des années, on déclare régulièrement que Linux va mourir progressivement du fait de *BSD, puis que *BSD va mourir progressivement du fait de Linux – alors que nous savons tous que c’est HURD qui va les enterrer…

Bref, je me méfie des oracles. Cela dit, tout projet informatique est voué à l’obsolescence, ce qui compte c’est de pouvoir réutiliser ce qu’il a apporté.

Enfn, je me dis que Google a fait du super boulot avec V8 son moteur/compilateur/interpréteur Javascript (utilisé dans chrome/chromium). Vous ne pensez pas que gcc et CLang risquent d'être très vite dépassés par le compilateur que Google aurait tout intérêt à sortir ?

L’intérêt de Google est fortement dépendant de sa stratégie commercial, donc de leur point de vu, je ne sais pas s’ils ont intérêt à le « sortir » – d’autant que je ne suis pas certain de ce que tu veux dire par là, dans la mesure où je peux donner plusieurs sens au terme « sortir » dans ce contexte. En tout cas, V8 est sous licence de type BSD.

Oui, V8 a de grande qualité en tant que moteur Javascript. Est-ce qu’un moteur Javascript peut fournir une bonne infrastructure pour réaliser un système de compilation générique, je ne le sais pas, d’autant que je n’ai jamais regardé le code interne de V8. Cela dit, j’ai des doutes à ce sujet.

Cela dit, oui, GCC est un projet désormais lourd et dans lequel il est difficile d’entrer. Il faut revenir à ce qu’il était au départ : lorsque Richard STALLMAN lance le projet en 1986, il n’est pour lui question que de réaliser un compilateur C. Désormais, il s’agit d’une collection de compilateurs supportant de très nombreux langages, architectures et systèmes. À l’inverse, Clang a commencé en 2007, supporte moins de langages et surtout moins de systèmes et a été bâti sur un projet qui, pour sa part, ne se veut qu’une infrastructure de compilateurs, à savoir LLVM.

Donc, au fil du temps, GCC a grossi et entrer dans son code source est devenu de plus en plus difficile. Au contraire, Clang est un projet jeune et dynamique. C’est un inconvénient pour GCC. On verra ce qu’il en sera de Clang dans vingt ans.

Cela dit, si on se pose la question de savoir vers quel projet se tourner pour contribuer, il y a deux façons de répondre. Soit on a un besoin pragmatique, par exemple on fait partie d’une entreprise qui a un besoin concret, et alors le projet vers lequel se tourner est sans doute celui qui est le plus utilisé dans le contexte souhaité. Soit on veut découvrir comment fonctionne un projet de compilateur, auquel cas Clang est certainement plus indiqué.

À bientôt.

Le Farfadet Spatial

[alexrtz]

Envoyé par acx01b

Je ne sais pas si ça compte, mais j'ai la nette impression que le code source de gcc (pas le code produit quand on compile nos sources) est vraiment "crade", et je ne vois pas trop comment des nouveaux développeurs peuvent s'intégrer au projet gcc et le faire évoluer. Pour moi c'est très simple : gcc risque de mourir progressivement.

Article de Phoronix sur le sujet, avec quelques liens sympas.