Après le tant attendu GCC 4.0 qui a vu la refonte complète son architecture interne voici maintenant la version 4.1 qui arrive.
Comme prévu la technologie SSA (Static Single Assignement) qui est au c½ur du nouveau GCC permet maintenant d'optimiser plus facilement le code source afin d'obtenir des améliorations générales. Le SSA est (en très gros) une forme intermédiaire entre le code source et le binaire dans laquelle chacune des variables du code source n'est assignée qu'une seule fois. Cette assignation unique a de nombreux avantages :
- Les définitions et les utilisations de chacune des variables deviennent claires et explicites.
- La majorité des analyses statiques du code source ne propagent les informations qu'à l'endroit strictement nécessaire.
- Un grand nombre d'optimisations sur la forme intermédiaire SSA deviennent linéaire en temps.
- De nombreux algorithmes deviennent plus concis et plus simples dans le cadre du SSA.
- On trouve ainsi dans cette nouvelle version 4.1 toute une série d'améliorations portant sur l'auto-vectorisation du code, notamment pour mieux profiter des unités multimédias des processeurs modernes (SSE ou Altivec). Cela ne remplacera pas des routines vectorisées "à la main" mais dans bien des cas c'est suffisant pour constater une amélioration significative de la vitesse d'exécution de certaines portions du code.
- L'infrastructure pour faire des optimisations inter-procédures est maintenant en place. Il s'agit en fait de propager l'information d'analyse du source tout au long du graphe représentant le programme afin d'en tirer le meilleur parti possible et de générer une vue plus globale. Le profilage du source est ainsi rendu plus "intelligent" et il va plus en profondeur afin d'améliorer l'efficacité du binaire en sortie des différentes passes d'optimisation.
- On trouve également une fonction pour marquer des portions de code en hot ou cold ce qui permet d'utiliser la mémoire cache des processeurs de façon plus rationnelle en ne chargeant que les instructions immédiatement utiles au programme en train de fonctionner (better instruction cache locality).
- Du coté sécurité GCC est maintenant capable de générer automatiquement du code rendant plus difficile les attaques de type écrasement de pile (stack-smashing attacks). A noter qu'il s'agit d'une réimplémentation plus propre et moins intrusive du patch ProPolice d'IBM. Celui-ci était disponible en tant que patch externe pour les versions 3.x de GCC et il était activé notamment sous OpenBSD, DragonFlyBSD et dans la distribution IPCop. On trouvait également ce patch sous Gentoo mais il n'était pas activé par défaut.
Maintenant que cette fonctionnalité de protection de la pile fait partie intégrante de GCC (ce qui était réclamée à corps et à cris depuis des années ) on peut penser que toutes les distributions vont faire profiter leurs utilisateurs de ce surcroît appréciable de sécurité. - Dans le domaine Java le compilateur spécialisé GCJ (qui peut générer du code natif ou du bytecode) a été grandement amélioré sur le plan de la stabilité et de la couverture des spécifications Java 1.4 (il se base maintenant sur GNU Classpath 0.19 avec un backport des corrections de bugs de Classpath 0.20). GCJ peut maintenant supporter beaucoup plus d'applications que précédemment : Le client bitorrent Azureus, le lecteur de fil RSSOwl ou le serveur applicatif JonAS en sont des exemples.
Un article détaillé sur les nouveautés spécifiques du compilateur Java GCJ 4.1 et sur la future version 4.2 est disponible sur l'excellent site Linux Weekly News. On apprend ainsi que le support de Java 1.5 pourrait utiliser le compilateur ECJ du projet Eclipse au lieu de GCJX (et ceci une fois que la GPL v3 sera adopté car c'est cette dernière qui permet de renforcer la compatibilité entre les licences libres et de reprendre le code Eclipse dans le projet GCC). - Enfin coté support matériel on remarque l'intégration d'une nouvelle architecture. Il s'agit de MorphoSys qui est une architecture hybride composée d'un module programmable (TinyRISC) et d'un module hardware reconfigurable (RC Array).
Pour ce qui est des évolutions futures du compilateur on peut se pencher sur les articles (très) techniques issus de la publication du sommet GCC de 2005 à Ottawa.
On découvre que, expansion rapide de GNU/Linux aidant, beaucoup de grandes entreprises de logiciel et de hardware soutiennent le développement de GCC en payant des développeurs à plein temps : Intel consacre beaucoup d'effort au support de l'Itanium avec le projet Gelato et IBM fait de même avec le support de sa nouvelle architecture Cell. Ces deux types de processeurs étant très particuliers, ils nécessitent un compilateur extrêmement performant et moderne pour optimiser correctement le code généré.
Apple pour sa part finance l'amélioration du support du langage Objective-C alors que les deux poids lourd du monde Linux commercial, Novell/Suse et Red Hat, participent également activement aux améliorations du compilateur libre.
Bien entendu tout cela ne peut que renforcer le caractère incontournable de GCC dans le monde du logiciel libre et même au-delà.
PS1 : Pour faciliter son travail de développement l'équipe GCC a abandonné en fin d'année le logiciel de gestion des versions CVS et a migré vers Subversion (dont la version 1.3 est disponible). Après KDE c'est encore un poids lourd du monde du libre qui a basculé vers Subversion.
PS2 : Merci à alenvers pour ce post explicatif que j'ai repris sans aucune vergogne.
Aller plus loin
- La liste des nouveautés de GCC 4.1 : (12 clics)
- SSA sur Wikipedia : (2 clics)
- Protection contre les écrasements de la pile : (2 clics)
- Le sommet GCC de 2005 : (1 clic)
- GCC sur Wikipédia (3 clics)
# Ca c'est de la bonne dépêche !
Posté par Cali_Mero . Évalué à 10.
Une petite question tout de même : les améliorations apportées dans cette nouvelle mouture produisent donc des binaires plus performants au final pour le même code source, si j'ai bien compris. Mais qu'en est il du temps de compilation lui-même ? Y-a t'il un surcout à ce niveau ?
Sinon, pour quel type de code/projets bénéficiera t-on le plus des améliorations de gcc 4.1 ? Et peut-on redouter des incompatibilités de certains codes sources comme ce fut le cas lors du passage à gcc 4.0 ?
# Esperons que la qualité suivra
Posté par Ontologia (site web personnel) . Évalué à 10.
MPlayer ne veux pas compiler avec, il impose gcc-3. Je me suis amusé à le forcer à utiliser gcc 4, ça ne compile effectivement, et il génère une erreur interne.
De même, le code généré par le compilateur Lisaac, qui a la particularité de gérer lui-même sa mémoire (ie. un gros malloc au début, et une gestion "à la main" des zones mémoires dans le code), ne compile généralement pas le code généré par le compilateur. Ce code est pourtant conforme à C99 (au minimum tout le corps du code).
Remarque GCC 3 déconne aussi parfois. Avec le même code craché par le compilateur, on remarque, si l'on compile en -O {2,3,s}, que le compilateur invente des registres (!!!). C'est vraiment assez marrant à regarder.
Il serait donc peut être intéressant qu'un jour, une équipe, comme celle de Xavier Leroy à l'INRIA s'amuse à prouver quelques morceaux du compilateur.
Ce qui a été fait pour un compîlateur mini C.
http://pauillac.inria.fr/~xleroy/compcert-backend/
GCC reste néanmoins un excellent logiciel, sans lequel le libre ne serait à mon avis pas ce qu'il est.
Félicitation à l'équipe.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Esperons que la qualité suivra
Posté par Jacquot Raphael . Évalué à 1.
[^] # Re: Esperons que la qualité suivra
Posté par Guillaume POIRIER . Évalué à 10.
Autant tu as raison qu'une partie du code C qui ne compilait pas avec GCC-4.x était moche, et le fait de l'adapter pour qu'il soit compatible avec GCC4 a été une bonne chose, autant les modifications qu'il y a eu à faire pour adapter l'assembleur inline a été un vrai cauchemar. La faute à certaines version de GCC qui ne respectent même pas les spécifs de leur propre docs. La faute aussi à l'équipe de GCC qui considère que c'est normal qu'un code ne puisse compiler que quand on active les optimisations: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203#c14 , la faute à l'équipe de GCC de considérer que c'est une situation normale que GCC ne puise pas réaliser son allocation de registre avec certains codes asm inline valides.
Oui, le code de MPlayer n'est pas ce qu'on puisse rêver de mieux en matière de qualité de code, mais ton aide est la bienvenue si tu veux remédier à ce problème.
[^] # Re: Esperons que la qualité suivra
Posté par Xavier Bestel (site web personnel) . Évalué à 10.
[^] # Re: Esperons que la qualité suivra
Posté par Chaddaï Fouché . Évalué à 5.
Par ailleurs la suite de la discussion est assez surréaliste avec un gros mensonge où quelqu'un confond NP-complet et "impossible", ce qui, même pour un étudiant en informatique comme moi est vraiment gros...
Il faut aussi tenir compte du fait que mplayer a une très grosse base de code assez ancien, ce qui ne peut pas aider, et que mplayer a également "besoin" d'utiliser du asm inline s'il veut garder la légèreté qui fait sa qualité en tant que lecteur vidéo. Franchement mplayer est l'aïeul du multimédia (vidéo) Linux et avec ffmpeg continue à être l'un des acteurs les plus important du multimédia libre. Alors insulter mplayer pour la qualité de son code c'est vraiment une réaction détestable ! Rien ne t'empêche d'aider au développement.
--
Jedaï
[^] # Re: Esperons que la qualité suivra
Posté par Ontologia (site web personnel) . Évalué à 4.
Oulala, je me sens visé...
Je n'ai pas dit que NP impliquait impossible. J'ai laissé entendre qu'on ne sait pas (et son auteur ne le sait pas non plus, je suis bien placé pour le savoir) comment le compilateur Lisaac réagira si on lui demande de compiler 1 000 000 de lignes.
Il consomme 512 Mo pour compiler 50 000 lignes (lib incluse) en 15 secondes (sur un athlon 2Ghz). Combien lui faudra t-il de mémoire et de temps pour compiler 1 000 000 de lignes ? On ne sait pas, on a jamais essayé.
L'analyse de flot (ie. l'algorithme testant toutes les branches de programme pour par exemple détecté qu'une variable est défini par n:=2*n+1 et 10 km virer un test de parité car il ne sert à rien) est un algorithme extrêmement consommateur de ressources, car exponentiel.
Pas impossible en théorie, mais potentiellement impossible sur le PC que j'achète chez l'assembleur du coin.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Esperons que la qualité suivra
Posté par M . Évalué à 1.
C'est pas la question.
Au pire tu peux utiliser la pile pour avoir tous les registres dispo (minus ceux en parametre) quand tu rentre dans un bloc asm inline.
[^] # Re: Esperons que la qualité suivra
Posté par Guillaume Knispel . Évalué à 6.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Esperons que la qualité suivra
Posté par lasher . Évalué à 10.
Tu veux dire, mis à part les fonctions de 4000 lignes et les hacks qu'on retrouve dans tous les sens ?
[^] # Re: Esperons que la qualité suivra
Posté par Corsaire . Évalué à 6.
Il semble cependant en effet que ce ne soit pas leur priorité et même trouvent les changement alourdissant le code.
Maintenant la question est vaut il mieux un code peut-etre un peu lourd mais qui compile sans erreurs, ou garder le code "leger" mais vomissant des pages d'injures à la compile ?
[^] # Re: Esperons que la qualité suivra
Posté par Colin Leroy (site web personnel) . Évalué à 4.
[^] # Re: Esperons que la qualité suivra
Posté par Krunch (site web personnel) . Évalué à 9.
Par ailleurs -Wsign-compare n'est pas activé par -Wall mais par -Wextra (anciennement -W).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Esperons que la qualité suivra
Posté par GNUtoo . Évalué à -9.
par contre xine a l'air bien ecris
[^] # Re: Esperons que la qualité suivra
Posté par Ph Husson (site web personnel) . Évalué à 7.
Prend le CVS ca marche sans probleme
(Pas testé avec le 4.1 pour le moment mais nickel pour le 4.0 je l'utilise plusieurs heures par jour sans probleme (vive le multiposte free))
[^] # Re: Esperons que la qualité suivra
Posté par Ontologia (site web personnel) . Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Esperons que la qualité suivra
Posté par Ph Husson (site web personnel) . Évalué à 4.
Avec gcc 4.1, testé avec 1h de multiposte free
[^] # Re: Esperons que la qualité suivra
Posté par Victor STINNER (site web personnel) . Évalué à 10.
On dit pas "plus restrictif", mais "plus respectueux des standards" :-) Avec l'option -Wall, gcc sort des avertissements souvent pertinant ou pouvant détecter des bugs. Les corriger prend du temps (si on n'avait jamais utilisé -Wall), mais ça ne peut qu'être bénéfique !
Bon, après il existe peut-être des faux-positifs ... mais j'en ai jamais rencontré.
Pour les extrémistes : options -ansi voir ... (aïe) -pedantic :-P
Haypo
[^] # Re: Esperons que la qualité suivra
Posté par lasher . Évalué à 7.
Euh, je n'utilise jamais -ansi, parce que de toute manière je serais obligé de définir certaines macros spécifiques à GCC, alors autant garder l'environnement de base. Mais je ne vois pas en quoi --pedantic est une option d'extrêmiste.
-Wall -W -pedantic
me semblent les options minimales pour qui veut faire un code un minimum correct (éventuellement avec l'option -std=c99 histoire de se mettre au goût du jour - mais bon, comme GCC n'implémente pas toutes les options de C99, ce sera du C99--).
[^] # C'est très bien -pedantic mais avec -std=c99 quand même
Posté par Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # D'autres outils
Posté par Victor STINNER (site web personnel) . Évalué à 3.
http://www.dwheeler.com/flawfinder/
https://securesoftware.custhelp.com/cgi-bin/securesoftware.c(...)
J'ai jamais compris si rats était libre ou nan !? Attendez je lis la licence ... GNU GPL2, ah nan c'est bon :-) C'est le formulaire qui me trouble.
J'ai l'impression que Flawfinder trouve plein de trucs, mais les rapports générés sont bordeliques. rats fait de jolis rapport en regroupant les fichiers (avec numéro de ligne) par erreur.
Puis y'a Valgrind pour traquer les erreurs d'accès mémoire et fuite de mémoire. La conférence à FOSDEM m'a vraiment convaincu que c'est un outil génial :
http://valgrind.org/
Pour un atelier sur la sensibilisation à la sécurité, j'avais entamé un article où vous y trouverez plein de liens :
http://www.haypocalc.com/wiki/Analyse_statique_de_code
Haypo
[^] # Re: D'autres outils
Posté par Krunch (site web personnel) . Évalué à 6.
http://goog-perftools.sf.net/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Esperons que la qualité suivra
Posté par agmk . Évalué à 2.
Pourrais-tu expliquer/expliciter à un béotien ? J'avoue que j'ai rien compris du tout...
[...] qui a la particularité de gérer lui-même sa mémoire (ie. un gros malloc au début, et une gestion "à la main" des zones mémoires dans le code)
"Le code", celui de l'appli ? ou celui du compilo ? Tu parles d'une forme de GC ?
Le fonctionnement de Lisaac a l'air assez intéressant, mais relativement obscur. Merci d'avance.
[^] # Re: Esperons que la qualité suivra
Posté par Thomas Douillard . Évalué à 5.
AMHA (Ontologia pourra me contredire) on a
code Lisaac --(compilo Lisaac)--> code C --( gcc )--> executable
Et ça coince à l'étape gcc, alors que normalement le code C généré est complètement correct.
Sinon, pour le 2, toujours AMHA, ca doit être le code C généré qui a des fonctions de gestions de mémoire maison, et qui gère l'allocation à l'intérieur du gros "malloc", sans doute une forme de gc, oui, mais là, je suis moins sûr ;)
[^] # Re: Esperons que la qualité suivra
Posté par Ontologia (site web personnel) . Évalué à 3.
Effectivement, Thomas a bien décrit le fonctionnement du compilateur.
La gestionnaire mémoire est tout simplement défini dans le fichier memory.li qui se trouve dans la lib du compilateur.
Rappelons que Lisaac est un compilateur ultra minimaliste : il ne connait même pas la conditionnelle, elle est défini dans la lib.
Un gros malloc est effectivement effectué au début, et un GC gère toute la mémoire.
Comme tout est intégralement compilé, le GC est défini dans la libairie en fait (le fameu memory.li)
Ça coince effectivement au niveau de la compilation avec gcc.
Je compare ce qui n'est pas comparable, mais comparer du C est beaucoup plus difficile que compiler du Lisaac (quoique, compiler l'héritage dynamique est extrêmement difficile, nécessite une analyse de flot sur touts le code et constitue de toutes façon un algo de complexité exponentielle), du moins compiler proprement : la grammaire de Lisaac tiens en 20 lignes, celle du C en 4 pages...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Esperons que la qualité suivra
Posté par Zakath (site web personnel) . Évalué à -1.
Et la marmotte qui met le chocolat dans le papier d'alu, tu la prouves aussi en Coq ?
Sérieusement, on est très très très très loin de pouvoir prouver du code C un tant soit peu non trivial, alors des bouts de gcc...
[^] # Re: Esperons que la qualité suivra
Posté par Ontologia (site web personnel) . Évalué à 3.
Ce qu'à fait X. Leroy, c'est de prouver le parser, la transformation du code source en code intermédiaire , l'allocation de registres et la traduction du code intermédiaire en code objet.
Prouver du code C, c'est plutôt l'oeuvre de Jean-Christophe Filliatre http://why.lri.fr
C'est vrai, que vu la taille de la grammaire, prouver du C non trivial est pas chose facile.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Esperons que la qualité suivra
Posté par Thomas Douillard . Évalué à 5.
(La flemme de fouiller dans mes notes pour voir si j'ai noté des trucs là dessus)
[^] # Re: Esperons que la qualité suivra
Posté par Krunch (site web personnel) . Évalué à 1.
http://www.cs.ucla.edu/~palsberg/paper/iccl92.pdf
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Esperons que la qualité suivra
Posté par Thomas Douillard . Évalué à 2.
Mais là, peut être que je me plante, mais il me semble qu'il y a des compilos C prouvés maintenant (Le papier date d'il y a 14 ans, ça me semble pas impossible ;) )
[^] # Re: Esperons que la qualité suivra
Posté par Gmooron . Évalué à 0.
Ada :p
[Mode chiant OFF]
# Gentoo
Posté par Guillaume Ceccarelli . Évalué à 2.
Pour le moment on peut quand même l'utiliser à coup d'entrées dans les fichiers de configuration de portage (le système de gestion de paquets de Gentoo) mais ça reste officiellement non supporté, même en ~arch qui est l'équivalent d'un "unstable" debian (obligation de rajout d'une variable d'environnement / de configuration I_PROMISE_TO_SEND_PATCHES_WITH_BUGS par exemple, en stipulant bien que si ton système casse avec GCC 4.x, pour le moment c'est ton problème.)
M'enfin... Je garde espoir, sachant que c'est surtout le code de certaines appllis qui ne compilent pas avec GCC 4 qui fait que le support officiel tarde.
[^] # Re: Gentoo
Posté par matt . Évalué à 3.
[^] # Re: Gentoo
Posté par klessou . Évalué à 1.
Enfin je suis peut être impressionné pour rien, mais c'est une application très "critique" en production dans une distribution comme Gentoo.
C'est un réel progret pour les distribution dite "source", mais je pense tout de même que GCC 4, va mêtre encore beaucoup de temps pour arriver en production dans la branche stable. Mais tout est relatif.
[^] # Re: Gentoo
Posté par tgl . Évalué à 7.
http://bugs.gentoo.org/showdependencytree.cgi?id=117482
Ça fait finalement assez peu de problèmes pour les gcc-4.x je trouve (comparativement à tout ce qui marche déjà bien quoi).
Tout à fait. Pour enfoncer encore un peu le clou, disons qu'il n'est pas vraiment question que gcc4 atteigne le ~arch tant qu'il restera des problèmes connus avec certains paquets qui sont fonctionnels par ailleurs. La branche ~arch n'est pas un terrain de jeu où l'on a le droit de sciemment provoquer des régressions, mais c'est une branche pour les paquets candidats à la stabilité. Aux imprévus près, elle est censée être complètement cohérente, enfin autant que possible.
Perso, je trouve ça plutôt rassurant que les devs Gentoo se tiennent à cette politique, y compris pour des paquets où la demande populaire peut devenir, comme ici, assez pressante. Et puis bon, c'est pas non plus comme si les ebuilds étaient absent de Portage et que ça prenait plus d'une dizaine de secondes pour y avoir accès...
# ObjectiveC++
Posté par Larry Cow . Évalué à 7.
[^] # Re: ObjectiveC++
Posté par FReEDoM (site web personnel) . Évalué à 1.
Webcore par exemple devrait pouvoir être porté plus facilement.
# apple et gcc
Posté par Troy McClure (site web personnel) . Évalué à 5.
http://www.kdedevelopers.org/node/1628
http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html
(le but étant de permettre des optimisations au moment du link)
# Ubuntu Dapper
Posté par Laurent Carlier . Évalué à 1.
https://lists.ubuntu.com/archives/dapper-changes/2006-March/(...)
# A propos des optimisations de code
Posté par Fabrice Mousset (site web personnel) . Évalué à 10.
Dans mon domaine on a l'habitude de travailler avec compilateurs relativement chers qui offrent des optimisations de codes très, très poussées (codewarrior, microtec, hi-tec, etc).
De puis quelques temps j'ai commencé à travailler avec le compilateur GCC et ses outils annexes, plus par curiosité et pour des développements personnels.
J'ai vu dans une doc de GCC version 3.xx, que celui-ci était incapable de faire une optimisation de code au niveau "module". En gros ça veut dire que si on utilise une fonction d'un module/fichier C d'une librairie, tout les fonctions du module sont importées dans le binaires.
Ce qui est relativement génant pour moi à moins de fractionner tous mes fichiers pour les exploser dans des fichiers séparés. Ce qui n'est pas forcément simple à faire ni agréable.
Je voulais simplement savoir si dans la version 4.0 ou 4.1 c'était encore le cas ? Quelqu'un sait où je pourrait trouver cette info ?
Et pour compléter encore un peu, est-ce qu'il y a quelque part des infos concernant la pertinance des optimisations et éventuellement un comparatif par rapport à d'autres compilateurs commerciaux ou libre ?
Sinon, super dépêche, très intéressante.
[^] # Re: A propos des optimisations de code
Posté par tuan kuranes (site web personnel) . Évalué à 10.
Pour les lib dynamiques, depuis gcc4.0 en C++ au moins il y a -fvisibility qui révolutionne la vie des librairies dynamiques :
: http://gcc.gnu.org/wiki/Visibility
[^] # Re: A propos des optimisations de code
Posté par gpe . Évalué à 4.
[^] # Re: A propos des optimisations de code
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: A propos des optimisations de code
Posté par gpe . Évalué à 3.
[^] # Re: A propos des optimisations de code
Posté par Philippe F (site web personnel) . Évalué à 10.
En general, gcc se fait battre par des compilos optimises pour des architectures specifiques, qui ont beaucoup moins de contraintes globales que gcc.
En vitesse de compilation, il se fait battre a plat de couture par Visual C++ vieille version.
Des projets comme KDE galerent parce que la gestion du code virtuel dans les classes n'est pas optimal. De ce que j'en comprends, le support C++ evolue tres lentement ce qui ralentit parfois de facon notable des gros projets C++. KDE etant probablement le plus gros projet Open Sourc en C++ qui utilise gcc.
Sur des archis embarques petite, je doute que gcc soit vraiment super efficace. Pour ce type d'architecture, ecrire un compilateur qui ne fait que du C et tient compte de certains caracteristiques des petits micros permet de meilleurs resultats que l'artillerie gcc.
Tu peux regarder sdcc (http://sdcc.sf.net) qui parait plus adapte. Sur certains projets, il arrivait au niveau de Keil.
Sinon, je travaille aussi dans l'embarque sur des micro 8bits et la facon dont tu ecris ton code a une influence certaine sur la taille du code genere par certains compilateurs. Certains vont mieux optimiser les acces aux variables globales, d'autres les acces aux variables locales. Certains n'aiment pas du tout les pointeurs (genre Keil, il aime pas du tout du tout les pointeurs au dela de 64K sur une archi 8 bits), d'autres les digerent facilement. Et chacun ont leur bugs : Codewarrior qui addresse les membres d'une structure sur un registre == pas possible d'avoir une strucutre plus grosse que 255 octets.
[^] # Re: A propos des optimisations de code
Posté par Fabimaru (site web personnel) . Évalué à 6.
D'un certain coté, écrire des programmes avec Visual C++ vieille version, ça me gave vu qu'il est limité point de vue support des templates (et c'est normal, il est vraiment vieux). La nouvelle version n'a rien à envier à gcc point de vue lenteur :-) (faudrait que je mesure la vitesse de compil sur gcc et vc7 sur notre gros projet).
[^] # Re: A propos des optimisations de code
Posté par gpe . Évalué à 6.
Je n'ai pas critiqué gcc. La question était de savoir si des comparatifs existaient entre gcc et des compilos commerciaux. J'ai apporté ma très modeste pierre avec une réponse basée sur des souvenirs...
Certe 20% ce n'est pas énorme et pas génant sur un PC mais dans l'embarqué c'est très pénalisant et pourtant je travaille sur une archi 32 bits (ARM7 et ARM9) avec des binaires de 2Mo. Mais 20% de plus c'est inacceptable chez nous... surtout si en plus le code est moins efficace. Mais il faudrait peut-être refaire le test avec cette version 4.1 de gcc pour voir l'évolution.
Je ne connaissais pas mais c'est inadapté à mon cas (32 bits, arm7 et arm9).
# Toujours pas l'intégration de GOMP...
Posté par tuan kuranes (site web personnel) . Évalué à 10.
En gros, bientot le seul moyen d'augementer les perfs pour une appli, utiliser les threads....puisqu'on pourra bientot plus acheter de plus gros proc...
Quelques docs pour ceux qui n'ont pas suivi :
- The Free Lunch Is Over de Herb Sutter (comité de normalisation du c++ : http://www.gotw.ca/publications/concurrency-ddj.htm )
- Managing Concurrency: Latent Futures, Parallel Lives ( http://www.gamearchitect.net/Articles/ManagingConcurrency1.h(...) )
Les optimisations de gcc 4 ne peseront pas lourds, face à des compilateurs qui savent gérer les multi-core (vc8, ic9, etc...), notemment par le support d'OPENMP ( http://www.openmp.org/drupal/ )
Vivement l'intégration d'OPENMP dans GCC plutot que de laisser ca en dans une branche inconnue ( http://gcc.gnu.org/projects/gomp/ ).
En tout cas, j'espere que les cours d'algo pour étudiant en ce moment mette plus l'accent qu'avant sur ce problème épineux... sinon "ca va pas etre facile".
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par tuan kuranes (site web personnel) . Évalué à 10.
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Orphis . Évalué à 2.
Mais bon, en même temps, pour le premier cours sur le sujet du semestre, fallait pas en demander trop !
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Philippe F (site web personnel) . Évalué à 4.
Sans meme aller jusqu'a l'efficacite, concevoir et debugger un programme dont les morceaux s'executent en parallele est enormement plus complexe que de concevoir et debugger un programme normal.
Perso, je pense que les threads ne doivent etre utilises qu'en cas d'extreme necessite couplee avec une necessite extreme. Genre calculs mathematiques, programmes gerant n connexions, etc.
Pour parallelise un programme plutot monotache dans son fonctionnement, c'est tout de suite beaucoup plus complique. Il faut isoler des portions du programme qui n'ont pas besoin d'ecrire des donnes communes, il faut regarder l'ordonancement de chaque tache pour voir si on peut pas en lancer qqs'une avant les autres, etc.
Je prefere plutot que mon noyau et son scheduler qui s'occupe de paralleliser l'utilisation des ressources de ma machine, que le compilateur qui essaye de paralleliser un programme.
Pour en revenir aux programmes pseudo-monotaches, je me demande a quel point ce n'est pas plus simple de faire un scheduler interne (ce qu'a fait mplayer) que de faire de la programmation par thread a tout va. Au moins, avec ton scheduler, tu sais ou tu vas.
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par lasher . Évalué à 4.
C'est dommage. Si un compilateur est capable, moyennant un léger surcoût à la compilation, d'extraire les instructions indépendantes, je ne vois pas pourquoi on ne pourrait pas en profiter pour paralléliser automatiquement le programme (création de pipelines logiciels, déroulage de boucles, déroulage/fusion, etc)
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Lionel Draghi (site web personnel) . Évalué à 5.
Au niveau optimisation, le processeur fait tout son possible pour explorer en avance de phase plusieurs chemins d'exécution, le compilateur va faire de son mieux pour détecter dans le code source des choses vectorisables, etc. etc.
Mais le parallélisme de l'application, par exemple les politiques d'ordonnancement ou d'accès aux donées partagées, si ce n'est pas décrit dans le code source, le compilateur ne peut pas l'inventer.
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par lasher . Évalué à 2.
Ben euh... Au moins la « threadification », le compilateur peut faire quelque chose...
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par forc3 . Évalué à 2.
Impossible de trouver du code ou quoi que ce d'autre que leur spec et presentation...
C'est que je veux le voir tourner ce truc !
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par gvallee . Évalué à 4.
Quelques autres liens qui pourraient egalement t'interesser, notamment le compilateur Omni (que j'ai utilise il y a quelque temps et qui fournit des exemples) :
- le compilateur Omni (LGPL) : http://phase.hpcc.jp/Omni/home.html
- un benchmark OpenMP (NAS Parallel Benchmarks in OpenMP) : http://phase.hpcc.jp/Omni/benchmarks/NPB/index.html
Mes 2 cents... :-)
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par tuan kuranes (site web personnel) . Évalué à 1.
http://gcc.gnu.org/projects/gomp/
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Ontologia (site web personnel) . Évalué à 3.
Bertrand Meyer, le concepteur d'Eiffel à conçu pour cela le modèle SCOOP : http://se.inf.ethz.ch/teaching/ss2004/0268/lectures/251-0268(...) pour Simple Concurrent Object-Oriented Computation
C'est un modèle qui propose une syntaxe pour Eiffel permettant de définir quand est-ce qu'un appel de message est asynchrone ou non.
Eiffel Software l'a implémenté en 1995.
Puisque la nature revient au galop ;-) je précise que le brouillon de publication que j'ai présenté sur ce site, n'est autre que l'adaptation du modèle SCOOP à un langage objet à prototype compilé.
https://linuxfr.org/~Montaigne/20582.html
L'idée de ce modèle est de permettre de la programmation parallèle, en pensant son code en tant que système multi agent.
Les problèmes de multithread ne se posent pas trop car les zones mémoires entre thread sont, dans ce modèle, étanches. C'est un peu l'idée de SCOOP.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Philip Marlowe . Évalué à 3.
Je suis content de l'apprendre. En fait, à ma connaissance, SCOOP avec son mot-clé separate et un fichier de ressources un peu semblable aux fichiers d'assemblage de classes (permettant de savoir si le nouveau "processeur" est un thread, un autre processeur, ou une machine distante, ou autre chose), ça n'a jamais été implémenté en 2006. Que la spécification date de 1995, je veux bien le croire.
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Lionel Draghi (site web personnel) . Évalué à 8.
J'en prends un extrait :
The mainstream state of the art revolves around lock-based programming, which is subtle and hazardous. We desperately need a higher-level programming model for concurrency than languages offer today; I'll have more to say about that soon.
<mode cynisme>
Encore un qui semble vachement au fait de l'état de l'art (son papier ne cite que Java). Je suis impatient de voir ce qu'il va nous pondre.
</fin du cynisme>
Ca me parait être l'occasion de rappeler que dans gcc, il y a un compilateur Ada, et que Ada propose un modèle de programmation parallèle d'une puissance inégalée.
Ces concepts sont intégrés depuis toujours dans le langage, ils ne s'agit pas d'une bibliothèque externe ou d'un concept minimaliste ajouté avec difficultés dans un langage pas du tout pensé pour ça.
En Ada, les taches ou les objets protégés sont des citoyens de première classe. Ils peuvent être manipulés comme beaucoup d'autres types. On peut par exemple déclarer un tableau de tache.
Si vous souhaitez faire un logiciel de calcul, de jeux, ou de traitement d'image, intégrant un tasking performant, basé sur un standard ISO, portable entre compilateur, portable entre OS, alors pas la peine d'attendre, c'est déjà dans gcc.
J'espère que la banalisation des dual-core augmentera l'intéret des développeurs pour Ada, qui permet d'écrire un code unique pour Linux/Solaris/Windows/etc., exploitant les ressources disponibles sur la machine, quel que soit le nombre de processeurs.
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Sylvain Sauvage . Évalué à 4.
J'ai de forts doutes : la mode est plus aux langages de scripts où on ne déclare pas grand'chose avant de s'en servir...
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par tuan kuranes (site web personnel) . Évalué à 1.
"mainstream" veut dire utilisé et accepté par tout le monde, industrie et academie.
C++, Java, C#, ruby, python => mainstream
ada, lisp, ocaml => peu utilisé, donc pas mainstream
Ada ne fait malheureusement pas parti du "mainstream".
Qui sait, les "task, "entry", "accept", "requeue", et autres "delay" feraont peut-etre leur coming-back.
# Protection de la pile par défaut sur les prochaines releases des distros
Posté par herodiade . Évalué à 10.
Ça serait formidable !
À ce jour, je n'ai pas eu d'autres echos que de la position de Fedora Core, dont un développeur expliquait sur une mailing-list que les packages sont désormais compilés avec cette option activée (la FC 5 sera donc releasée avec cette protection). Et évidement DragonflyBSD et OpenBSD qui utilisent son équivalent pour gcc3 depuis une paye.
Qu'en est-il des autres distributions ? quelles sont celles qui ont annoncé leur position par rapport à cette option (qu'ils aient décidé de la supporter ou non) ?
Qu'en pensent Debian, Ubuntu, OpenSuse et Mandriva ?
Je suis particulièrement inquiet pour Debian, qui a longtemps tenu le haut du pavé en matière de sécurité, du fait de la très haute exigeance qualité de son équipe de developpeurs. Mais qui semble ne plus tenir le rythme, par exemple par rapport à Fedora (qui intègre maintenant par défaut SELinux , Exec-Shield, fstack-protector , FORTIFY_SOURCE...).
Un grand nombre de ces protections (option /Gs de vc++, ACL ntfs, ...) sont même désormais intégrées dans les dernières releases de windows, cependant que (selon un sondage mené par debian-administration.org) les developpeurs Debian considèrent la sécurisation comme relativement secondaire (et je ne parle pas des couacs comme l'absence de maj sécu de juillet dernier, le temps de réponse aux problèmes de firefox en aout etc. !).
Quel dommage s'il fallait se priver de la qualité et stabilité légendaires de Debian (sur ce plan, Debian ne fléchit pas !) pour avoir un environement sécurisé par défaut, lors de la prochaine release (et non, recompiler toute l'archive avec -fstack-protector, créer les polices SELinux pour les daemons courants et le système de base etc. n'est pas une solution triviale. Et oui, ces protections sont devenues nécéssaire, parceque les pirates ont, eux aussi, progréssé. D'où le besoin du secure "by default").
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par olivn . Évalué à 3.
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par salvaire . Évalué à 2.
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par Frédéric Lopez . Évalué à 7.
C'est justement la saison de l'élection du chef d'orchestre chez Debian :
http://www.us.debian.org/vote/2006/vote_002
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par herodiade . Évalué à 2.
Peut-être pas pour le besoin de dévouement: certaines de ces technologies ne demandent pas beaucoup d'efforts particuliers, le terrain a déjà été déffriché par les autres distros, et il y a aussi du suport commercial derrière Debian (Xandros, Ubuntu, Progeny, DCC, ...), mais je crois que tu a raison en pointant le besoin de collaboration et la difficulté de prendre des décisions collectives comme les causes principales de ce problème.
Car même lorsque la mise en oeuvre de certaines de ces protections est assez simple, elle doit souvent être appliquée à toute l'archive ou aux composants centraux. Elle demande donc une décision collective (pour les mainteneurs gcc/glibc/kernel de Debian, ça représente peut-être plus de travail que la mise en oeuvre technique).
Dommage, j'aurai préféré que, même sur ces questions, le modèle de fonctionnement démocratique soit le plus efficace :(
Pour les chantiers plus lourds (comme l'intégration de politiques RSBAC ou SELinux), il aurait été juste que ceux qui tirent un profit commercial de Debian mettent leur responsabilité en oeuvre. Par exemple que DCC se montre enfin utile, plutot que de faire mal aux mouches !
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Par exemple, sur SELinux, je prefererais que debian choissise par défaut RSBAC.
http://www.rsbac.org/
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par mickabouille . Évalué à 2.
Après tout, ceux qui l'ont conçu sont les même qui aiment bien écouter les gens.
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par herodiade . Évalué à 3.
Bref, ils sont problablement les utilisateurs qui ont le plus besoin de cette technologie ; il est donc improbable qu'ils aient pris le risque de laisser des trous connus - même cachés. De même qu'ils n'ont surement pas choisi Rijndael pour devenir AES en fonction d'une quelquonque fragilité de l'algorithme, vu qu'ils seront contraints de l'utiliser quotidiennement.
Celà étant dit il faut reconnaitre que les contraintes de la NSA sont assez tortueuse, et (en conséquence ?) SELinux un poil byzantin.
Je suis d'accord avec Sytoka Modon (commentaire ci-dessus) pour privilégier RSBAC lorsque l'administration étasunienne n'est pas votre cible: le code est moins volumineux (potentiellement moins de bugs), le système est beaucoup plus facile à mettre en oeuvre (potentiellement moins d'erreurs d'admin) et surtout, certains composants de SELinux sont affectés par de sombres histoires de brevets logiciels qui font froid dans le dos.
Mais de là à dire que SELinux est une régression en termes de sécurité ....
Quoiqu'il en soit, ces systèmes sont peut-être contraignants et difficiles à mettre en oeuvre dans une distro (mais certaines l'ont fait ...) mais ça n'est pas le cas des options de renforcement à la compilation, comme fstack-protector et fortify ainsi que de certains patches du noyau ! C'est maintenant une responsabilité des mainteneurs de distribution, de contraindre un minimum de protections en les activants pour les binaires qu'ils produisent.
Quand on apprend qu'une majorité (je n'ai plus les chiffres en têtes, peut-être 70%) des failles critiques indéxées par le CERT sont des buffers overflow, précisément, ce que protègent ces outils simples et non intrusifs (dont la mise en oeuvre n'est pas lourde mais doit être faite par ceux qui packagent), on peut trouver irresponsable, pour des mainteneurs de distribution, de les ignorer.
# C++0x
Posté par Sebastien . Évalué à 4.
J'ai trouve que ce concept de "concept" etait vraiment tres interessant et devrait permettre de plus facilement resoudre certains problemes du C++ (notamment les collections d'objets polymorphiques qui devraient pouvoir etre vues comme des collections d'objets a n'importe quel endroit de l'arbre d'heritage)
Par contre je n'ai pas trouve de mention concernant XTI (eXtended Type Information) [3] qui aurait du/pu resoudre les problemes de persistence des donnees (entre autre!).
Quelqu'un a de plus amples informations concernant XTI ?
[1] la version light
http://www.artima.com/cppsource/cpp0x.html
[2] la version poussee
http://www.research.att.com/~bs/popl06.pdf
[3] http://lcgapp.cern.ch/project/architecture/XTI_accu.pdf
[^] # Re: C++0x
Posté par salvaire . Évalué à 2.
[^] # Re: C++0x
Posté par Sebastien . Évalué à 4.
Faut pas voir le mal partout, hein...
Je crois surtout que c'est une histoire de manpower.
Apparemment, Stroustrup est tout seul a implementer/developper cette librairie...
Donc normal que cela prenne du temps.
Moi, le seul reproche que je ferais ce serait: "mais pourquoi diantre ne pousse-t-il pas cette lib dans Boost comme ca pleins de gens (talentueux) s'y mettraient et contribueraient !?".
Quand on voit le nombre d'applications dans la vraie vie (TM) qu'aurait XTI, je suis sur que ce n'est pas une question du probleme de la "tour d'ivoire".
Juste un bete probleme de manpower (parce que BS, il a quand meme un vrai boulot aussi a cote).
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.