La sortie de la version 4.6 du compilateur GCC a été annoncée ce vendredi 25 mars sur la liste de diffusion du projet.
Écrit à l’origine par [Richard Stallman] en tant que compilateur C officiel du projet GNU, dont il est le fondateur, [GCC] est aujourd’hui le compilateur multi-langage de référence du monde du logiciel libre. Il accepte du code source écrit en Ada, C, C++, Objective-C, Objective-C++, D, Fortran, Go, Java, Pascal et VHDL, et fonctionne sur une multitude d’architectures.
Sommaire
Les nouveautés de la version 4.6
Un nouveau niveau d’optimisation fait son apparition aux côtés des traditionnels
« -Os »,« -O1 »,« -O2 »et« -O3 ». La nouvelle option« -Ofast »permet d’activer toutes les optimisations du niveau« -O3 »et d’ajouter en plus des options spécifiques, comme« -ffast-math », qui peuvent ne pas se conformer strictement aux standards. Si votre code n’a pas besoin de respecter religieusement la norme IEEE sur les opérations à virgule flottante, alors le niveau d’optimisation« -Ofast »est à considérer sérieusement.Si vous avez reniflé de mépris en lisant le texte de la nouveauté précédente, parce que votre code exige la plus exquise précision de calcul possible, sachez que les développeurs de GCC 4.6 ont entendu votre appel. En effet, la bibliothèque LGPL libquadmath a été intégrée à cette version du compilateur libre, et elle permet de calculer avec une précision de 128 bits. Le type
« __float128 »est maintenant accessible sur les architectures x86, x86-64 et Itanium, via le compilateur GNU Fortran. Bien entendu, un tel calcul en quad‑precision est beaucoup plus lent, puisqu’il repose sur une bibliothèque logicielle et ne s’appuie pas sur une correspondance avec les registres du processeur sous‑jacent.Le support du langage de programmation Go, développé par Google, a été accepté par le comité technique de GCC. Il est donc maintenant possible, si GCC a été lui‑même compilé avec l’option
« --enable-languages=go »configurée, d’utiliser le frontal gccgo pour compiler votre source et l’envoyer vers le back‑end commun de GCC.
Nul doute que cette intégration va permettre d’augmenter la popularité de ce langage moderne et innovant.Comme d’habitude, GCC améliore son support des nouvelles générations de langage de programmation. Un gros travail a été effectué sur Objective-C et son nouveau standard 2.0 qui est maintenant supporté. Du côté de FORTRAN, la norme 2003 est étendue et le travail sur la version 2008 continue, avec notamment, Coarray FORTRAN qui permet de faciliter la programmation parallèle. En ce qui concerne la future norme C++0x (ne devrait-elle pas s’appeler « C++1x » maintenant ?) le tableau récapitulatif permet de se faire une idée des progrès réalisés. Enfin, le vénérable langage C n’est pas oublié, puisque le travail a déjà commencé sur le successeur de C99 ; GCC 4.6 apporte, grâce à l’option
« -std=c1x », les tout premiers éléments du futur C1X.On se souvient que la précédente version de GCC avait apporté la technique LTO (pour Link Time Optimization) qui permet des passes d’optimisations supplémentaires lors de l’édition des liens. Par défaut, dans la version 4.6, c’est maintenant l’architecture WHOPR (WHOle Program Optimise*R*) qui est utilisée. Le graphe des appels de fonctions est d’abord analysé, puis partitionné pour pouvoir être distribué entre les différents processeurs. Ce partage entre les cœurs de calcul se fait grâce à l’option
« -flto=n », n étant le nombre de compilations en parallèle à exécuter lors de l’édition des liens.En plus de l’architecture WHOPR par défaut, c’est toute la fonction de Link Time Optimization qui a été largement optimisée dans GCC 4.6. De nombreux bogues ont été corrigés, et il est maintenant possible de compiler de très gros projets avec l’option
« -lto », par exemple, GCC lui-même, ou encore Mozilla Firefox (voir les échanges sur cette entrée Bugzilla et le fichier PDF du sommet GCC). Les passes d’optimisations sont plus agressives et l’occupation mémoire est réduite. L’« inlining » de fonction (c-à‑d le remplacement d’un appel de fonction par une copie de son corps) a été amélioré, ce qui peut réduire significativement le temps de démarrage des grosses applications en C++. Enfin, le temps de compilation a été amélioré et des gains de 10 % environ sont enregistrés sur architecture x86‑64.La bibliothèque Bionic écrite par Google est une alternative légère, sous licence BSD, de la glibc. Le compilateur GCC 4.6 supporte maintenant Bionic et l’option «
-mandroid» permet de compiler du code compatible avec la plate-forme Android. Attention, toutefois, car cette option n’est actuellement utilisable que pour l’architecture ARM.Sur les architectures x86 et x86-64, une nouvelle option «
-fsplit-stack» permet d’utiliser une pile discontinue. Avant cette option, il était nécessaire, pour les programmes multithread, de penser à l’avance à la taille maximum que la pile pouvait atteindre. En utilisant« -fsplit-stack », la pile s’agrandira ou diminuera automatiquement en fonction des besoins réels de l’application, et non plus en fonction du pire des cas envisagé par le développeur. Cela permet d’économiser beaucoup de mémoire sur les programmes multithread. La documentation évoque même la possibilité de lancer des millions de threads NPTL depuis une machine 32 bits.Les fonctions d’« inlining », c’est‑à‑dire la technique d’optimisation du code qui remplace l’appel d’une fonction par le code de la fonction lui‑même, ont été améliorées dans cette version du compilateur GCC. On trouve, par exemple, la nouvelle option
« -fpartial-inlining »qui permet de découper une fonction en deux chemins (hot path et cold path) et d’« inliner » uniquement le hot path. Cet inlining partiel augmente les performances et réduit également l’occupation mémoire (pas de duplication du cold path dans le code).Une nouvelle passe d’optimisation, nommée
« -fipa-profile », a été ajoutée au vaste répertoire de GCC 4.6. Cette passe permet de marquer en « COLD » les fonctions qui sont appelées très rarement ou qui sont appelées seulement une fois (ayant, par exemple, l’attribut « noreturn »). Une fois ce marquage effectué, le compilateur prendra soin d’optimiser ces fonctions pour la taille(« -Os »), au lieu de les optimiser pour la vitesse(« -O3 »).Deux autres passes d’optimisation intéressantes concernant les boucles de code sont intégrées dans cette version de GCC. L’option
« -ftree-loop-if-convert »tente de transformer les sauts conditionnels qui se trouvent à l’intérieur de la boucle, pour éviter d’avoir à choisir entre plusieurs branches. Si l’on sort ce code de la boucle, on facilite la vectorisation et c’est ce qui explique pourquoi cette passe d’optimisation est activée si vous choisissez l’option de vectorisation automatique. La seconde passe se nomme« -ftree-loop-distribute-patterns »et s’occupe d’extraire les parties de la boucle qui peuvent être remplacées par des appels de fonctions.GCC 4.6 permet maintenant d’optimiser spécifiquement le code pour les nouvelles générations de processeurs x86. L’option
« -march=corei7 »optimise pour les processeurs de type Core i3 / i5 / i7, tandis que l’option« -march=corei7-avx »ajoute le support de l’unité vectorielle 256 bits AVX. En ce qui concerne AMD, c’est la puce « Bobcat » qui est maintenant supportée via« -march=btver1 ».Du côté des processeurs ARM, très à la mode en ce moment, on trouve des améliorations de la génération du code vectoriel NEON, la réécriture de l’infrastructure de génération de code pour les instructions
« load »et« store », ou encore le support amélioré des unités flottantes des puces Cortex-A9. Cette extension « vers le haut » des gammes de processeurs ARM se manifeste aussi par le support préliminaire du puissant Cortex-A15.En ce qui concerne les processeurs un peu plus exotiques, on trouve les optimisations pour la dernière génération des représentants de l’architecture MIPS Loongson (
« -march=loongson3a »), ou encore le support du z196 (« -march=z196 »), le tout dernier processeur mainframe d’IBM.
Enfin, si l’on s’interroge sur le futur de GCC, on peut se tourner vers les nombreux articles techniques publiés à l’occasion du sommet GCC 2010 d’Ottawa, qui s’est déroulé en octobre dernier (Summit2010.pdf).
Un autre point important à considérer est la décision du comité technique de GCC d’autoriser l’usage du langage C++ dans le code de GCC, alors que jusqu’à présent, seul le C était utilisé. L’usage de l’outil sémantique Coccinelle a également été évoqué pour faciliter les modifications et les restructurations du code, afin d’intégrer le C++. Ces décisions vont, bien entendu, changer beaucoup de choses dans les futures versions de GCC, même s’il est encore un peu tôt pour en évaluer l’impact. Est‑ce que le développement va s’accélerer ? Est‑ce que des nouveaux contributeurs vont se manifester ? Est‑ce que Linus Torvalds va avoir une attaque ?
Une page spéciale C++ a été créée pour centraliser les informations, et il est bien indiqué que seule une sous‑partie du langage sera autorisée, avec des conventions de codage strictes, pour éviter d’introduire des fonctions controversées (alias « idiotic crap », en langage « torvaldien »).
Aller plus loin
- Les nouveautés de GCC 4.6 (718 clics)
- La fonction Split Stacks de GCC 4.6 (221 clics)
- LinuxFr : Sortie de GCC 4.5 (176 clics)
# Merci
Posté par gasche . Évalué à 6.
Comme d'habitude, merci patrick_g pour cette excellente dépêche. Avant sa sortie, j'ai lu les "change notes" officielles, mais il est beaucoup plus difficile d'en distinguer les changements importants.
[^] # Re: Merci
Posté par ElectronLibre . Évalué à -8.
Merci !
Maintenant je sais ce que je vais faire ce soir : lire
Bonne lecture !
[^] # Re: Merci
Posté par i M@N (site web personnel) . Évalué à -9.
Merci patrick_g!
/me patrick_g fan forever!!
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: Merci
Posté par MarbolanGos (site web personnel) . Évalué à -1.
Oui clairement merci pour une nouvelle si facilement lisible et bien détaillée. Super agréable à lire.
Et surtout : plus accessible que le kernel corner.
# quand est-il du support d'AVX pour les futurs CPU AMD (architecture Bulldozer particulièrement) ?
Posté par mum1989 . Évalué à 0.
tout est dans le titre
Bobat c'est plutôt du réchauffé niveau CPU (archi K10 en gros).
[^] # Bobcat != K10
Posté par Antoine . Évalué à 4.
Non, rien à voir, c'est une architecture beaucoup plus légère dédiée aux netbooks et PC peu puissants.
cf. http://www.hardware.fr/articles/819-2/amd-e-350-fusion-solutions-mini-itx.html
[^] # Qu'en est-il...
Posté par windu.2b . Évalué à 8.
Tout est dans le titre.
[^] # Re: Qu'en est-il...
Posté par Maclag . Évalué à 3.
Il est 12h44 au moment où j'écris.
Mais avec le décalage horaire et le fait que l'horloge de mon PC n'est peut-être pas à l'heure, sans compter que je vais mettre plus d'une minute à taper ce message, tu peux considérer que c'est 12h44 à une constante temporelle près.
Bonne après-midi!
# Un dernier petit pas pour C++0x
Posté par small_duck (site web personnel) . Évalué à 4.
La plupart du boulot autour de C++0x a été fait dans g++4.4 et g++4.5, la principale nouveauté dans g++4.6 étant le "range based for", qui va permettre enfin de mettre en retraite forcée le bon vieux BOOST_FOREACH.
Les autres ajouts, nullptr, constexpr, et quelques trucs sur les unions, sont moins enthousiasmants, mais c'est toujours ça de pris. Il ne manque plus grand chose, maintenant (non, par pitié, pas le GC!).
J'attends aussi beaucoup de bonnes choses du WHOPR, en espérant cependant que le temps passé à faire l'édition de liens n'explose pas.
[^] # Re: Un dernier petit pas pour C++0x
Posté par gasche . Évalué à 7.
En parlant du temps d'édition des liens, le linker Gold semble maintenant être un citoyen à part entière de l'écosystème GCC; il est mentionné à plusieurs reprises dans les changelogs.
[^] # Re: Un dernier petit pas pour C++0x
Posté par nazcafan . Évalué à 7.
Personnellement, j'attends beaucoup de la délégation et de l'héritage de constructeurs. L'impossibilité de faire des template typedef se fait sentir également dans la vie de tous les jours.
Visiblement, ils sont pas mal à la bourre sur la partie multithreading de C++0x, mais ça a l'air également valable chez visual et ICC (et clang…).
Sinon, d'après Herb Sutter, C++0x est en état pour passer le vote ISO, ils penchent pour une publication du standard cet été:
[^] # Re: Un dernier petit pas pour C++0x
Posté par GeneralZod . Évalué à 1.
C'est principalement du au fait que l'implémentation de constexpr n'était pas finalisée jusqu'à présent, donc maintenant ça devrait aller vite côté GCC vu que le gros du boulot dans libstdc++ a été fait (merci Boost ;) ). Pour CLang and libc++, c'était le même problème.
[^] # Re: Un dernier petit pas pour C++0x
Posté par ecyrbe . Évalué à 3.
Je ne vois pas le rapport entre constexpr et le multi-threading. Quand on parle de la partie multi-threading de c++ on ne parle pas seulement de std::thread mais aussi des operations atomiques ajoutées au standard ainsi que les nouvelles définitions du modèle mémoire qui prennent enfin en compte le multi-threading pour expliquer comment doit marcher un programme c++.
Car pour le moment, le multi-threading, ça tombe en marche plus qu'autre chose car rien n'est définit dans c+03 pour expliquer comment doit se comporter un programme c++ face à des accès mémoires concurrents.
[^] # Re: Un dernier petit pas pour C++0x
Posté par lasher . Évalué à 2.
Oui alors justement, « grâce » à ce magnifique modèle mémoire, en cas d'accès concurrent à une adresse mémoire, n'importe quoi peut arriver (même initier une connexion TCP pour commander 90 chameaux pour demain via UPS). Je comprends très bien pourquoi ils font ça, mais c'est (je trouve) extrêmement dangereux et surtout chiant pour debugger...
[^] # Re: Un dernier petit pas pour C++0x
Posté par auve . Évalué à 1.
Parce que le hardware est comme ça, et que spécifier la sémantique d'un programme contenant des data-races de façon portable et sans inhiber les optimisations faisables par le compilateur est quasiment impossible à l'heure actuelle ?
http://rsim.cs.illinois.edu/Pubs/10-cacm-memory-models.pdf
[^] # Re: Un dernier petit pas pour C++0x
Posté par lasher . Évalué à 3.
Non justement, le hardware n'est pas comme ça. Il obéit à tout un tas de règles (sequential consistency, ou release consistency, ou total store order, ou partial store order, etc). Je connais bien l'article que tu références. En fait, j'ai lu presque tous les articles de S.Adve concernant les modèles mémoire. Ceux de Boehm en grande partie. Et Pugh.
C'est pour ça que je disais que je comprenais les raisons de Adve & Boehm, mais ça reste dangereux selon moi.
[^] # Re: Un dernier petit pas pour C++0x
Posté par GeneralZod . Évalué à 1.
two words: data-safety, c'est utilisé dans l'implémentation des mécanismes de synchronisation entre autre et c'est ce qui retarde la plupart des implémenteurs de compilo en ce domaine.
[^] # Re: Un dernier petit pas pour C++0x
Posté par ecyrbe . Évalué à 3.
Deux mots anglais, c'est sensé impressionner? constexpr est un mécanisme utilisé pour généraliser le système des expressions évaluable à la compilation. C'est un mécanisme type-safe (d'ou ton data-safety?).
Cependant, il n'a rien à voir avec l'implémentation multi-threading du standard si ce n'est dans la librairie ou de nouvelles méthodes constexpr ont été définies. Pour les mécanisme du compilateur, (modèle mémoire etc...), je ne vois toujours pas le rapport.
Je pense que tu raconte n'importe quoi, je n'ai vu nulle part de problèmes d'implémentation du multi-threading dus à constexpr chez les développeurs de gcc.
[^] # Re: Un dernier petit pas pour C++0x
Posté par GeneralZod . Évalué à 1.
Soit tu n'as pas du tout compris la sémantique de constexpr, soit effectivement, je raconte n'importe quoi ...
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2976.html (document de travail qui explique l'intérêt en général de constexpr dans la bibliothèque standard)
La norme C++2011 garantit qu'un constructeur déclaré avec constexpr et qui satisfait les conditions requires est initialisé statiquement (donc 100% thread-safe, aucun risque de data races, d'où le data-safety). Par exemple, la norme impose que le constructeur par défaut de std::mutex soit déclaré constexpr (pour rester avec les mutex, ça revient plus ou moins à ce que fait la macro PTHREAD_MUTEX_INITIALIZER dans la bibliothèque Posix Threads).
# c'est illisible
Posté par Gabin . Évalué à -8.
La dépêche est assez indigeste, les paragraphes ne sont pas suffisamment délimités et aérés.
En plus, du fait du sujet, ça fourmille de nom propres, de caractères spéciaux, de changement de typo...
J'ai beau changer les tailles ou la police, j'ai du mal à suivre.
Sans doute que la précédente dépêche sur le noyau nous a épuisé mister patrick_g... :)
C'est bien dommage, car celle-ci est tout aussi importante que le noyau...
[^] # Re: c'est illisible
Posté par JGO . Évalué à 9.
Problème de CSS ? Le format de la dépêche et très bien pour moi...
Personnellement je trouve que le format de ton commentaire est peu lisible. Trois lignes courtes séparées par un retour de chariot, qui chez moi vont à la ligne au mauvais endroit (juste après la fin de ligne), suivies de deux lignes tout aussi courtes, séparées de deux blancs sans qu'on sache pourquoi. Ton texte fait de la dentelle à droite au lieu d'être justifié, les yeux doivent prématurément revenir à la ligne plusieurs fois. En plus je trouve trois utilisations des points de suspension, qui cassent le rythme de lecture.
[^] # Re: c'est illisible: çamarchechezmoi
Posté par Gabin . Évalué à -10.
J'utilise la CSS par défaut et merci, ma lecture de l'excellente dépêche sur le noyau se fait sans soucis celle-là et pourtant, elle est tout aussi dense.
Sinon, Patrick_G est-il parfait? Parole d'évangile pour qu'on ne puisse dire, de temps en temps "oh, tiens, cette fois-ci, c'est moins bon."?
Donc en gros, on doit faire du gros léchage de fion, comme il est coutume dans les 10 premiers commentaires d'un journal Patrick_Gien?
Pour rappelle, je ne dénigrais rien, la forme est tout simplement chargée visuellement et ce avec la CSS par défaut de LinuxFr et j'ai pas envie de m'amuser à en changer, ça se passe très bien sur les autres sites que je consulte et surtout, je n'ai pas de problème sur les autres articles/journaux du site.
Bref, il était bon vot' susucre?
[^] # Re: c'est illisible: çamarchechezmoi
Posté par JGO . Évalué à 6.
Je te remercie de m'épargner tes grossièretés à mon égard et à l'égard des contributeurs du site.
Tu critiques la forme de la dépêche, tu as le droit. Je critique la forme de ton commentaire, j'ai aussi le droit.
[^] # Re: c'est illisible: çamarchechezmoi
Posté par Guillaume Denry (site web personnel) . Évalué à 7.
Non seulement c'est grossier mais en plus la critique elle-même est très conne ; la dépêche est une liste détaillé de nouveautés distinctement écrites chacune dans un format relativement court, c'est l'anti-pavé par excellence.
# ...
Posté par M . Évalué à 7.
C'est plus exactement un portage de la libc de openbsd sous linux. Google n'ont pas tout récrit. Au passage ça vaut mieux, vu le nombre de bugs subtiles qui ont été trouvé dans leur implémentation des threads ...
Linux étant lasy (COW), la stack est réellement alloué qu'a l'utilisation et chaque thread peut alloué 8MB sans consommer de la RAM physique.
Du coup le seul avantage que je vois c'est pour les système qui ont un espace d’adressage limité (32 bits). Et quand je lit ce que cette option coûte (chaque fonction doit vérifier s'il faut allouer une nouvelle pile), je vois pas l’intérêt du truc.
Serait il possible d'avoir des exemples concrets des avantages de toutes ces nouvelles options ?
PS : Une nouvelle version de llvm devrait sortir dans quelques jours
[^] # Re: ...
Posté par neologix . Évalué à 4.
1) Tout le monde n'utilise pas l'overcommiting : dans ce cas, l'OOM killer va se déclencher au moment de la création des threads, et pas de leur utilisation de la stack, même s'il reste encore plein de mémoire physique disponible. Si tu utilises par exemple un pool de threads fixe, c'est une grosse limitation.
2) Le risque de stack overflow est moindre, puisque la stack est augmentée à la demande.
3) Même avec l'overcommiting, avoir un mémoire virtuelle importante (Committed_AS) a un impact sur les performances : le "page reclaiming code" (j'ai horreur du franglais, mais c'est plus clair) prend en compte la quantité de pages mappées pour savoir s'il doit swapper des process (swap_tendency prend en compte les valeurs mapped ratio et swappinnes). Donc rien qu'avoir un bazillion de threads qui ne font rien va augmenter la tendance du noyau à diminuer le page cache ou swapper.
[^] # Re: ...
Posté par M . Évalué à 3.
1) dans quel cas la non utilisation de l'overcommit et split-stack serait utile ?
Un des usages de ne pas utiliser l'overcommit, c'est de ne pas avoir de OOM killer (non l'OOM killer ne se déclenche pas a la création des threads, mais on a une belle erreur du pthread_create suite au mmap de la stack qui échoue) mais un comportement ou l'on peut catcher les erreurs.
Dans ce cas l'utilisation des split-stack est débile : on introduit un comportement non prédictible (si la taille de la stack doit etre augmenté et qu'il n'y a plus de memoire, que fait on ?).
De plus la non utilisation de l'overcommit est pas évidente. Tu connais des exemples de système qui l'utilise ?
2)
dans le cas classique on a la stack plus une page de garde pour catcher les débordement de pile. Avec ce système il faudra rajouter du code qui gère tout les cas de débordement de pile (allocation statique par le compilo, tableau sur la pile de taille variable, alloca, ...).
3)
J'ai pas tout suivi. Si tu alloue des pages, mais que tu n'utilises pas encore, ca influence les algo de swapping de linux ?
Pourquoi ne pas améliorer ces algos dans ce cas. Les stacks ne sont pas le seul cas de ce cas d'usage.
En plus l'utilisation en contexte embarqué des split-stack est peu recommandable pour les tâches RT. Dans le cas classique on peut pre-faulter la stack, ici on aura des mmap automatique en cours de vie du programme.
[^] # Re: ...
Posté par neologix . Évalué à 2.
1) oui bien sûr sans overcommit mmap ou malloc va retourner une erreur (enfin dans la majorité des cas). L'intérêt de split-stack sans overcommit c'est que tu pourras créer plus de threads, et gâcher moins de mémoire. Je suis d'accord que le comportement n'est pas déterministe, mais je ne pense pas que les cas ciblés soient le temps-réel ou les systèmes embarqués.
Il y a plein de cas où l'overcommitting est désactivé : par exemple tu évoques les problèmes de déterminisme, or l'OOM est hautement imprévisible. Sinon, il est souvent conseillé de le désactiver avec certaines bases de données, http://www.network-theory.co.uk/docs/postgresql/vol3/LinuxMemoryOvercommit.html. Enfin, il y a plein de systèmes qui ne supportent pas l'overcommitting (gcc ne compile pas que du code destiné à tourner sous Linux avec un MMU).
2) tout à fait d'accord, mais la probabilité d'occurrence de débordement de pile est plus faible
3) je me suis posé la même question. Il faudra que je vérifie le code, mais j'ai bien l'impression que c'est le nombre de pages mappées qui est pris en compte dans la politique de pagination. A creuse.
Tu as l'air d'avoir une approche systèmes embarqués temps-réel, mais je ne suis pas sûr que splitstacks s'adresse à ce type de cas.
[^] # Re: ...
Posté par neologix . Évalué à 2.
OK, pour le point 3, je me suis trompé, c'est bien le nombre de pages physiques mappées (par zone), pas committées, donc cela n'a pas d'influence.
# option -Ofast
Posté par errno . Évalué à 4.
J'aimerai bien avoir quelque précision sur l'option -Ofast, qui semble activer -O3 et -ffast-math.
L'option -ffast-math ne respecte pas les standard IEEE pour les floating points, mais de ce que j'ai pu lire ici: http://gcc.gnu.org/ml/gcc/2001-07/msg02150.html , il ne s'agit que des ajustements suivants :
plus de gestion des valeurs dénormalisées
plus de zero negatif
autres ? ...
Est ce que je me trompe en disant que si le code ne génère pas de valeur dénormalisée, et ne se soucie pas des zéros négatifs, cette option va optimiser sans changer la précision ?
En gros quel est exactement l'impact de cette optimisation sur la précision des FP ?
p.s: très bonne dépêche de patrick_g, comme toujours.
[^] # Re: option -Ofast
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est le problème de ce genre d'optim : tu ne sais pas ce que tu perds sans faire d'essais.
"La première sécurité est la liberté"
[^] # Re: option -Ofast
Posté par Shuba . Évalué à 5.
L'option -ffsat-math va vraiment enlever pleins de règle de calcul en flottant:
Et d'autres que je ne connais pas. C'est une option qui est souvent mise quand on fait des calculs graphiques je crois. Par exemple, OpenGL précise qu'il ne doit jamais y avoir de crash en cas d'erreur de calcul en flottant, mais que le résultat affiché a le droit d'être faux auquel cas.
[^] # Re: option -Ofast
Posté par Kerro . Évalué à 3.
Question performances, ça change beaucoup ?
Parce que si c'est pour gagner 2%, les inconvénients sont un peu raide.
[^] # Re: option -Ofast
Posté par Shuba . Évalué à 3.
Testé sur mon raytrcer joujou (donc avec pleins de cacluls en flottant, pour lesquels on n'a pas besoin de respecter les normes IEEE):
Donc effectivement, pas mieux que du 2%, mais y a pas vraiment d'inconvénient en l'occurence, donc c'est toujours ça de pris (surtout que vu la lenteur de mon raytracer en l'état, pour des vrais rendus 2% ça peut me faire gagner beaucoup de temps. Et c'est même vrai pour les raytracers utilisés professionellement : quand ton film prend plusieurs jours à rendre, 2% de perfs c'est plusieurs heures de temps d'artiste passées à peaufiner des détails).
Et pour OpenGL, je crois bien que c'est plutôt un avantage je crois : on a pas envie que le driver crash parce que la matrice fournie par l'utilisateur était la matrice nulle.
[^] # Re: option -Ofast
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Tu as essayé de compléter avec d'autre optimisation agressive ? -Ofast, -ftree-vectorize (inclus dans O3 à priori) -fomit-frame-pointer (pour avoir un registre de plus) -funsafe-loop-optimizations (utile, si tu n'utilises pas le mot clef restrict et que tu utilises beaucoup de pointer qui ne pointe jamais sur la même zone mémoire) -floop-strip-mine (avec --with-ppl et --with-cloog, pour utiliser l'infrastructure de réécriture de boucle) -fwhole-program (pour la compile de tous les fichiers C en même temps ou presque et faire plus d'inlining) -funsafe-math-optimizations (est encore plus vilain avec la norme IEEE 754) -fsingle-precision-constant (si tu ne rajoutes pas de petit f derrière les constante avec des calculs uniquement 32 bits flottant, ce qui produit des calculs et des conversion 64 bits) -funroll-loops (peut avoir de bon effet pour la vectorisation) et surtout -march=native pour utiliser toutes les instructions à disposition -mfpmath=see si tu travailles avec un cpu intel car la fpu x87 est plus lente que le sse.
L'idée est de fournir un maximum d'informations sur ton code au compilateur pour qu'il puisse utiliser un maximum de propriétés pour avoir le code le plus rapide possible. L'aliasing (le fait d'avoir une possibilité d'avoir une zone mémoire pointé 2 fois) et les boucles mal faites sont des tueries de performances. Donner plus d'informations permet au compilateur de transformer ce qui pose problème.
"La première sécurité est la liberté"
[^] # Re: option -Ofast
Posté par windu.2b . Évalué à 2.
Peut-on en déduire qu'il fallait lire
-mfpmath=sse?[^] # Re: option -Ofast
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
oui sse, c'est une typo.
"La première sécurité est la liberté"
[^] # Re: option -Ofast
Posté par Shuba . Évalué à 1.
J'avais déja -O3 et -march=native, je ne crois pas avoir le support du sse sur mon proco (mais je sais pas vraiment comment tester ça) (et c'est dommage, parce que j'en profiterais grandement). Le -fomit-frame-pointer est sensé être activé par -O3 (et même avant), le -funsafe-math est activé par -ffast-math.
Je crains que -funroll-loops n'ait pas d'effet sur mon code, la plupart de boucles sont des boucles while (et l'arrêt se fait sur une condition aléatoire).
-fwhole-program et -fsingle-precision-constant ça a l'air cool, faut que je teste :)
Je crois que la principale raison pour la lenteur de mon code, c'est que l'architecture est tout sauf optimisée (même pas de multithreading alors que c'est très facile à paralléliser, naive sur certains points).
[^] # Re: option -Ofast
Posté par gasche . Évalué à 2.
[^] # Re: option -Ofast
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
je ne crois pas avoir le support du sse sur mon proco
Tu l'as forcément à moins d'avoir un PC de 10 ans.
Le -fomit-frame-pointer est sensé être activé par -O3 (et même avant)
Non, il ne l'est pas forcément car le code devient non debugable.
"-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging."
le -funsafe-math est activé par -ffast-math.
En effet.
Je crains que -funroll-loops n'ait pas d'effet sur mon code, la plupart de boucles sont des boucles while (et l'arrêt se fait sur une condition aléatoire).
Dans ce cas, tu peux tenter -funroll-all-loops, selon le code, cela peut bien marcher.
(même pas de multithreading alors que c'est très facile à paralléliser, naive sur certains points).
Dans ce cas regarde du coté de openmp, il suffit souvent de rajouter un "#pragma omp parrallel for private(i)" devant une boucle for pour la rendre parallèle.
"La première sécurité est la liberté"
# A propos de Coccinelle
Posté par Sylvestre Ledru (site web personnel) . Évalué à 7.
Dans le cadre du Google Summer of Code, le projet Scilab "accueille" deux projets de Coccinelle dont celui de la gestion C++ au sein de l'outil.
Voir: http://wiki.scilab.org/Ideas_of_development_for_Scilab
# D admis dans GCC ?
Posté par GeneralZod . Évalué à 5.
La dépêche laisserait croire que la prise en charge du langage D est intégré dans le tronc GCC mais contrairement à Go, ça n'est toujours pas le cas :(
https://bitbucket.org/goshawk/gdc/wiki/Home
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.