GCC r�impl�ment� en C++

Version imprimable

17/08/2012, 14h00
Hinault Romaric

GCC r�impl�ment� en C++

GCC r�impl�ment� en C++
les d�veloppeurs du compilateur andonnent le C pour garder son code facilement maintenable et compr�hensible

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 ?

:fleche: Bonne ou mauvaise id�e ? Pourquoi ?
17/08/2012, 15h49
Freem

Citation:

Envoy� par Hinault Romaric

:fleche: 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:

Citation:

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.
17/08/2012, 16h15
jmnicolas

GCC r�impl�ment� en C++ ?

Les signes avant-coureurs sont bien l�, les Mayas avaient raison : 2012 c'est la fin du monde :mrgreen:
17/08/2012, 16h27
gbdivers

Pourquoi pas ? Mais perso, je suis plus int�ress� par les nouvelles fonctionnalit�s qui seront impl�ment�es : support complet de la norme (il doit manquer des choses je crois), proposition de nouvelles fonctionnalit�s pour le prochaine TR ou C++1x (SG1 et SG5 en particulier), am�lioration des temps de compilation et des messages d'erreurs de template (clang en mieux). Si cette �volution permet de faciliter l'ajout de ces fonctionnalit�s, je prend
17/08/2012, 16h36
Freem

Citation:

Envoy� par jmnicolas

GCC r�impl�ment� en C++ ?

Les signes avant-coureurs sont bien l�, les Mayas avaient raison : 2012 c'est la fin du monde :mrgreen:

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:

Citation:

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)
17/08/2012, 17h04
gbdivers

Citation:

Pour le coup, je me demande ce qu'en pense ce cher Linus.

On connait d�j� sa position sur le C++ et ce n'est pas non plus lui qui �crit le code de gcc

Pour les id�es re�ues, le pdf date de 2008. Si les gens ont encore ce genre d'id�es 4 ans apr�s, faudrait peut �tre qu'ils se remettent en question

Dans http://gcc.gnu.org/gcc-4.8/changes.html :

Citation:

GCC now uses C++ as its implementation language. This means that to build GCC from sources, you will need a C++ compiler that understands C++ 2003.

Donc pas de C++11
17/08/2012, 17h19
Freem

Citation:

Envoy� par gbdivers

On connait d�j� sa position sur le C++ et ce n'est pas non plus lui qui �crit le code de gcc

Ce n'�tait pas une phrase s�rieuse en m�me temps ;)

Citation:

Envoy� par gbdivers

Pour les id�es re�ues, le pdf date de 2008. Si les gens ont encore ce genre d'id�es 4 ans apr�s, faudrait peut �tre qu'ils se remettent en question

En m�me temps, si j'avais confiance dans la capacit� des gens (y compris moi-m�me hein) � se remettre en question ou � changer d'id�es quand la raison l'impose, je pense que j'aurai pr�f�r� un m�tier avec plus de contact humain. Le fait que mon contact se limite � des rapports de bugs et des demandes de fonctionnalit�s me suffit amplement.

Citation:

Envoy� par gbdivers

Dans http://gcc.gnu.org/gcc-4.8/changes.html :

Donc pas de C++11

La source indique �galement que le compilateur version N doit pouvoir �tre compil�e par le compilateur version N-1, donc effectivement, C++11 ne sera pas utilis� de sit�t.
Je suppose qu'il faudrait d�j� qu'il soit compl�tement impl�ment� et surtout d�bogu� pour �a... Un compilateur qui utilise une techno qui n'est pas n�cessairement stable risquerait d'introduire pas mal de bugs dans les binaires par effet de cascade.
Je suis tout de m�me assez content de voir qu'ils n'y vont pas comme des brutes. En tout cas, je me demande combien de temps �a va mettre pour qu'ils sortent un truc en b�ta, et je me demande quel sera le r�sultat niveau am�liorations de perfs.

D'ailleurs, vu que mingw est bas� sur GCC, peut-�tre qu'on aura aussi des am�liorations de ce c�t�-ci? Histoire de pouvoir concurrencer un peu VS, ce serait pas mal.
18/08/2012, 23h05
PINGOUIN_GEANT

Citation:

Envoy� par gbdivers

Citation:

GCC now uses C++ as its implementation language. This means that to build GCC from sources, you will need a C++ compiler that understands C++ 2003.

Donc pas de C++11

Tu posais une question sur les nouvelles fonctionnalit�s support�es par gcc, mais il me semble que la version de langage pour d�velopper gcc est quelque chose diff�rent de l'actuel support d'un langage. J'ai peut-�tre rat� quelque chose.
Passer de C a C++, qu'est ce que cela veut dire sur l'optimisation des 2 versions de gcc pour compiler du C et du C++ ? Est-ce que la variante pour compiler du C++ est maintenant plus mature que la variante pour le C ? A-t-on des indices pour le savoir (aussi en comparaison des variantes pour Java, FORTRAN 95, etc.) ?
19/08/2012, 12h51
guillaume07

c'est pas trop t�t !!
19/08/2012, 15h23
gbdivers

Citation:

Envoy� par Freem

La source indique �galement que le compilateur version N doit pouvoir �tre compil�e par le compilateur version N-1, donc effectivement, C++11 ne sera pas utilis� de sit�t.

Je suppose que c'est le num�ro de version mineur de gcc, j'esp�re qu'ils compilent pas gcc avec la version 3 :aie:
Dans ce cas, la version N-1 (gcc 4.7) supporte d�j� une tr�s grande partie du C++11, donc ils pourraient l'utiliser sans probl�me pour gcc 4.8

Citation:

Envoy� par PINGOUIN_GEANT

Tu posais une question sur les nouvelles fonctionnalit�s support�es par gcc, mais il me semble que la version de langage pour d�velopper gcc est quelque chose diff�rent de l'actuel support d'un langage. J'ai peut-�tre rat� quelque chose.

Pas compris. On parle du langage pour �crire gcc et non du langage pris en charge par gcc

Citation:

Envoy� par PINGOUIN_GEANT

Passer de C a C++, qu'est ce que cela veut dire sur l'optimisation des 2 versions de gcc pour compiler du C et du C++ ? Est-ce que la variante pour compiler du C++ est maintenant plus mature que la variante pour le C ? A-t-on des indices pour le savoir (aussi en comparaison des variantes pour Java, FORTRAN 95, etc.) ?

Il n'y a pas plusieurs variantes de gcc, il y a une version de gcc en cours de dev et la prise en charge des langages d�pend : 1. de l'�volution des langages (le C et le C++ ont eu des nouvelles normes r�centes) 2. de la disponibilit� des �quipes de dev
Bref, pas trop compris la question
20/08/2012, 13h18
Freem
Je pense aussi que c'est le num�ro mineur, parce que sinon, la compilation qui met d�j� 50 plombes quand on joue avec quantit� de template mettrait probablement 50 si�cles :D

Pour le reste, je suppose que PINGOUIN_GEANT demande si un compilateur GCC est �crit dans le langage qu'il est cens� compiler... Mais en fait, je suis presque s�r de ne pas trop avoir compris non plus.

Mais bon...
GCC, pour ce que j'en sais, est con�u de fa�on modulaire, quand on �crit un compilateur GCC pour un nouveau langage, on �crit un nouveau module. Pr�c�demment, GCC �tait �crit 100% en C, mais il semble qu'ils aient d�cid� de commencer � utiliser le langage C++ pour continuer certains modules.

Pour ce qui est de l'int�r�t d'utiliser C++ au lieu de C, ce n'est pas tant une question de maturit� du compilateur (puisqu'on pourrait vouloir compiler GCC avec VS, pour ce que j'en sais), mais de techniques utilisables dans les langages.
C++ offre plus de possibilit�s que C pour impl�menter les choses, entres autres parce que C++ est multi-paradigme, alors que C n'en utilise qu'un.
Et, selon l'auteur du PDF que j'ai cit�, C++ permet d'�crire du code plus lisible, et donc plus simple � maintenir, que s'il �tait �crit en C. Cette personne estime aussi que le gain de performance obtenu en �crivant en C est n�gligeable voire inexistant. Elle estime d'ailleurs que sur certains points, le C++ est plus performant.
Cette performance serait par exemple due au fait que, si je me souviens bien, le C n�cessite de d�clarer toutes les variables en d�but de fonction, contrairement au C++.
L'int�r�t de ceci pour le C++, est que l'on peut par exemple �crire cela:
Code:

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:

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.

Autre point sur lequel C++ est meilleur en terme de performance, c'est le support de la RTTI, qui, bien que lourde, est plus rapide que d'effectuer deux fois la conversion d'un type � un sous-type, afin de v�rifier que le type est le bon.

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)
20/08/2012, 13h32
screetch
j'ai lu le PDF et a la page 3 il dit
Code:

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 :(
20/08/2012, 14h16
Tryph

Citation:

Envoy� par Freem

[...]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.
20/08/2012, 14h23
gbdivers

@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)
20/08/2012, 15h45
rt15
Citation:
Envoy� par Freem

Cette performance serait par exemple due au fait que, si je me souviens bien, le C n�cessite de d�clarer toutes les variables en d�but de fonction, contrairement au C++.
L'int�r�t de ceci pour le C++, est que l'on peut par exemple �crire cela:

Code:

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:

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.
Ce code montre aussi beaucoup plus pourquoi le C++ peut �tre plus lent que le C.

Mais parlons donc m�moire tout d'abord. D�j�, le mot "allocation", pour des variables locales ferais presque bondir certaines personnes, assez peu il est vrai. Elle r�servent ce terme aux allocations dynamiques, � base de malloc ou new par exemple. Pour une variable locales, ces personnes parlent plus de "r�servation dans la pile".
Car ces deux m�thode pour obtenir de la m�moire sont tr�s diff�rentes. Dans un cas, on ne change que la valeur d'un registre du processeur pour d�placer la t�te de pile, dans l'autre on appelle toute une machinerie qui g�re un tas.
(C'est a nuancer car il y a toute une gestion de la pile par l'OS derri�re : taille initiale, taille maximale, ajout de pages lors des d�fauts de pages. Mais dans la grande majorit� des cas, la pile est pr�te).

Bref, que repr�sente donc l'"allocation" de f et b dans le code C ci-dessus ? Une mis�rable instruction sub esp, XXX ou XXX correspond (Au moins � peu pr�s, d�pend de la gestion de l'alignement) � la taille d'une instance de Foo + une instance de Bar. Il y aurait 200 variables, il n'y aurait quand m�me qu'une instruction. Pour un co�t � l'ex�cution quasi nul. Effectivement, il y a de la m�moire consomm�e, mais dans la pile donc c'est carr�ment anecdotique -> Par d�faut, la taille max de la pile est de 1 ou 2 Mo (Pr�cis�e dans le .exe par le linker). Malgr� �a, pour faire un d�passement de pile, il faut souvent mettre un bon gros tableau en variable locale, ou faire un r�cursivit� qui ne s'arr�te pas.

Bref, le code C ci-dessus ne coute quasi rien en CPU et pas grand chose en m�moire.

Pouvoir donner une port�e en interne aux variables r�duirait potentiellement un peu la consommation m�moire, mais ralentirait l'ex�cution (1 sub esp, XXX par port�e, et pourquoi pas un add esp � la fin des port�es).

En fait, pouvoir limiter la port�e des variables comme ci-dessus sert surtout au C++. Non pas pour limiter la consommation m�moire, d'ailleurs, mais la consommation CPU !

Et c'est l� tout le pi�ge du C++ en ce qui concerne les performances !

Le code C ci-dessus est quasi instantan�. Il ne PEUT PAS prendre de temps.
Mais le code C++ ci-dessus prend un temps... Inconnu ! Peut �tre plusieurs secondes ! Peut �tre des heures... Avec juste ce bout de code, on ne sait pas ce que le processeur va devoir ex�cuter.

Tout d�pend en effet des constructeurs de Foo et Bar ! Et c'est pour �a que la port�e limit�e est bien plus int�ressante en C++ qu'en C, par exemple pour ne pas ex�cuter de constructeurs d'instances dont on a pas besoin.

Et c'est une des raisons pour laquelle une impl�mentation en C est souvent plus rapide. Car le C colle au comportement du processeur, l� ou le C++ permet d'ajouter de l'abstraction qui nous cache des instructions.
20/08/2012, 16h02
gbdivers

8O 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)

Effectivement, le message est assez fin, et est presque plus philosophique que technique. Mais prenons par exemple le code C++ suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #include <vector> #define VECTOR_SIZE 10000000 int main() { std::vector<int> my_vector(VECTOR_SIZE); for (int i = 0; i < VECTOR_SIZE; i++) my_vector[i] = i; return 0; }
On construit un vecteur de int avec chaque �l�ment qui est �gale � son indice.
Bien s�r, un vector n'est pas tr�s adapt�, mais c'est pour l'exemple.

La question est : combien de fois les �l�ments du vecteurs sont ils parcourus et affect�s ?

Ne lisez pas la suite avant de vous �tre pos� la question !

On comprend bien qu'un seul parcourt devrait suffire pour r�aliser cette t�che. Pourtant le code ci-dessus en fait deux. Les �l�ments sont initialis�s � z�ro dans le constructeur, et ce quel que soit le niveau d'optimisation donn� au compilo.

Encore une fois, ce n'est pas tranchant comme argument. Mais en lisant le code, on a quand m�me bien l'impression de voire une complexit� en n, pas en 2n. Tout �a � cause d'un constructeur qui ex�cute du code dans notre dos, sans que �a ait d'int�r�t pour nous. 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. :aie:

Pour en revenir � la philosophie, on peut remarquer que ce genre de "d�tail" � une f�cheuse tendance � �tre plus rep�r� par des d�veloppeurs C que des d�veloppeur C++. Nan mais franchement, vous imagineriez une double initialisation d'une liste dans le noyau linux ? �a ferait pas tr�s s�rieux quand m�me...:cry:

20/08/2012, 18h47
gbdivers

Ok donc �a confirme ce que je dis

Citation:

Envoy� par gbdivers

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

Citation:

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

Citation:

de voire une complexit� en n, pas en 2n

Jusqu'au derni�re nouvelle, O(n) = O(2n)

Citation:

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 :

Citation:

Effectivement, le message est assez fin, et est presque plus philosophique que technique.

Merci de ne pas prendre les gens de haut
21/08/2012, 09h22
transgohan

Citation:

Envoy� par gbdivers

Jusqu'au derni�re nouvelle, O(n) = O(2n)

Seulement apr�s simplification (qu'on effectue dans 99% des cas je te l'accorde, mais si on veut parler bien, parlons bien !).
Certains chercheurs travaillent dans des domaines o� ils ne peuvent se permettre de dire que O(10n) est n�gligeable et �quivalent � O(n). ;)

mathematiquement, O(2n) est equivalent a O(n)
programmatiquement, le code philosophique de rt15 n'est pas equivalent a son pendant vector, le code equivalent est:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 #include <vector> #define VECTOR_SIZE 10000000 int main() { std::vector<int> my_vector; my_vector.reserve(VECTOR_SIZE); for (int i = 0; i < VECTOR_SIZE; i++) my_vector.push_back(i); return 0; }
ou il n'y a qu'un seul parcours (le O(1N) philosophique)
pour en revenir au sujet sur GCC, nul doute que les erreurs sur la page 3 du PDF sont simplement de l'inattention (un copie/colle vite fait) puisque il cumule 4 erreurs en 3 lignes (1 - pointeur sur vecteur, 2 - operateur [] sur le pointeur et non sur le vecteur, 3 - acces hors borne puisque il y a depth elements donc le dernier est depth-1, 4 - reserve ne grandit pas le vecteur, donc il y a toujours 0 element dans le vecteur).

meme un programmeur C qui n'a jamais code C++ aurait fait mieux, je suppose donc une simple slide fait a la va-vite.

21/08/2012, 10h51
Hibernatus34
Citation:
Envoy� par Freem

Code:

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:

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 :)

Pour le d�bat O(2n) est equivalent a O(n), c'est vrai pour les maths.
Maintenant, si les sprinters se mettaient � courir le 100m en 20 secondes, me semble que la diff�rence vous sauterait aux yeux, non ? Un programme qui deviens deux fois plus lent, �a pique en g�n�ral.

Pour ce qui est de l'utilisation de "reserve", en th�orie c'est bien, �a ram�ne probablement � un parcourt de tableau... Sauf que compil� avec g++ (En -O2 ou -O3), le code avec reserve met un temps tout � fait similaire � mon code. Les deux mettant � peu pr�s deux fois le temps pass� sur un parcourt unique...

A v�rifier, mais je suppose que c'est d� au fait que push_back a plus de boulot � faire que l'op�rateur []. Bilan la complexit� a beau �tre n, l'op�ration r�alis�e est deux fois plus complexe (Mise � jour de la size du vecteur probable par exemple).
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 #include <vector> #include <iostream> #include <windows.h> using namespace std; #define VECTOR_SIZE 20000000 int array[VECTOR_SIZE]; void constructor() { vector<int> my_vector(VECTOR_SIZE); for (int i = 0; i < VECTOR_SIZE; i++) my_vector[i] = i; } void browse() { for (int i = 0; i < VECTOR_SIZE; i++) array[i] = i; } void reserve() { std::vector<int> my_vector; my_vector.reserve(VECTOR_SIZE); for (int i = 0; i < VECTOR_SIZE; i++) my_vector.push_back(i); } int main() { LARGE_INTEGER starting; LARGE_INTEGER end; for (int i = 0; i < 10; i++) { QueryPerformanceCounter(&starting); constructor(); QueryPerformanceCounter(&end); cout << end.QuadPart - starting.QuadPart << endl; QueryPerformanceCounter(&starting); reserve(); QueryPerformanceCounter(&end); cout << end.QuadPart - starting.QuadPart << endl; QueryPerformanceCounter(&starting); browse(); QueryPerformanceCounter(&end); cout << end.QuadPart - starting.QuadPart << endl; cout << endl; } return 0; }
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 233871239 232111922 161693399 236877116 232803109 115653265 237220459 234170832 114499161 237944784 237114185 115160248 239684284 233381540 114996329 238357294 232007671 114847537 246558018 231487116 120612464 267180473 244786381 103820297 272322960 238285341 116277903 243198732 232527302 115246334
Quand je dis "fin", c'est pour dire que c'est petit voire n�gligeable (En th�orie on peut m�me tout � fait dire que les perfs C vs C++ sont comparables), pas pour dire qu'il faut �tre un super h�ro pour voir la diff�rence.

Mais c'est juste que quand des gens commencent � �crire que passer du code C en C++ peut, notamment, am�liorer les perfs... C'est comme dire que le java peut �tre plus rapide que l'assembleur. C'est vrai (Encore que je n'ai jamais eu la preuve montre en main :roll:), mais c'est beaucoup plus rare que l'inverse.

21/08/2012, 11h47
Hibernatus34

rt15:
1. Le fait de mettre 2 fois plus de temps � alimenter un tableau est n�gligeable, le fait de pouvoir acc�der � ce tableau aussi efficacement qu'en C, une fois ce tableau aliment� est beaucoup plus important pour la plupart des algorithmes. Tu ne d�velopperas pas de programmes plus rapides avec des raisonnements aussi limit�s.

2. Certaines optimisations ne sont envisageables qu'� un certain niveau d'abstraction. Pour prendre un exemple qui te parlera je pense, imagine programmer tout Photoshop en assembleur en entrela�ant � la main les instructions pour b�n�ficier des fameuses optims du Pentium... Heureusement qu'il existe le compilo C capable de le faire � ta place.

L'exemple typique du C++ plus rapide que le C, c'est le qsort Vs. std::sort.
21/08/2012, 12h03
screetch

Citation:

Envoy� par rt15

...

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...
21/08/2012, 12h08
rt15

Dommage que le code de photoshop ne soit pas libre.
D'apr�s le web, photoshop utilise ou utilisait pas mal SSE2.
SSE2 n'est pas utilisable efficacement en C, tout du moins pas sans une biblioth�que. Une biblioth�que �crite partiellement en assembleur.
L'alternative est d'utiliser directement l'assembleur.

A ma connaissance, aucun compilateur C ou C++ � l'heure actuelle n'est tout simplement capable d'optimiser des calculs efficacement en utilisant SSE. Car il faut une compr�hension profonde des dits calculs pour pouvoir les rendre parall�les et adapt�s � SSE. Les compilos peuvent utiliser SSE pour des "d�tails", fonctions built-in ou autre, mais ils ne vont pas transformer nos propre code de calcul en du jolie code machine exploitant bien SSE.

Photoshop est pr�cis�ment dans le cas o� une optimisation tr�s travaill�e a �t� mise en place. Car pour certaines partie du code, la performance est critique. Et ils ont fait quoi ? Ils ont fait du C++ ???? Non, ils ont certainement fait de l'assembleur, ou utiliser une biblioth�que faite en assembleur.

Pour optimiser, on se rapproche de la machine. C++ -> C. C -> ASM. On ne fait pas du haut niveau. �a marchera seulement quand les compilos seront plus intelligent que les hommes.

Merci pour qsort, vs sort, je vais voire �a.

[edit]
Mon code C++ ci-dessus n'est pas l� pour comparer les temps C vs C++, surtout que c'est que du C++ lol. C'est plus pour comparer reserver et le constructeur et se donner une id�e de ce que �a donne par rapport � un parcourt simple.
21/08/2012, 12h13
screetch

pour optimiser, on s'approche de la machine en C comme ne C++ comme en assembly, ca passe en premier lieu par une grosse optimisation du cache memoire qui est le bottleneck de toute application, surtout photoshop (on comprend bien que photoshop, c'est le processing d'image hein qu'il faut optimiser, pas l'interface utilisateur)

et on utilise SSE en C++ avec les "intrinsic", et on encapsule le tout dans des classes C++. Eh ouais, c'est comme ca qu'on fait, on ecrit pas de l'assembleur.

j'ai travaille sur d'autres codes ou la performance etait critique, il y avait pas une goutte d'assembleur, c'etait du C++ avec des intrinsic, et une tres tres grosse passe pour faire du traitement par batch (qui n'est as contraire au C++ mais la le C++ n'est pas forcement l'outil le plus adapte)

la meilleure preuve que photoshop ne doit pas contenir d'assembleur, c'est que sous visual studio en configuration 64bits on a plus le droit a l'assembleur.
21/08/2012, 12h17
Hibernatus34

Je suis d'accord rt15. Mais justement, si on peut combiner plusieurs langages c'est id�al.
L'assembleur tu l'utiliseras pour du code court et ex�cut� � haute fr�quence.
Le C++ permet de faire de l'assembleur inline, mais aussi du C inline d'une certaine mani�re.

Et je suis s�r qu'un d�veloppeur avis� sur les questions de bas niveau tel que toi, probablement adepte aussi de code explicite et simple, ferait un tr�s bon d�veloppeur C++, juste diff�rent des d�veloppeurs C++ qui aiment d�velopper des templates monstrueux, ou ceux qui veulent faire du Java en C++ etc. A chacun sa mani�re de profiter du C++, mais refuser en bloc le C++ n'a pas de sens.

PS. screetch : asm inline ou intrinsics, franchement quand tu vois la t�te d'un code bourr� d'intrinsics SSE2 c'est kif-kif :)
Et l'assembleur, m�me s'il est pas inline peut �tre link� � un projet C++, c'est pas tellement le probl�me (j'esp�re quand m�me que Microsoft va r�tablir l'inline :))

Citation:
Envoy� par screetch
programmatiquement, le code philosophique de rt15 n'est pas equivalent a son pendant vector, le code equivalent est:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 #include <vector> #define VECTOR_SIZE 10000000 int main() { std::vector<int> my_vector; my_vector.reserve(VECTOR_SIZE); for (int i = 0; i < VECTOR_SIZE; i++) my_vector.push_back(i); return 0; }
Le v�ritable code C++ �quivalent au code de rt15 serait l�utilisation de std::array.
Son code C utilise un tableau statique, le std::vector a une s�mantique de tableau dynamique (avec ce que �a implique comme surco�t). Donc la comparaison est biais�e.
D�ailleurs, en utilisant std::array il n�y a pas de diff�rence de perf� entre le C et le C++ sur cet exemple (qui vaut ce qu�il vaut).

21/08/2012, 12h44
Freem

Citation:

Envoy� par Hibernatus34

Je suis d'accord rt15. Mais justement, si on peut combiner plusieurs langages c'est id�al.
L'assembleur tu l'utiliseras pour du code court et ex�cut� � haute fr�quence.
Le C++ permet de faire de l'assembleur inline, mais aussi du C inline d'une certaine mani�re.

Et je suis s�r qu'un d�veloppeur avis� sur les questions de bas niveau tel que toi, probablement adepte aussi de code explicite et simple, ferait un tr�s bon d�veloppeur C++, juste diff�rent des d�veloppeurs C++ qui aiment d�velopper des templates monstrueux, ou ceux qui veulent faire du Java en C++ etc. A chacun sa mani�re de profiter du C++, mais refuser en bloc le C++ n'a pas de sens.

PS. screetch : asm inline ou intrinsics, franchement quand tu vois la t�te d'un code bourr� d'intrinsics SSE2 c'est kif-kif :)
Et l'assembleur, m�me s'il est pas inline peut �tre link� � un projet C++, c'est pas tellement le probl�me (j'esp�re quand m�me que Microsoft va r�tablir l'inline :))

Je n'ai pas l'impression qu'il refuse le C++ en bloc.
Il argumentait juste sur le fait que j'ai dit que le C++ pourrait optimiser le code, nuance.
Le souci ayant �t� que, comme lui avec son exemple du vector, j'aie pris un (tr�s) mauvais exemple.

Personnellement, je pense que C et C++, bien utilis�s, sont aussi rapides l'un que l'autre (C �tant un sous-ensemble du langage C++, dans celui-ci).
0 diff�rence, vu qu'au final, tous les langages natifs sont �gaux face au code machine.
Le probl�me �tant que, pour moi, et je crois ne pas �tre le seul � le penser, bien utiliser le C est plus complexe que bien utiliser le C++.

Par exemple, dans les documents de GCC, il est pr�cis� qu'ils utilisent un garbage collector en C.
Bien.
Le probl�me des garbage collector, selon moi, c'est qu'ils ne lib�rent pas la m�moire aussit�t qu'elle n'est plus n�cessaire, contrairement � la RAII.
Sans compter que la m�canique interne du GC n�cessite s�rement des variables, qui vont �tre modifi�es par des calculs, ce qui consomme du temps processeur. Ensuite, le GC, si je ne suis pas dans le faux, va appeler la fonction qui permet de lib�rer l'objet en question.

Pourquoi avoir utilis� un GC?
Je pense que c'est parce que l'usage de la RAII est plus contraignant en C qu'en C++.
Niveau performance, il me semble �vident que la RAII soit plus efficace dans l'absolu qu'un GC (m�moire lib�r�e aussit�t => moins de swap et moins de changement de segment de donn�es. Dans l'absolu, am�lioration - faible pour les changement de segment - des perf. Et �conomie d'un m�canisme de GC, qui doit au final lib�rer quand m�me la m�moire, re am�lioration probable des perf).

Le fait est qu'en C++ aussi, on peut avoir un GC. Mais que la RAII, est aussi nettement plus simple � utiliser en C++ qu'en C: pas besoin de penser tout le temps a appeler un faux destructeur ou un faux constructeur.

De ce changement de langage, ce qui va en r�sulter, c'est donc, pour moi, un changement naturel et progressif dans l'architecture du logiciel, qui devrait pouvoir permettre des am�liorations de perf.

Effectivement, j'avais totalement tord en prenant le raccourcis C++ peut rendre le code plus rapide.
Mea culpa donc.

PS: je me permet tout de m�me de dire que l'exemple du vector m'a piqu� les yeux, mais c'est de bonne guerre, mon exemple ayant aussi �t� mauvais: dans la pratique, je n'utilise pas le changement de scope de fa�on aussi laide, mais plut�t des fonctions, le compilo me les mettant je pense inline selon les options de compilation et la situation.
C'�tait pour l'exemple, mais il �tait tr�s mauvais :D

Par rapport � votre d�bat "O(2n) est equivalent a O(n)" la r�ponse est tr�s simple.
En maths, il ne me semble pas que �quivalent soit �gal. Donc, O(2n) �quivaut toujours � O(n), mais O(2n) diff�re de O(n). Me semble m�me me souvenir que les matheux ont un symbole sp�cial pour l'�quivalence...
Mais bon, moi et les maths...
21/08/2012, 12h57
screetch

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:

Citation:

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.