Développé depuis au moins 1987 (la v1.0 est sortie le 23 mai 1987, la v2.0 le 22 février 1992), le passage à GCC version 3.x (18 juin 2001) a apporté beaucoup de changements : optimisations diverses, améliorations du C++ et consorts, meilleure prise en compte des architectures non-x86, etc.
Voici donc un court article (ses commentaires et sa collection de liens) sur le vrai et le faux des optimisations GCC les plus courantes.
Aller plus loin
- GCC Myths and Facts (1 clic)
- GCC (1 clic)
- GCC Development Plan (1 clic)
# Re: Editorial FreshMeat sur GCC
Posté par Mathieu Pillard (site web personnel) . Évalué à 5.
[^] # Re: Editorial FreshMeat sur GCC
Posté par Nÿco (site web personnel) . Évalué à 4.
This article is written for the average desktop Linux user and with the x86 architecture and C/C++ in mind, but some of its content can be applied to all architectures and languages.
...sinon plus bas :
Interesting Links
* http://www.gnu.org/software/gcc/(...)
* http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/(...)
* http://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html(...)
* http://www.redhat.com/software/gnupro/technical/gnupro_gcc.html(...)
* http://www.freshmeat.net/projects/prelink/(...)
* http://www.tldp.org/HOWTO/GCC-HOWTO/index.html(...) (last updated in May of 1999)
[^] # Re: Editorial FreshMeat sur GCC
Posté par dvrasp . Évalué à 1.
# gcc 3.2
Posté par benja . Évalué à 10.
Cf. un thread sur les list openbsd. http://marc.theaimsgroup.com/?l=openbsd-tech&m=104453801914141&(...)
http://marc.theaimsgroup.com/?l=openbsd-tech&m=104456745628909&(...)
[^] # Re: gcc 3.2
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 9.
[^] # Re: gcc 3.2
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
[^] # Re: gcc 3.2
Posté par let antibarbie = xp <- xp - 1 . Évalué à 5.
Non sans dec' ! Le support de la STL est une bénédiction (même si les foncteurs ca vaut pas encore les langages fonctionnels), et les temps de compilation... ben il faut bien gérer ses #include et ses dépendances... et à moins de compiler sur un vieux sparc, ca vaut pas un meilleur compilo et un meilleur code.
[^] # Re: gcc 3.2
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
et les temps de compilation... ben il faut bien gérer ses #include et ses dépendances
Justement, les templates font exploser ça, tu es obligés d'inclure plein de choses (en plus du temps de génération du code pour les templates instanciés).
[^] # Re: gcc 3.2
Posté par reno . Évalué à 8.
Ca devrait accelerer pas mal les choses (ne serait-ce que la compilation des librairies STL)..
[^] # Re: gcc 3.2
Posté par Fabimaru (site web personnel) . Évalué à 6.
Pour les mecs qui ont un parc de machines minimal, un programme comme distcc (lancement de compilation distribuée sur le LAN, j'ai jamais essayé) a un impact énorme. J'ai essayé IncrediBuild (propriétaire, Windows) qui marche sur le meme principe et c'est formidable. Je ne pense pas qu'on puisse avoir un meme gain de vitesse de compil du meme ordre avec des progrets de gcc.
[^] # Re: gcc 3.2
Posté par duf . Évalué à 1.
Sincèrement ça vaut le coup d'essayer !
[^] # Re: gcc 3.2
Posté par cozon (site web personnel) . Évalué à 2.
Jusqu'ici, j'utilise un autre solution : Je monte le / de ma gentoo via NFS sur le /mnt/gentoo d'un PC plus puissant.
Ensuite je vais un chroot, un source /etc/profile puis un env-update et zou, je retrouve ma gentoo et je peux compiler des gros trucs.
Attention, genre pour compiler kde ça génére énormément de trafic via le réseau, de l'ordre du giga-octet.
[^] # Re: gcc 3.2
Posté par printakilla . Évalué à 10.
Euh... à part les développeurs, qui se soucie de la vitesse de compilation?
En tant qu'utilisateur je me moque bien de savoir combien de temps a duré la compilation des logiciels, ce qui m'intéresse c'est leur efficacité, et la vitesse d'éxécution en est un paramètre.
En fait, la bonne technique c'est d'avoir un compilateur rapide pour le développeur, pendant la phase de développement, et un compilateur efficace (qui génère du code rapide) pendant la phase d'intégration.
Au fait, je signale que dans ma boîte, on utilise gcc au service d'intégration (on vient de passer de 2.7 à 2.9 ; pour la 3.x attendez un peu ^_^)
[^] # Re: gcc 3.2
Posté par Guillaume Thomassin . Évalué à 0.
--
Chuchi
PS: par client j'entends pas uniquement le client final qui achete le soft, mais aussi les equipes de tests, ...
[^] # Re: gcc 3.2
Posté par Bouiaw . Évalué à 4.
[^] # Re: gcc 3.2
Posté par Jean-Yves B. . Évalué à 1.
# Mauvaise nouvelle
Posté par matiasf . Évalué à -10.
Hein, non j'ai rien dit.
# Re: Editorial FreshMeat sur GCC
Posté par Nicolas Boulay (site web personnel) . Évalué à -2.
-O3 -fomit-frame-pointer -funroll-all-loops (-ffast-math)
C'est en moyenne le plus rapide.
"La première sécurité est la liberté"
[^] # Re: Editorial FreshMeat sur GCC
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Je serais ravi de voir des stats de performance sur des codecs vidéos entre autres pour déterminer EN SITUATION quelle sont réellement les meilleures options de compilation.
[^] # Re: Editorial FreshMeat sur GCC
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Sauf que c'est complètement faux ! C'est une croyance type légende urbaine qui traine. Faite le test ! Un type (de suse ?) fait un test continue de qualité de gcc, -funroll-all-loops est même mieux que -funroll-loops alors que cela doit prendre plus de place en mémoire.
La perte dans le cache est tout à fait minime en comparaison du gain du à la diminution du nombre de saut et des bulles dans le pipeline.
(mais pourquoi mon poste précédent est à -3 ?)
Je serais ravi de voir des stats de performance sur des codecs vidéos entre autres pour déterminer EN SITUATION quelle sont réellement les meilleures options de compilation.
Leur boucle principal est souvent en assembleur, donc tu ne peux pas gagner grand chose.
"La première sécurité est la liberté"
[^] # Re: Editorial FreshMeat sur GCC
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
Sur quel type de code ? Si c'est sur un benchmark ou un truc hyper-spécialisé genre codec video, ça n'a pas vraiment de rapport avec une appli réelle.
[^] # Re: Editorial FreshMeat sur GCC
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Editorial FreshMeat sur GCC
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Editorial FreshMeat sur GCC
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
De toute façon, je ne crois pas que des applications comme KOffice ou Oo compile avec autres choses que "-02 -g".
"La première sécurité est la liberté"
[^] # Re: Editorial FreshMeat sur GCC
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
Par "applications" je veux dire "vrais logiciels qui servent à quelque chose", genre Word, Excel, Photoshop, etc... pas "20 petits bouts de code qui font tourner un vague algo". Par ailleurs SPEC c'est pas juste un benchmark (mais dans le cas présent il doit s'agir de SPEC CPU).
http://www.spec.org/(...)
De toute façon, je ne crois pas que des applications comme KOffice ou Oo compile avec autres choses que "-02 -g".
Je ne comprends pas ce que tu veux dire. Que KOffice ou OpenOffice ne compilent pas avec -funroll-loops ? A quoi sert ce flag si il ne marche pas sur une vrai appli alors ? :-)
[^] # Re: Editorial FreshMeat sur GCC
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Sur PowerPC TOUT se compile avec :
-pipe -O3 -fsigned-char -fomit-frame-pointer -march=750
sauf postgresql ou je doit mettre -O2 et guile ou je doit me contenter de -O0.
Le résultat fonctionne sur G3 et G4.
Pour les applis C++ j'essaie de rajouter autant que possible -fno-exceptions -fno-rtti mais beaucoup d'applis ont besoin des exceptions ou de rtti et on ne peut le savoir qu'à la compilation ou à l'exécution si ya des plantages...
J'ai décidé depuis peu de rajouter l'option -ffast-math à tout sauf les bibliothèques et applis scientifiques. Si yen a qui on des retours d'expérience avec cette option je suis preneur.
Suite à cette article je vais aussi rajouter -DNDEBUG -DG_DISABLE_ASSERT pour voir...
[^] # Re: Editorial FreshMeat sur GCC
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Editorial FreshMeat sur GCC
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
SI, ça marche ! Faut lire la doc !
> Gentoo linux compile KDE avec -02 -g
Comme quoi la Gentoo est loin d'etre aussi optimisé que beaucoup le prétende !
Je profite de la perche qui m'est tendu pour dire halte aux idées reçus. Non la gentoo n'optimise pas par défaut les softs qu'elle installe !!!
Gentoo a peut-etre fait ce choix car avec -O3 la compilation de KDE prend beaucoup plus de temps et nécessite beaucoup plus de mémoire...
[^] # Re: Editorial FreshMeat sur GCC
Posté par Alberto . Évalué à 0.
[^] # Re: Editorial FreshMeat sur GCC
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
# Re: Editorial FreshMeat sur GCC
Posté par thedidouille . Évalué à 3.
[^] # Re: Editorial FreshMeat sur GCC
Posté par Prae . Évalué à 3.
Je pensais que c'était une documentation plus consistante et pas seulement 3 ou 4 points qui se battent en duel ... dommage.
Malgrès tout, on apprend des trucs ;)
[^] # Re: Editorial FreshMeat sur GCC
Posté par Benjamin . Évalué à 3.
Je me souviens meme avoir vu un edito sur le multimédia sous Linux qui était bourré d'erreurs
# OffTopic: cherche qq'un pour porter gcc
Posté par Philippe F (site web personnel) . Évalué à 7.
# C++ et gcc-3.X.X
Posté par sToR_K . Évalué à 2.
Pleins d'applis qui passait très bien, sans warnings avec gcc-2.95 se vautrent comme des otaries bourrés à la bière avec gcc-3.(problème STL, string.h, etc..)
Je précise que c'est vraiment l'implémentation qui a changé parce que j'ai les mêmes messages sur debian et OS X...
[^] # Re: C++ et gcc-3.X.X
Posté par notrya2 . Évalué à 3.
C'est un problème d'appli et non de gcc. Je n'ai trouvé que çà comme explication un peu détaillée :
http://www.redhat.com/advice/speaks_gcc.html(...)
[^] # Re: C++ et gcc-3.X.X
Posté par let antibarbie = xp <- xp - 1 . Évalué à 2.
C'etait aussi un gros desavantage lorsque tu voulais compiler ailleurs, (chez sun / intel / m$ / borland), ca compilait pas mais alors pas du tout...
maintenant c'est très axé sur les standards et ça n'accepte plus certains petits écarts de rien du tout qui passaient avant comme une fleur... bon ça oblige a coder proprement, et finallement c'est pas plus mal.
Y'a aussi les extensions a la STL qui sont bien séparées comme étant des extensions (comme on en parle un peu plus bas), mais ca choque au debut.
Mais franchement faudrait un bon gros standard derriere tout ca avec au moins des hash_map de base ! Si vous en avez pas assez de la STL, y'a BOOST http://www.boost.org/(...) qui est un truc sympa (mais ca vaudra toujours pas les langages fonctionnels).
[^] # Re: C++ et gcc-3.X.X
Posté par pingoo35 . Évalué à 2.
Arrete de troller pour les langages fonctionnels ! Je serai convaincu de leur superiorite quand tu aura porte album.pl en caml !
[^] # Re: C++ et gcc-3.X.X
Posté par let antibarbie = xp <- xp - 1 . Évalué à 0.
[^] # Re: C++ et gcc-3.X.X
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
album.pl ? google me donne ça : http://perl.bobbitt.ca/album/(...)
C'est pas une appli ça, c'est un jouet. Essaie un vrai truc genre KWord, tu aura prouvé quelque chose.
[^] # Re: C++ et gcc-3.X.X
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: C++ et gcc-3.X.X
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
[^] # Re: C++ et gcc-3.X.X
Posté par let antibarbie = xp <- xp - 1 . Évalué à 0.
[^] # Re: C++ et gcc-3.X.X
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: C++ et gcc-3.X.X
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 3.
vraiment la norme C++, notamment les 'namespaces' qui sont des regroupement de classes, de fonctions etc ... (un:
using namespace std;
using namespace __gnu_ccx; //hash_map et certaines autres classes
permet de corriger cela)
deplus la norme ansi-c++ defini les entete de la librairie standard comme suit:
#include <string> //pour classe string
#include <sstream> // pour classe stringstream
#include <iostream> // cout et cin notamment
etc..
et donc la libstdc++ a ete corrige en ce sens
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.