GCC 6.1 disponible : la norme C++14 utilisée par défaut

GCC 6.1 disponible : la norme C++14 utilisée par défaut

Attention aux migrations

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

28/04/2016 3 minutes
48

GCC 6.1 disponible : la norme C++14 utilisée par défaut

Après plus d’un an depuis GCC 5.0, la version 6.1 de la suite de compilation est disponible pour tous. Il s’agit d’une mouture particulièrement importante, notamment par son utilisation de la norme C++14 en lieu et place de C++98.

En dépit de son numéro de version, GCC 6.1 est bien la première vraie version de la branche 6.X pour les développeurs. Les améliorations sont particulièrement nombreuses et importantes. La principale est clairement l’utilisation par défaut de la norme C++14 pour la compilation. Jakub Jelinek (Red Hat) prévient d’ailleurs dans l’annonce qu’en fonction des projets, il faudra peut-être revoir une partie du code ou activer d’anciens modes de compilation. Parallèlement, le support expérimental de C++17 progresse.

OpenMP, OpenAAC et architectures

GCC 6.1 est également compatible avec les spécifications OpenMP 4.5 pour le parallélisme des calculs, ainsi qu’OpenAAC 2.0a pour les différentes méthodes d’accélérations de ces derniers, notamment en leur permettant d’être lancés sur des GPU NVIDIA. Idem pour la technologie HSA (Heterogeneous System Architecture).

Côté support des architectures, de nombreux points sont à souligner. GCC 6.1 supporte pleinement Zen chez AMD, Skylake chez Intel (avec les extensions AVX-512) et z13 chez IBM. Les architectures AR64 et Power sont également mieux exploitées. D’autres par contre, anciennes, seront supprimées dans de prochains versions. C’est notamment de toutes celles qui vont d’arm2 à strongarm1110.

Des optimisations renforcées

La nouvelle version de la suite de compilation comprend également une foule d’améliorations diverses, notamment dans tout ce qui touche aux optimisations automatiques du code, qui se veulent plus efficaces. Deux domaines sont particulièrement concernés : les optimisations inter-procédurales et celles du linker. Pour ce dernier, GCC 7 supportera d’ailleurs les optimisations incrémentielles.

Les diagnostics se veulent en outre beaucoup plus pratiques dans leurs résultats, avec des emplacements plus précis, des suggestions pour les éléments identifiants mal écrits, les noms d’options et ainsi de suite. GCC fournit en complément des suggestions sur les corrections à apporter. Enfin, de nouveaux avertissements ont été mis en place.

La récupération de GCC 6.1 pourra se faire depuis une liste de miroirs sur cette page. Ceux qui souhaitent consulter la (très) longue liste des modifications et améliorations pourront le faire sur le site officiel.

48

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

OpenMP, OpenAAC et architectures

Des optimisations renforcées

Commentaires (48)


Je m’en vais recompiler mon kernel avec mon gpu de suite <img data-src=" />




GCC 6.1 supporte pleinement Zen chez AMD



Ah ouai, ‘sont au taquet. Bien.








Ar-no a écrit :



Je m’en vais recompiler mon kernel avec mon gpu de suite <img data-src=" />





Tu l’as déjà fait <img data-src=" /> ? J’ai bien envie de tester ça avec ma gtx960 <img data-src=" />

Si tu peux me rediriger vers un bon tuto, je dis pas non <img data-src=" />



Je t’avoue que la seule chose que je recompile de temps à autre c’est FFMpeg…

D’ailleurs est-ce que le kernel implémente au moins openAAC ?








Ar-no a écrit :



Je m’en vais recompiler mon kernel avec mon gpu de suite <img data-src=" />





De ce que je comprend, ce n’est pas GCC qui utilise le GPU pour compiler, mais qu’il supporte OpenAAC 2.0a et donc permet de compiler afin que les programmes (ton kernel) puisse utiliser le GPU pour les processus parallèle. Et là encore, il faut que ton code possède les macro adéquates http://www.openacc.org/). Or je doute fort que ce soit le cas de ton noyau.



Ça permettrait du coup à GCC d’être compilé avec les openMP et openAAC pour paralléliser la compil sur GPU… Non ? <img data-src=" />


On passe de C++ 98 à C++14 en attendant C++ 17.

Ils font un random sur les numéros de version ?


C++ (19)98 à C++ (20)14, je pense.


Je suis un boulet, je ne trouve pas de quoi signaler l’erreur…



Ce n’est pas OpenAAC, mais OpenACC.








ldesnogu a écrit :



Je suis un boulet, je ne trouve pas de quoi signaler l’erreur…



Ce n’est pas OpenAAC, mais OpenACC.





Le point d’exclamation dans la petite barre du haut qui apparaît en scrollant la page vers le bas.

<img data-src=" />









t-la a écrit :



On passe de C++ 98 à C++14 en attendant C++ 17.

Ils font un random sur les numéros de version ?





Il n’y avait pas eu des versions supportant C++11 ?



de mémoire, la 4.8


Y aurai-t-il une synergie avec Vulkan? <img data-src=" />








RTDaemons a écrit :



Le point d’exclamation dans la petite barre du haut qui apparaît en scrollant la page vers le bas.

<img data-src=" />





Hum, j’aime le fouet&nbsp;<img data-src=" />



Message envoye, merci a toi !



Sans doute pas trop d’intérêt, la compilation c’est une tâche pleine de branches, pas spécialement adaptée aux GPU (SIMD : Same Instruction Multiple Data, autrement dit tout le monde fait la même chose ou presque).


Toutes depuis 4.8 effectivement il me semble, mais le support par défaut était resté à C++98 (il fallait passer le flag -std=c++11 pour activer). Je ne sais pas quoi en fait (<img data-src=" />), mais quelques cas doivent être gérés différemment par les deux standards, et l’idée était de garder la rétro-compatibilité.&nbsp;


C’est moins performant que le compilateur de Visual Studio je suppose ?


blague ? Vulkan c’est une API C, qui n’a pas grand chose à voir avec C++14 (dommage, ça la rendrait sans doute plus digeste). Des interfaces C++ existent, mais pas grand chose à voir avec GCC dans tous les cas.

&nbsp;Si c’est le support HSA qui te fait penser à ça, c’est pas trop pour le même but a priori : Vulkan est orienté graphismes et très bas niveau (vise à maximiser l’utilisation GPU pour du rendu), alors que le support HSA est plutôt pour le calcul (ou les tâches lourdes et parallélisables en général, mais pas que graphisme) et vise à remonter l’abstraction, à rendre l’utilisation conjointe CPU/GPU plus facile (par exemple en fusionnant les espaces mémoire CPU/GPU)


GCC supporte le C++1114 depuis longtemps, la différence est que maintenant il n’y a plus besoin de spécifier explicitement le standard (-std=c++14 est implicitement activé par défaut)&nbsp;<img data-src=" />



Du coup plus besoin de convaincre ton chef obsolète d’activer le C++11 pour profiter des nouveautés !&nbsp;<img data-src=" />


“Performant” pour un compilo, ça peut prendre pas mal de colorations différentes :




  • binaire plus ou moins rapide

  • binaire plus ou moins gros

  • compilation plus ou moins rapide

  • support des standards



    Le compilateur de Visual Studio (msvc) est super lent (plus que gcc, c’est dire… surtout qu’il ne connait pas ccache par exemple), les binaires de sortie sont à ma connaissance comparables à gcc, mais il est super en retard sur le support des standards (C++11 vient tout juste d’être supporté). Par contre Clang (llvm) met tout le monde d’accord sur la vitesse de compilation, de loin








brokensoul a écrit :



“Performant” pour un compilo, ça peut prendre pas mal de colorations différentes :




  • binaire plus ou moins rapide

  • binaire plus ou moins gros

  • compilation plus ou moins rapide

  • support des standards



    Le compilateur de Visual Studio (msvc) est super lent (plus que gcc, c’est dire… surtout qu’il ne connait pas ccache par exemple), les binaires de sortie sont à ma connaissance comparables à gcc, mais il est super en retard sur le support des standards (C++11 vient tout juste d’être supporté). Par contre Clang (llvm) met tout le monde d’accord sur la vitesse de compilation, de loin





    Bonjour,



    Je me suis toujours demandé, c’est quoi l’intérêt de compiler rapidement?

    Je pensais peut-être un peu naïvement que la vitesse de l’exécutable était le plus important



Quand ton travail c’est coder, attendre 10 à 30 min à chaque fois que tu fais une modif c’est chiant.



Quand il faut attendre plus de 2h pour que tous ton projet soit recompilé depuis 0 c’est long&nbsp; aussi.


ninja + ccache sur un ramdisk&nbsp;<img data-src=" />&nbsp;miam miam



@guy02 :

-&nbsp;Intérêt ci-dessus, c’est effectivement super casse-pieds quand tu codes.




  • Un autre intérêt, c’est pour de l’intégration continue, quand le code de tout le monde est compilé en permanence à chaque commit (envoi incrémental sur un serveur). Ça permet de détecter les erreurs plus tôt, mais dans ce cas un compilateur 30% plus rapide peut te sauver un serveur (exemple pratique dans ma boîte : je code sous linux, mais notre code doit être cross-platform, windows/mac/linux. Du coup mes commits sont testés à chaque envoi sur les autres plate-formes, et souvent ça casse, alors que c’était invisible sur ma machine (par exemple si j’utilise quelque chose qui n’est pas géré par le compilo microsoft). Les serveurs qui font ça se retrouve à faire des centaines ou milliers de compilations par jour, alors un compilo 50% plus rapide c’est pas mal..

  • Un dernier intérêt pour la compilation rapide, c’est qu’à un moment ça devient mieux de compiler puis d’exécuter plutôt que d’interprêter directement un truc moisi. On perd un peu au début, mais ensuite c’est tellement plus rapide que ça vaut le coup. C’est ce qui se passe sur le Web avec le JIT (Just-In-Time, compilation à la volée). Si la compilation prend trois plombes, ça ne marche pas



    Après chacun ses priorités, tu peux avoir des secteurs d’activités dans lesquels la vitesse du binaire est effectivement le plus important


On a déjà des ssd avec des 6 coeurs, ce qui prend du temps c’est le link qui lui est pas multi threadé








Tkop a écrit :



On a déjà des ssd avec des 6 coeurs, ce qui prend du temps c’est le link qui lui est pas multi threadé





gold est multi threade, il me semble.









brokensoul a écrit :



blague ? Vulkan c’est une API C, qui n’a pas grand chose à voir avec C++14 (dommage, ça la rendrait sans doute plus digeste). Des interfaces C++ existent, mais pas grand chose à voir avec GCC dans tous les cas.&nbsp;





&nbsp;Gcc ne fait pas que du C++, Il compile de nombreux langages dont le C (et Ada, Fortran, Go, …).

Mais c’est vrai qu’il n’y a pas de lien avec direct avec Vulkan pour autant.

&nbsp;





linconnu a écrit :



C’est moins performant que le compilateur de Visual Studio je suppose ?





C’est difficile de classer formellement un compilateur comme plus performant qu’un autre, il y a énormément de points qui rentrent en compte. C’est très facile sur de mini benchmarks de faire gagner tantôt l’un tantôt l’autre.

&nbsp;

Je pense qu’il est raisonnable de dire qu’au niveau des performances du code généré, les deux sont assez proches. Le meilleur dans ce domaine selon l’avis général semblant être le compilateur de Intel.









guy02 a écrit :



Bonjour,



Je me suis toujours demandé, c’est quoi l’intérêt de compiler rapidement?

Je pensais peut-être un peu naïvement que la vitesse de l’exécutable était le plus important





Voilà. Gros +1.

Aujourd’hui faut faire du code vite, très vite. OSEF que le soft soit pourri dans le fond et codé avec les pieds, tant qu’il est design et qu’il sort vite









brokensoul a écrit :



Sans doute pas trop d’intérêt, la compilation c’est une tâche pleine de branches, pas spécialement adaptée aux GPU (SIMD : Same Instruction Multiple Data, autrement dit tout le monde fait la même chose ou presque).









guy02 a écrit :



Bonjour,



Je me suis toujours demandé, c’est quoi l’intérêt de compiler rapidement?

Je pensais peut-être un peu naïvement que la vitesse de l’exécutable était le plus important







GCC permet entre autre différent niveau de compilation (option -O) :

-niveau 0 : compilation rapide qui conserve tout plein d’information utile pour le débugage (avec des outils comme gdb).

-niveau 2 et 3 : compilation avec un max d’optimisation, mais du coup, peu les outils de débugage sont un peu largué. Étrangement, même si le niveau 3 est théoriquement le meilleur, il arrive souvent que dans la pratique ce soit le niveau 2 (la taille de l’exécutable peut être plus important en niveau 3, obligeant de faire beaucoup de chargement en cache).







Uther a écrit :



Gcc ne fait pas que du C++, Il compile de nombreux langages dont le C (et Ada, Fortran, Go, …).

Mais c’est vrai qu’il n’y a pas de lien avec direct avec Vulkan pour autant.





C’est difficile de classer formellement un compilateur comme plus performant qu’un autre, il y a énormément de points qui rentrent en compte. C’est très facile sur de mini benchmarks de faire gagner tantôt l’un tantôt l’autre.



Je pense qu’il est raisonnable de dire qu’au niveau des performances du code généré, les deux sont assez proches. Le meilleur dans ce domaine selon l’avis général semblant être le compilateur de Intel.







Pour le compilo Intel, j’avais vu effectivement un bench il y a de ça quelques années, des mecs qui avait fait un énorme protocole de test, avec différent compilo, différent optimisation,différent processeur, et c’était a priori optimisé surtout pour les processeurs Intel.









Tkop a écrit :



On a déjà des ssd avec des 6 coeurs, ce qui prend du temps c’est le link qui lui est pas multi threadé





Moi qui était content quand on m’a changé de PC pour un I5 avec 4Go de ram et un OS 64bits…&nbsp;<img data-src=" />



&nbsp;



Non, ça fait un moment que O3 produit du code strictement plus rapide que O2 :

http://www.phoronix.com/scan.php?page=news_item&px=GCC-5.3-New-Opt-Tests



&nbsp;


Rapport avec la choucroute ? On parle de compiler rapidement, pas de coder rapidement.



Compiler rapidement, ça permet d’avoir plus de temps pour tester (la présence de bugs, et l’impact des optimisations qu’on produit nous même par exemple), ce qui permet justement de s’assurer que le code est pas développé avec les pieds … Qu’il contient un minimum de bug, qu’il a des performances convenables, etc. Parce qu’on produit pas un code parfait du premier coup.



Pas&nbsp; mal de boîtes optimisent le time-to-market et s’en foutent de produire du soft moisi, mais ça n’a absolument rien à voir avec le besoin d’un compilateur qui produit rapidement des binaires.


Les tests sont fait à priori sur un Xeon qui possède une grosse quantité de cache et est donc moins sensible aux défauts de cache.

Le problème du niveau 3, c’est qu’il a tendance à réduire les appels de fonction et tout ce que est instructions de saut dans le code en en “inlinant” les fonctions (ça permet par exemple de ne pas se taper la mise sur la pile des paramêtres ni d’aller chercher à l’autre bout du code) ou en déroulant les boucles.

Mais du coup, en faisant ça, tu as un exécutable plus gros. Et là, c’est très dépendant des codes et des processeurs mais on peut avoir d’énorme problème de défauts de cache.








Arcy a écrit :



C++ (19)98 à C++ (20)14, je pense.







On va être dans la merde en 2098 <img data-src=" />









Drepanocytose a écrit :



Voilà. Gros +1.

Aujourd’hui faut faire du code vite, très vite. OSEF que le soft soit pourri dans le fond et codé avec les pieds, tant qu’il est design et qu’il sort vite





Bah non, justement. Au plus le compilo est rapide, au plus il y a de chances que le développeur passe du temps à écrire du code correct au lieu de jouer au solitaire en attendant que son binaire arrive. Des cycles de compilation courts favorisent les micro-améliorations incrémentales, les tests automatisés, etc…



Perso quand j’ai commencé à programmer il fallait soumettre la compilation en batch et attendre 15 minutes dans la file (j’ai eu de la chance, l’année d’avant c’était encore des cartes perforées) et honnêtement ça ne me manque pas.&nbsp;<img data-src=" />



Je plussoie avec vigueur ! Non, faire poiroter un programmeur n’augmentera pas la qualité de son travail, au contraire. Et je pense qu’on peut remplacer “programmeur” par n’importe quel métier dans cette phrase.








33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



Bah non, justement. Au plus le compilo est rapide, au plus il y a de chances que le développeur passe du temps à écrire du code correct au lieu de jouer au solitaire en attendant que son binaire arrive. Des cycles de compilation courts favorisent les micro-améliorations incrémentales, les tests automatisés, etc…

:





Favorisent, tout est dit <img data-src=" />

Pas dit que le dev passe quand même du temps à chiader son code ; ca lui facilite de le faire, mais pas sûr qu’il le fasse.

Ils y a les bons devs et les mauvais devs, c’est comme les chasseurs <img data-src=" />



Plutôt que d’attendre 1/2h pour tester une simple modif, il vaut mieux créer un test unitaire en isolant une partie du code quand c’est possible.

Mais la rapidité de compilation reste très importante pour la productivité.



Ils ont quand même mis un coup d’accélérateur appréciable sur l’avancement de la norme et son intégration dans les outils. Heureusement pour ce langage qui commençait à dépérir face à des concurrents de mieux en mieux armés face aux avantages du C++.








Drepanocytose a écrit :



Pas dit que le dev passe quand même du temps à chiader son code ; ca lui facilite de le faire, mais pas sûr qu’il le fasse.

Ils y a les bons devs et les mauvais devs, c’est comme les chasseurs <img data-src=" />





Certes, mais c’est surtout la contraposée qui s’applique : un bon programmeur face à un compilo qui met des plombes en aura vite marre de perdre son temps <img data-src=" />&nbsp;et fera ses modifs à la pelle à neige plutôt qu’au scalpel micrométrique.





OpenMP, OpenAAC et architectures





Perso, je préfère compiler mes vidéos en OpenDTS ou OpenAC3 .



<img data-src=" />








ActionFighter a écrit :



Plutôt que d’attendre 1/2h pour tester une simple modif, il vaut mieux créer un test unitaire en isolant une partie du code quand c’est possible.

Mais la rapidité de compilation reste très importante pour la productivité.



Ils ont quand même mis un coup d’accélérateur appréciable sur l’avancement de la norme et son intégration dans les outils. Heureusement pour ce langage qui commençait à dépérir face à des concurrents de mieux en mieux armés face aux avantages du C++.





Quand tu parles de créer des tests unitaires, ç’est dans le cas ou tu as plusieurs exécutables, et tu les teste séparément, c’est ça?

&nbsp;

Et sinon, pusique tu as l’air de t’y connaitre, c’est quoi les gros avantages du c++ 14 par rapport au 11? Je connais pas trop les dernières évolutions…









guy02 a écrit :



Quand tu parles de créer des tests unitaires, ç’est dans le cas ou tu as plusieurs exécutables, et tu les teste séparément, c’est ça?





Je veux dire par là isoler le code que tu veux tester dans un projet séparé, avec un binaire séparé.

 





guy02 a écrit :



Et sinon, pusique tu as l’air de t’y connaitre, c’est quoi les gros avantages du c++ 14 par rapport au 11? Je connais pas trop les dernières évolutions…





Ça fait un bail que j’ai pas fait de c++, et j’ai pas encore prêté attention aux nouveautés de c++14.









33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



Certes, mais c’est surtout la contraposée qui s’applique : un bon programmeur face à un compilo qui met des plombes en aura vite marre de perdre son temps <img data-src=" />&nbsp;et fera ses modifs à la pelle à neige plutôt qu’au scalpel micrométrique.







Ouis mais est-ce qu’il n’y a pas parfois des choix antinomiques entre la vitesse de compilation et la vitesse d’exécution?

&nbsp; par exemple si tu peux choisir entre une classe template et un héritage. D’après ce que j’ai pu lire, l’utilisation d’une classe template alongera la durée de compilation, mais le code sera plus rapide à l’exécution









doom_Oo7 a écrit :



Non, ça fait un moment que O3 produit du code strictement plus rapide que O2 :

http://www.phoronix.com/scan.php?page=news_item&px=GCC-5.3-New-Opt-Tests





J’ai plusieurs procédures (chiffrement de données) pour lesquelles le code le plus rapide est produit avec -O1 (GCC 5.3.0). Et ça dépend aussi de l’architecture (x86 ou x64).









guy02 a écrit :



Ouis mais est-ce qu’il n’y a pas parfois des choix antinomiques entre la vitesse de compilation et la vitesse d’exécution?

  par exemple si tu peux choisir entre une classe template et un héritage. D’après ce que j’ai pu lire, l’utilisation d’une classe template alongera la durée de compilation, mais le code sera plus rapide à l’exécution





Pour ma part, le choix template vs héritage tient plus dans le design recherché avec les différentes possibilités (connaissance du type à l’exécution), et de la maintenabilité (templater à tout-va peut rendre le code totalement illisible) que des perfs.









guy02 a écrit :



&nbsp;Et sinon, pusique tu as l’air de t’y connaitre, c’est quoi les gros avantages du c++ 14 par rapport au 11? Je connais pas trop les dernières évolutions…





Par rapport au 11, très peu finalement, il y a certaines literalles qui ne sont plus dans experimental, les variables templates, les lambdas génériques, relâchement de certaines contraintes pour les fonctions constexpr, deduction de type pour le retour de fonction, et la correction d’un oubli pour unique_ptr. Après, c’est&nbsp; très mineur. Le vrai gap c’était C++11, C++14 facilite des petits bouts qui étaient foireux.



Le véritable apport sur GCC6.1 c’est le passage du support par défaut de C++98 à C++14, mais ça n’a pas d’impact pour les gens qui utilisent déjà cette norme depuis un bail (et qui mettait simplement qu’ils utilisaient C++14 dans leurs options de compilation).



A la question template VS héritage, c’est surtout sémantique. Dans un cas il faut s’efforcer de respecter le LSP, dans l’autre pas nécessairement.