IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

GCC réimplémenté en C++
Les développeurs du compilateur abandonnent le C pour garder son code facilement maintenable et compréhensible

Le , par Hinault Romaric
29 commentaires

22PARTAGES

8  0 
Le développement du compilateur GCC (GNU Compiler Collection) passe du langage C au C++.

La communauté en charge du développement de la suite de compilateurs libre GCC vient d’annoncer que son code a été réimplémenté avec le langage orienté objet C++.

Avant cette adoption définitive du C++, le code utilisé dans l’étape un du processus de construction de GCC a été mis en œuvre avec le langage C. Le code des étapes deux et trois de ce processus a été développé pendant un certain temps en C++ avant d’être abandonné.

L’idée d’utiliser le C++ en lieu et place du C avait germé dans la tête des développeurs de GCC en mai 2010, qui estimaient que le C++ était acceptable pour développer le compilateur.

Selon les explications sur le Wiki du projet, le passage du C au C++ a pour objectif de maintenir le code du GCC compréhensible et facilement maintenable. Les développeurs du projet notent néanmoins que l’utilisation imprudente de C++ peut être lourde de conséquences. Un point qui cependant n’est pas qualitativement différent des problèmes rencontrés actuellement.

Les modifications du code de GCC ont été planifiées et mises en œuvre dans le cadre du projet « GCC in Cxx ». Certaines structures de données ont déjà été réimplémentées en C++ et, actuellement, les développeurs sont en train de travailler sur les changements qui ont été intégrés à la branche 4.7.

GCC est à sa version 4.7.1 depuis juin 2012. La suite de compilateurs permet de transformer le code source en langage machine pour plusieurs langages de programmation dont C, C++, Java, Objective-C, Ada et même Fortran 95.

Source : Wiki conversion GCC vers C++

Et vous ?

Bonne ou mauvaise idée ? Pourquoi ?

Une erreur dans cette actualité ? Signalez-nous-la !

29 commentaires
Commenter Signaler un problème
Freem
Avatar de Freem
Membre émérite https://www.developpez.com
Le 17/08/2012 à 16:36
Citation Envoyé par jmnicolas Voir le message
GCC réimplémenté en C++ ?

Les signes avant-coureurs sont bien là, les Mayas avaient raison : 2012 c'est la fin du monde
Post très argumenté s'il en est.

J'ai lu un peu plus en détail le contenu de cette source et des documents qui y sont cités...

D'ailleurs, j'ai l'impression que le titre de cet article fait dans la sensation.

Le C n'est pas abandonné, pas totalement du moins, puisque "GCC generates temporary garbage which is only freed by ggc collect", GCC étant écrit en C. D'un autre côté "C++ permits reference counting smart pointers." et donc "We may want to use a mixture of reference counting and garbage collection."

En gros, le C++ va être utilisé, oui, mais uniquement quand il présente un avantage par rapport au C.
Basiquement, je suppose qu'ils ne vont pas utiliser les stream (et je ne pourrait leur en vouloir, personnellement je ne les apprécie pas du tout)

Pendant que j'y suis, j'ai juste adoré le PDF que j'ai cité, notamment un passage:
The FSF doesn’t like it!
◮ The FSF is not writing the code.
Je salue la justesse du raisonnement de l'auteur

Ce PDF attaque aussi d'autres idées reçues, telles que:
_ C++ trop lent
_ C++ trop compliqué
_ C++ pas portable
Et surtout, les exemples de code sont très instructifs.

Bon... n'empêche, il précise aussi que ce n'est pas la panacée, juste une amélioration.
Pour le coup, je me demande ce qu'en pense ce cher Linus.

Au sujet de la source elle-même, il semble qu'ils attendent un véritable gain en mémoire, et donc en durée de compilation.
Gain dû au fait que le C++ aie des destructeurs, et que donc, dès que l'on sors d'une portée, on libère de la mémoire. La ou l'implémentation C utilisais un gargage collector, une implémentation C++ économise la mémoire grâce à la RAII.
Quand je vois qu'en 2-3 threads je monte vite à 1Gio, qui est la limite de mon netbook, c'est plutôt une bonne nouvelle qu'ils espèrent ce type d'amélioration.
Divers autres passages parlent aussi de diminution du nombre de cast dynamiques, et donc d'optimisation de la vitesse également.

En tout cas, je pense que ce projet permettra de montrer clairement si oui ou non, C++ est une amélioration par rapport au C, et dans quelle mesure l'efficacité est améliorée.
A noter tout de même, qu'ils ne semblent pas vouloir tout convertir, mais juste quelques modules.

En tout cas, ils n'y parlent pas d'implémenter les fonctionnalités restantes des standards.
Ce qui paraît logique: je pense qu'ils vont commencer par migrer les parties stables, pour faciliter le travail.
Migrer une partie stable, ça veut dire qu'il est possible qu'il existe des tests unitaires pour cette partie, donc que le code migré sera bien testé, plutôt que de devoir à la fois lutter contre les bugs de migration et ceux d'implémentation.
Donc, pour moi, a court et moyen terme, on ne peux s'attendre qu'a une amélioration en terme de mémoire et de vitesse à la compilation (pour les raisons déjà évoquées)
7  1 
gbdivers
Avatar de gbdivers
Inactif https://www.developpez.com
Le 20/08/2012 à 16:02
C'est quoi cette argumentation ??? Surtout la dernière phrase

Si tes variables f ou b ont besoin d'être initialisé, que ce soit dans le constructeur des classes (C++) ou dans une fonction d'initialisation (C), ça sera pareil en terme de temps d’exécution. Si tu n'as pas besoin de les initialiser, ça te coûtera pas plus en C++ qu'en C.
De plus, en C++ comme en C, les variables seront sur la pile, il n'y aura pas de différence sur le code généré et les performances

Il faudrait comprendre un jour que le C++ et le C ont les mêmes performances pour les mêmes fonctionnalités (et les fonctionnalités du C++ qui n'existent pas en C, comme par exemple les fonctions virtuelles, nécessiteront du code supplémentaire en C, ce qui donnera les mêmes performances au final)
4  0 
Freem
Avatar de Freem
Membre émérite https://www.developpez.com
Le 17/08/2012 à 15:49
Citation Envoyé par Hinault Romaric Voir le message

Bonne ou mauvaise idée ? Pourquoi ?
Bonne... question.

D'un côté, C++ permet d'utiliser plus de paradigmes de développement, mais cet ajout implique pour moi une certaine nécessité de re-réfléchir à la conception.
Je ne suis pas du tout persuadé que la migration d'un langage à un autre soit une bonne idée.

D'un autre côté, C++ permet de compiler du C. Le fait qu'il soit multi-paradigme permet tout simplement une refonte en douceur, très progressive, via divers refactoring très légers.
Donc la stabilité ne devrait pas trop en souffrir.

Après... Quels sont les avantages de C++ contre C?
_ la possibilité d'utiliser des outils pour générer des diagrammes de classes UML afin de comprendre nettement plus rapidement la structure de code. Diagrammes UML qui sont quand même de plus en plus connus par les développeurs, je pense. L'intérêt de ce point, c'est de pouvoir amener facilement de nouveaux contributeurs: plus un projet est simple a appréhender, moins ça coûte cher en formation et motivation, plus rapidement les nouveaux contributeurs peuvent contribuer. Donc, plus vite le projet peut lui-même évoluer.
Bien sûr, ce n'est pas parce qu'un projet est écrit en C qu'il est mal documenté, mais je n'ai jamais entendu parler d'outils qui extraient la structure d'un projet écrit en langage non objet.

_ utilisation des templates. Ca allonge la durée de compilation, mais ça permet de réduire la base de code de façon parfois drastique. Je doute fortement que ça aie un impact en terme de performances, en revanche, niveau maintenance, c'est une évidence. Bon... tant qu'il n'y a pas besoin d'aller lire le code source des templates fournis par G++, parce que bon, ces bouts de code n'ont pas grand chose de simple à lire... Voire de lisible...

Donc, pour moi, le seul gain potentiel sera un gain en terme de maintenance, une certaine partie du code sera fusionnée via les templates, une autre sera plus lisible grâce aux fonctions inline, et une doc pourra être générée à partir du source via les diagrammes de classe.

Peut-être même de légères pertes de performances dans l'absolu, parce que migrer du langage C au langage C++ est truffé de subtilités, mais s'ils gèrent bien (ce qui est probable, on parle de gens qui écrivent des compilateurs, dont un compilateur C++ hein), la différence ne sera pas perceptible (voire inexistante?):
Utiliser les méthodes et fonctions inline à bon escient et ne pas abuser du code virtuel (héritages et méthodes) permet de n'avoir que peu voire pas du tout d'impact.
Vu que la base de code est en C, je doute qu'il y ait de l'héritage de structures autre que "manuel" et du coup, il ne devrait pas y avoir trop de virtuel. De ce côté, il est même possible qu'il y ait un gain de performances occupation mémoire et/où utilisation CPU).
Pour l'inlining, le compilateur fait bien le boulot lui-même, je pense.

D'ailleurs, cette nouvelle amène une question:
C++, oui, mais C++11?
Parce que si ce n'est pas le cas, ils vont se priver de certains mécanismes qui peuvent considérablement simplifier leur vie: move semantic, intégration des instructions multi-thread, et ce genre de choses. Choses qui pour certaines sont fournies avec le C11, mais ça n'aurait été "qu'une simple mise à jour" du code, avec de probables oublis réguliers (je n'ose imaginer la taille en LOC du projet!). Ici, le changement de langage va probablement impliquer un travail avec plus d'attention, qui pourrait permettre d'intégrer les avancées de C11 et C++11, et la, je suis certain qu'on aura des améliorations de performances.

Quant à la question du fait que ça empêcherait que ça fonctionne sur certaines architecture d'utiliser du code trop récent: je suis sûr à 95% qu'ils utilisent GCC pour compiler, du coup, ça implique qu'au moins un compilateur pourra compiler leur compilateur: le leur. Et donc, il pourra le faire sur toutes les plate-formes déjà supportées, non?

[edit]
J'ai vu juste, le gain qu'ils semblent attendre est effectivement axé sur la maintenance:

Background

What matters for GCC going forward is that it continue to be comprehensible and maintainable. That is a struggle that GCC has faced for its entire existence as a free software project. It is certainly true that using C++ unwisely can make that struggle more difficult. But this issue is not qualitatively different from the issues we face today.

Whether we use C or C++, we need to try to ensure that interfaces are easy to understand, that the code is reasonably modular, that the internal documentation corresponds to the code, that it is possible for new developers to write new passes and to fix bugs. Those are the important issues for us to consider. The C++ features which are not present in C -- features which are well documented in many books and many web sites -- are not an important issue.

For additional background information on this effort and its scope, please check out http://airs.com/ian/cxx-slides.pdf .
==>
Ce qui importe est que GCC reste compréhensible et maintenable[...]que nous utilisions C ou C++ nous devons nous assurer que les interfaces soient simples à comprendre, que le code soit raisonnablement modulaire, que la documentation interne corresponde au code, qu'il soit possible pour de nouveaux développeurs d'écrire de nouvelles passes et de corriger les bugs.

==>
Les fonctionnalités de C++ qui ne sont pas présentes en C -- fonctionnalités qui sont très bien documentées [...] -- ne sont pas importantes.

Du coup, j'en déduis qu'ils ne vont pas utiliser les fonctionnalités des nouveaux standards, ce qui répond(?) à ma question précédente.
4  1 
Avatar de
https://www.developpez.com
Le 21/08/2012 à 12:03
Citation Envoyé par rt15 Voir le message
...
c'est gentil d'avoir retirer l'allocation dynamique du tableau pour favoriser le C.
en faisant l'allocation dynamique j'obtiens des resultats un peu plus proches deja.....

c'est deja pas facile de comparer du C et du C++, mais prendre une loupe pour regarder un element sans considerer un programme entier c'est tres contre-productif.

De mon experience, les deux ont la meme vitesse; le C++ perd par moment mais gagne par d'autres, et regarder individuellement c'est contre productif.

C'est comme mettre un exemple de 4 lignes en java qui va plus vite qu'en C++ sans regarder que eclipse qui est une vrai appli java cette fois, rame comme pas permis.

En plus, si on cherche bien, on trouve toujours des trucs mieux ou moins bien (plus ou moins rapide), ca n'a vraiment aucun interet...
3  0 
Tryph
Avatar de Tryph
Membre émérite https://www.developpez.com
Le 20/08/2012 à 14:16
Citation Envoyé par Freem Voir le message

[...]je n'ai jamais entendu parler d'outils qui extraient la structure d'un projet écrit en langage non objet.
Doxygen est capable d'analyser du code C, de décrire les structures, de les lier entre elles et même de faire des diagrammes pour synthétiser tout ça.

bon c'est pas de l'UML, mais c'est déjà bien pratique.
2  0 
gbdivers
Avatar de gbdivers
Inactif https://www.developpez.com
Le 20/08/2012 à 18:47
Ok donc ça confirme ce que je dis

Citation Envoyé par gbdivers Voir le message
Il faudrait comprendre un jour que le C++ et le C ont les mêmes performances pour les mêmes fonctionnalités (et les fonctionnalités du C++ qui n'existent pas en C, comme par exemple les fonctions virtuelles, nécessiteront du code supplémentaire en C, ce qui donnera les mêmes performances au final)
Là tu compares avec une classe qui encapsule un tableau avec RAII en C++ et un tableau sans initialisation en C. Deux fonctionnalités différentes, deux résultats différents.
En C++, tu n'as pas en effet de séparation allocation et initialisation pour un vector, donc on pourrait oublier (ou ne pas savoir) que l'on parcours deux fois le tableau dans ton code. Mais :
- on trouve plus souvent l'erreur d'utilisation d'un tableau C non initialisé qu'un problème de performance d'un tableau C++
- on trouve plus souvent des problèmes d'algorithme sur la gestion des ressources que des problèmes de performance d'un tableau C++ (typiquement des tableaux qui sont alloué et libéré plusieurs fois dans un algo)
- la différence de temps d'allocation d'un tableau C ou C++ est en général ridicule sur la durée total d'un programme (si on s'amuse pas à allouer et libérer les tableaux tout le temps)
- le C++ autorise d'autres types de tableaux qui ne présente pas la sécurité du RAII (new[], malloc) ou de fournir d'autres allocateurs

Bien sûr, un vector n'est pas très adapté, mais c'est pour l'exemple.
C'est claire qu'en prenant des outils non adaptés, on arrive aux conclusions que l'on veut

de voire une complexité en n, pas en 2n
Jusqu'au dernière nouvelle, O(n) = O(2n)

C'est donc quand même très vite fait d'écrire un code deux fois plus lent qu'il ne devrait, sans que ça saute aux yeux.
Tu l'as testé ton code pour dire qu'il est deux fois plus lent ?

Bref, ton argument est basé sur une méconnaissance du C++

HS :
Effectivement, le message est assez fin, et est presque plus philosophique que technique.
Merci de ne pas prendre les gens de haut
3  1 
Hibernatus34
Avatar de Hibernatus34
Membre expérimenté https://www.developpez.com
Le 21/08/2012 à 10:51
Citation Envoyé par Freem Voir le message

Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
int main()
{
  //code divers
  {
     Foo f;
     //code exploitant f
  }
  // encore un peu de code
  {
     Bar b;
     // code exploitant b
  }
  //autre code divers
}
Alors qu'en C il eut fallut écrire:
Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
int main()
{
  Foo f;
  Bar b;
  //code divers
  //code exploitant f
  //code exploitant b
  //autre code divers
}
La différence provenant du fait que dans le code C++ la mémoire utilisée par f n'est pas allouée avant que f ne serve, et est vidée quand il ne sert plus à rien. Idem pour b. Selon le programme, ces trucs peuvent prendre plus ou moins de mémoire, entres autres.
Pardon, mais c'est pas pertinent du tout à mes yeux, la seule différence entre ces 2 codes est la portée des variables, mais le code compilé sera probablement le même, puisque l'allocation de toutes les variables d'une fonction se fait par une seule soustraction. Une variable peut être déclarée dans un while, le compilo ne sera pas assez stupide pour empiler/dépiler à chaque itération. La seule différence viendrait de la présence de constructeurs/destructeurs (c'est d'ailleurs la raison pour laquelle C++ devait permettre ces déclarations n'importe où), mais évidemment le C n'en a pas, donc il n'est pas question de comparer ça. Ce que fait le constructeur en C++, une fonction C peut le faire... n'importe où également.

(notez que je préfère de très loin le C++ au C)

screetch : Le code n'est pas 100% équivalent à un array (était-ce le but ?), parce qu'on incrémente le membre size du vector à chaque itération, ce qu'on ne ferait pas pour un array Perso je m'en fous
2  0 
Avatar de
https://www.developpez.com
Le 21/08/2012 à 12:57
pourt les maths (et j'espere que ca clot le sujet car on comprend bien les intentions des uns et des autres)
la definition de O:
f est bornée, par le dessus, par g asymptotiquement
(à un facteur près)
la remarque importante, c'est "a un facteur pres". donc O(2n) = O(n) = O(5000n)
mais dans la plupart des cas si on a equivalence des O pour deux algorithmes (tous les deux en O(n) on cherchera a savoir par quel facteur.
2  0 
Avatar de
https://www.developpez.com
Le 20/08/2012 à 13:32
j'ai lu le PDF et a la page 3 il dit
Code : Sélectionner tout 
1
2
3
4
typedef std::vector<struct loop, gcallocator> loopvec;
loopvec *superloops;
superloops->reserve (depth);
superloops[depth];
un pointeur sur un vecteur... c'est peut etre pas si bien barré que ca
1  0 
gbdivers
Avatar de gbdivers
Inactif https://www.developpez.com
Le 20/08/2012 à 14:23
@screetch
Aie, en effet, si on ce genre de code, ça fait mal

Citation Envoyé par Freem
Et il semble que ces technologies aient un potentiel non négligeable d'optimisation de GCC, dont la réputation de lenteur et de lourdeur doit être connue de la plupart des gens ici. (je ne sais pas si elle est avérée, je ne me suis jamais amusé à faire de comparaison réelle, mais c'est à coup sûr un reproche que l'on voit souvent sur le web)
Je crois pas que l'optimisation de gcc (qui en a effectivement bien besoin) puisse venir de quelques fonctionnalités du langage C++
Le problème de gcc est plus profond, c'est un problème d'algorithmie (en particulier, on lui reproche de parser plusieurs fois les fichiers d'en-tête et de ne pas garder en mémoire ce qu'il a déjà analysé, d'où la perte de temps)
A voir si c'est toujours le cas. Mais si oui, on pourrait tout réécrire en assembleur (voir en langage machine ou en micro code processeur) que cela ne changerait rien

Très clairement pour moi, si ça avait été un débutant qui proposerait de recoder gcc en C++ pour diminuer les temps de compilation, je lui aurait répondu que c'est de la premature optimization, qu'il teste d'abord le temps passer dans les algos et dans les appels de fonctions et ne réécrire que s'il montre que c'est nécessaire.
Bon mais là, c'est les devs de gcc, je vais rien dire...

Pour moi, le principal intérêt reste le gain en évolutivité, qui lui permettra d'implémenter plus facilement de nouvelles méthodes de compilation qui vont faire gagner du temps (et l'ajout des nouvelles fonctionnalités aux langages, ce qui est encore mieux)
1  0 
Commenter Signaler un problème