GCC est un ensemble de compilateurs largement utilisé pour la création des logiciels open source. La version 5.0, qui sera publiée dans quelques semaines, proposera une vaste liste d’améliorations, dont la plus importante est très clairement l’utilisation par défaut de la norme C11, en lieu et place de la C89.
GCC passe de la norme C89 à C11
GCC (GNU Compiler Collection) 5.0 arrivera bientôt et les développeurs devront absorber une vraie vague de nouveautés. La plus importante concerne ceux qui codent en C puisque le compilateur utilisera par défaut GNU11 au lieu de GNU89. Il s’agit respectivement des implémentations des normes ISO C11 et C89, ce qui signifie une modernisation évidente dans le compilateur dans ses réglages par défaut. On remarquera d’ailleurs que GCC avait fait l’impasse sur la norme C99, sortie entre temps, comme norme de base pour la compilation.
Les normes C définissent le socle standard qu’un développeur peut attendre d’un compilateur en particulier. Par exemple, C11 a apporté la possibilité d’aligner les structures, le support des structures et des unions anonymes, a amélioré la gestion du multithreading et la gestion des chaines Unicode, etc. Bien entendu, rien n’empêchait les développeurs d’activer la norme C11, mais l’utilisation par défaut reste une étape cruciale.
Nombreux ajouts d'architectures et optimisations diverses
GCC 5.0 contiendra également de nombreuses améliorations. Par exemple, les optimisations interprocédurales (conçues pour améliorer les performances dans le code utilisant fréquemment les mêmes fonctions de petite et moyenne tailles) peuvent réaliser une nouvelle passe Identical Code Folding (ICF) permettant de regrouper les fonctions identiques. Diverses optimisations sont présentes, notamment sur les tables virtuelles, les variables en écriture seule ou encore quand les link-time optimizations (LTO) sont activées.
Côté support, cette version 5.0 de GCC ne sera pas en reste, avec notamment :
- Les extensions AVX-512 dans les futurs processeurs Xeon de la génération Skylake
- De nombreuses fonctionnalités de C++14
- L’interface de programmation parallèle Cilk Plus d’Intel
- OpenMP 4.0 (programme parallèle là encore) pour C, C++ et Fortran
- Le langage Go (de Google) dans sa version 1.4.2
- MIPS Release 3, 5 et 6
- L’arrivée de la compilation du Just-In-Time (JIT) pour la bibliothèque libgccjit, même si cette dernière est toujours expérimentale.
Les développeurs intéressés pourront lire sur le site officiel de GCC la très longue liste des améliorations prévues. Nous mettrons évidemment à jour cette actualité pour signaler la disponibilité du compilateur. On notera également que la future version 22 de Fedora intègrera GCC 5.0 par défaut.
Commentaires (51)
#1
Etant un grand utilisateur de MinGW, j’attends de voir si ce sera plus performant que la 4.7, parce que pour l’instant, autant au niveau taille de code que vitesse d’exécution, les 4.8 et 4.9 (surtout la 4.8 qui est une horreur sans nom) sont vraiment à la ramasse.
Dans tous mes projets, je suis bloqué sur la 4.7 pour ces raisons.
#2
Plus qu’à attendre que tout le monde se mettent à jour…
…. et je crains que le processus dure encore plus longtemps que la disparition d’IE6.
#3
> On remarquera d’ailleurs que GCC avait fait l’impasse sur la norme C99 sortie entre temps.
Dire que l’impasse a été faite sur c99 est un peu fort… Voir ici et là pour les supports de c99 dans gcc (depuis la version 4.5).
Après, on es d’accord, par défaut, gcc ne compile pas du c99, il faut lui demander explicitement pour qu’il le fasse.
#4
Ça tombe bien, on parle de norme par défaut pour la compilation. Mais j’ai insisté un peu plus sur ce point dans une petite modification.
#5
Je me demandais si “ton” problème venait de GCC ou du couple GCC/Windows.
#6
Qu’est-ce que Windows vient faire là-dedans ?
Je parle de performance pure, de code effectuant des calculs qui pourrait être porté sur Linux avec pratiquement aucune modification.
Quant aux appels système, c’est toujours le même système qui est en-dessous. Windows ne se décide pas à ralentir subitement s’il détecte que l’exécutable est issu d’une version de GCC qu’il n’aime pas.
Je ne suis d’ailleurs pas le seul à avoir constaté ça : https://bbs.archlinux.org/viewtopic.php?id=160566
Et là, c’est pas du Windows…
Pour moi c’est un fait : il n’y a aucune vérification des performances globales dans la pratique. Lorsque la 4.7 est sortie, je l’ai comparée aux compilos d’Intel et de MS : GCC 4.7 produit un code presque aussi rapide que le compilateur d’Intel de l’époque (et bien sûr, je l’ai testé sur plusieurs trucs).
Et je me souviens, avant d’avoir arrêté de coder pendant quelques années, qu’il y a une dizaine d’années, c’était pareil : les performances variaient vers le haut ou vers le bas d’une version à l’autre, et les différences étaient à chaque fois énormes, tout comme aujourd’hui.
Ca ne m’arrange pas parce que l’implémentation des intrinsics AVX de la 4.7 n’est pas complète. Et l’ASM n’est plus trop ma tasse de thé.
#7
#8
Peut être pas assez présent dans la news, mais ca fait longtemps que C++11 était supporté, contrairement par exemple à msvc.. On peut critiquer GCC pour la vitesse de compilation (encore que, avec ccache sous linux ce n’est pas vraiment un souci), mais on peut dans la même phrase se souvenir que les binaires produits sont super rapides, et que le support des nouvelles normes arrive bien plus vite que chez Microsoft.
On utilise c++11 autant que possible dans ma boîte, ca change vraiment la vie, presqu’un nouveau langage (mais toujours aussi rapide). Le meilleur de plusieurs mondes !
#9
{{trololololo}}
booba à propos du développeur C “fouiny babe” : sale pointeur!{{/trololololo}}
#10
La référence en matière de perf c’est quand même CLang. Même si GCC rattrape son retard.
#11
en vitesse de compilation peut être. En vitesse du binaire pas vraiment, sans OpenMP Clang est un peu largué sur toutes les applications hautes performances… (ok, ca arrive)
#12
Et typiquement sur du code fortement métaprog, clang est encore en retard sur les exécutables que peut produire gcc. Par contre effectivement, il est bien plus rapide pour compiler et l’affichage des erreurs est plus clair.
" /> .
Par contre comparer les performances ça devient compliqué, en présence de code concurrent très bas niveau, les compilateurs font de toute façon des optimisations qui sont unsound, donc ça devient un peu chaud de déterminer lequel produit des exécutables rapides ET corrects
#13
#14
#15
Sur quels benchs tu te bases ?
Moi j’ai toujours lu que Clang était plus rapide, en tout cas concernant le C++.
Par exemple ici.
Après GCC commence à intégrer les optimisations qui ont été développées dans Clang et donc s’améliore de version en version.
J’utilise pas OpenMP, j’utilise HPX qui est aussi réputé pour être plus rapide que OpenMP.
#16
Super, merci pour l’éclaircissent du texte.
#17
premier bench de ton lien, qui utilise openmp, gcc est N fois plus rapide (lié au nombre de processeurs et à la boucle openmp qui n’est pas déroulée). Je ne dis pas qu’il n’y a pas des situations dans lesquelles Clang n’est pas plus rapide, mais pour l’instant si tu te soucies de la performance de ton binaire, alors il y a de fortes chances que tu utilises OpenMP, et dans ce cas là Clang est hors jeu (pour l’instant). C’est un problème de support d’une norme, pas de qualité de Clang bien sûr, mais comme les autres différences entre compilos sont +-10% (hors benchs sur le temps de compilation, mais il y a pas mal de cas dans lesquels osef), ce support de OpenMP fait toute la différence
#18
#19
#20
#21
ok pour hpx sinon, je ne connaissais pas, mais c’est une lib ? je vais regarder ca, merci pour l’info, on dirait du boost en plus digeste
#22
#23
Hmm, j’avais regardé Rust il y a quelques temps, c’est bien le truc qui n’est toujours pas fini ? Je ne dis pas qu’il n’y a pas mieux que c++11, mais il a le mérite d’exister :) Sinon le threading a l’air assez facile, mais le problème c’est aussi le contenu : tu fais quoi avec Rust ? Il existe des libs ? C’est aussi le souci avec ces nouveaux languages, sympa mais c’est rare que tu refasses tout de zéro, tu prends aussi des libs existantes dans la vraie vie. Plus facile d’innover aussi quand tu te fous de la compatibilité ascendante..
#24
#25
#26
Euh non, Clang compile plus vite mais GCC produit du code plus rapide :http://linuxfr.org/users/patrick_g/journaux/gcc-vs-llvm
#27
Je ne connaissais pas Rust, je suis dev c++ et j’avoue que je trouve ca pas mal, surtout que j’ai pas mal réfléchie à comment faire de la programmation fonctionnelle en c++.
Tu aurait pu rajouter que Rust est un langage natif et que en tant que tel il pourrait linker avec d’autre langage natif (mais je ne suis pas certain que ce soit déjà possible, le C certainement, le C++ j’en doute)
#28
#29
#30
#31
Merci pour toutes tes précisions. Je “regarderai” à l’occasion.
" />), je ne suis qu’un vieux schtroumpf de CC
Perso, hormis les L4G sous Windows (terriblement pratiques pour les applis de gestions communes mais à haute V.A.), moi c’est le C (‘aske j’le veaux bien).
“Niveau bas niveau” ouais c’est (trop) le top.
Par contre, je ne connais pas vraiment le CPP par manque de pratique, et je ne vois pas dans ton argumentaire en quoi il ne pourrait pas être adapté au dév. de bas niveau.
OK, dans l’affaire, c’est moi le “bas niveau” (
#32
+1
Je crois me souvenir que C# a au moins 15 ans (ou 20). A l’époque, il fallait des dizaines de lignes de code mal maîtrisées pour se connecter à une BDD, et je parle pas du SQL…
A la même époque, des L4G permettaient déjà de coder dans le dur en multi-plateforme et en client/serveur. OK, il ne s’agit pas de lourds calculs, ni de jeux, etc. mais de besoins de programmation qui répondaient à la demande du marché.
Maintenant, pour faire de la saisie prédictive temps réel dans un champ basée sur un big data, je dis pas :)
Pour les technos en entreprises, les DSI ont peur, surtout de l’open source en raison des problèmes de responsabilités en cas de ratage. Pas de support Microsoft contractuel Monsieur ? -> Au revoir. La hantise.
Pas chez Orange (même si ça merde) ? -> la hantise. Etc, etc.
Je ne connais personne qui met en jeu la vie de sa boite et de tous ses salariés (genre +100, +300…) sur de l’open source et des langages où on ne trouve personne. C’est malheureux mais c’est ce que je constate.
#33
Le support des normes C++ est plus rapide depuis VS2013, même si c’est encore en retard dérrière Clang et GCC pour le C++14, mais l’intégralité des améliorations principales sont là
#34
#35
Pas d’accord, je pense comme @HarmattanBlow que c’est déconnecté de la réalité, l’open source a fait ses preuves sur des gros projets. Dans les technos web même pas la peine d’en parler tellement c’est évident, l’open source est la règle, mais même dans des trucs c++ un peu plus bas niveau, des libs comme boost, thrust ou opencv sont largement utilisées (dans mon champ de compétences en tout cas). Je suis dans une grosse startup (15 personnes), heureusement qu’on utilise de l’open source. La garantie microsoft sur les produits, je ne suis pas sûr que ce soit vraiment un facteur de décision, à part peut être pour quelques vieux DSI restés en 1980
#36
#37
#38
#39
#40
As-tu regardé du coté de Cython? http://cython.org/
#41
#42
#43
#44
#45
Portant le projet arrive à de bonnes performances:
http://www.matthiaskauer.com/2014/02/a-speed-comparison-of-python-cython-and-c/
 http://nbviewer.ipython.org/github/rasbt/One-Python-benchmark-per-day/blob/maste…
#46
#47
#48
Bon je n’ai pas pu éditer à temps, donc mon edit :
Le modèle C++11 est plutôt bien foutu mais il y a encore quelques soucis à régler pour que le degré de confiance qu’on est sensé lui accorder soit effectivement celui qu’on a même en présence d’optimisations. En particulier, pour du code concurrent très bas niveau, où grosso modo la preuve devient plus facile et bien plus fiable que le test, on aimerait que lorsque l’on établit une preuve de correction en prenant en compte le modèle mémoire, le compilateur n’est pas susceptible de tout casser lors de la phase d’optimisation (à noter : Compcert TSO est sensé apporter ce genre de garanties pour C11, mais je ne sais pas où en est son développement).
#49
#50
#51