Discussion :

[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.

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 !

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]

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.