Sortie de GCC 4.2

Posté par (page perso) . Modéré par Christophe Guilloux.
Tags :
0
17
mai
2007
GNU
GCC, pour GNU Compiler Collection, le compilateur de référence du monde libre est maintenant disponible en version 4.2 a annoncé ce mardi 15 mai Mark Mitchell, le responsable de la coordination du projet.

Selon lui cette version est particulièrement importante car elle contient de nombreuses nouvelles fonctions en plus des habituelles corrections de bugs.

NdM: Merci à Sytoka Modon pour avoir proposé une dépêche sur le même sujet. L'une des fonctions les plus attendues est le support de l'interface de programmation OpenMP par l'intermédiaire du projet GOMP. Cela va permettre d'exploiter plus facilement les nombreux processeurs des machines modernes (par exemple, les processeurs multi-coeurs) :

"OpenMP offers a simple way of exploiting parallelism without interfering with algorithm design; an OpenMP program compiles and operates correctly in both parallel and serial execution environments. Using OpenMP's directive-based parallelism also simplifies the act of converting existing serial code to efficient parallel code."

Traduction libre :
OpenMP offre un moyen simple d'exploiter le parallélisme sans interférer avec le design des algorithmes. Un programme OpenMP se compile et tourne correctement sur des environnements d'exécution parallèles ou non. Utiliser le parallélisme basé sur les directives d'OpenMP simplifie la conversion de code traditionnel en code parallèle efficace.

OpenMP est disponible pour les langages C, C++ et Fortran.

GCC 4.2 propose également des options pour rendre plus strict le contrôle du code lors de la compilation. En passant les options -fstrict-overflow et -Wstrict-overflow on peut maintenant se rendre compte d'erreurs du type débordement de la pile.
Une autre grosse nouveauté concerne les processeurs de type Itanium. Ceux-ci, de par leur conception, sont extrêmement dépendants de la qualité du compilateur. Intel a choisi de simplifier au maximum le hardware en n'intégrant pas de module d'ordonnancement des instructions dans le désordre (Out-of-order). C'est le compilateur qui doit donc s'occuper tout seul de trouver le parallélisme dans le code avant de générer le binaire. Pour cela il faut analyser au maximum le flot de données et cette version 4.2 de GCC le fait beaucoup plus efficacement en spéculant sur les données et les instructions futures.

Parmi les nouveautés, on notera également l'apparition des composantes 'allocatable' dans les structures de données et la gestion des flux d'entrée/sortie de la norme Fortran 2003.

On notera également que le langage Java est maintenant supporté sur la plateforme HPPA pour la version 32 bits de HP-UX.

Comme toujours le sommet annuel des développeurs GCC nous donne une indication du travail qui sera incorporé dans les futures versions du compilateur. Les lecteurs (courageux) pourront se plonger dans les papiers issus du sommet 2006 pour se faire une idée plus précise (attention fichier pdf de 13 Mo).
Les moins courageux se contenteront de jouer à classer les principaux contributeurs de GCC en fonction des employeurs : 6 pour IBM, 3 pour Suse et 2 pour RedHat.

Aller plus loin

  • # GCJ

    Posté par (page perso) . Évalué à 7.

    Pour ceux que GCJ intéresse, le travail qui a été fait sur Java 1.5 n'a pas pu être intégré dans GCC 4.2, de justesse : http://tromey.com/blog/?p=353
    • [^] # Re: GCJ

      Posté par . Évalué à 1.

      GCJ, mais à quoi va-t-il servir lorsque Java 7 sortira ?
      • [^] # Re: GCJ

        Posté par . Évalué à 6.

        Pour le C aussi il y a plusieurs compilateurs libres
      • [^] # Re: GCJ

        Posté par (page perso) . Évalué à 5.

        1) A compiler le Java.

        2) A permettre de supporter les plateformes offertes par GCC.

        3) A avoir une autre implémentation.

        La différence se pose aussi entre les 2 librairies du JDK : Classpath soutenu par GNU et le JDK officiel soutenu par Sun (+ Harmony d'Apache). A ce niveau, je parierai sur une fusion des implémentations Classpath et Sun, et un abandon d'Harmony.

        Pour tous ceux qui pensent qu'un 2e compilateur Java est inutile, il y a de fortes chances qu'ils utilisent déjà un autre au quotidien : le JDT. Dans Eclipse, le compilateur n'est pas celui de Sun, mais bien un compilateur interne, plus puissant et plus rapide (et plus adapté à un IDE).
        • [^] # Re: GCJ

          Posté par . Évalué à 2.

          >fusion des implémentations Classpath et Sun, et un abandon d'Harmony.

          J'ignore ce qui va se passer mais Harmony est sous license BSD (ou équivalente me souvient plus) alors que le JDK de Sun est GPL.

          Maintenant y-a t'il suffisamment d'interet parmi ceux qui font du code propriétaire pour maintenir Harmony..
  • # OpenMP

    Posté par (page perso) . Évalué à 9.

    OpenMP permet de faire du calcul parallèle relativement facilement, c'est plutôt orienté pour les machines SMP comme par exemple les PC bi-processeurs dual-core. En effet, les quadri-coeur x86 ne sont pas encore au point pour le calcul intensif, notament à cause du goulet d'étrangement pour l'accès à la mémoire.

    Sur plateforme Itanium, il y a de belles machines SMP, par exemple, les Altix de SGI qui permettent d'avoir en SMP plus de 4000 noeuds ! Heureusement, la gamme Altix permet de commencer plus modestement dans le SMP.

    Pour finir, si on veut vraiment faire un programme parallèle sur les GROSSES machines, il vaut mieux se tourner vers la bibliothèque MPI. Très peu de programme OpenMP dépasse les 100 tâches sans perte de performance alors que MPI permet d'aller jusqu'a 1000 tâches. Au dela des 1000 tâches, de nos jours, très peu de programmes sont efficases et il y a un gros boulot d'ingénierie pour trouver des solutions.

    En conclusion, pour le bureau et 99% des applications, OpenMP, c'est bon, mangé en ;-)
    • [^] # Re: OpenMP

      Posté par . Évalué à 6.

      Pour ce qui est d'OpenMP Vs MPI, je crois que le problème ne se pose pas dans ces termes. MPI (Message Passing Interface) fonctionne plutôt avec une approche par processus dans les implémentations courantes. OpenMP est « intrinsèquement » lié aux threads. Dans les deux cas, tout est question d'implémentation du standard.

      Par exemple, utiliser MPI sur un quad-core me semble carrément plus ridicule qu'utiliser OpenMP (en supposant que les deux implémentations soient bonnes).

      Intel, par exemple, possède une bonne implémentation d'OpenMP (propriétaire). Quant aux histoires de tailles pour le passage à l'échelle, c'est là encore totalement dépendant de l'implémentation. Si l'on a à sa disposition une implémentation d'OpenMP capable de savoir que la machine est de type NUMA (non-uniform memory access, en gros avec des barettes de mémoire "distribuées" physiquement), et qu'OpenMP est capable d'en tirer parti, je ne vois pas en quoi ce serait moins bon.

      Avec OpenMP, il y a plus de parallélisme "implicite" qu'avec MPI, où l'on doit explicitement tout faire. Forcément, ça fait qu'il y a moins de choses à gérer du côté du mec qui programme la bibliothèque MPI que du côté d'OpenMP. Cela dit, faire une implémentation de MPI qui torche, c'est très difficile aussi.
      • [^] # Re: OpenMP

        Posté par (page perso) . Évalué à 6.

        L'autre difference de taille c'est qu'avec MPI tu es obligé de reflechir avant de paralleliser, et d'y passer quelques plombes. Alors qu'avec openmp n'importe quel guignol peut paralleliser une boucle for à la truelle et avoir un magnifique speedup de 12% (ou carrément négatif). Mais sinon openmp est une invention merveilleuse qui met le parallelisme à la portée de tous, tout ça dans un style puissant et racé (miam le mélange des #pragma avec la lib openmp, comme c'est beau et élégant)
      • [^] # Re: OpenMP

        Posté par (page perso) . Évalué à 6.

        Tu dis à peu près la même chose que moi. En effet, OpenMP est plus simple à mettre en oeuvre sur un Quad-Core, mais dans ce cas là, tu n'a pas 100 tâches mais au plus 4 (si tu te débrouilles bien car au dela, tu charge trop la machine et tu perds en global à cause des caches).

        Maintenant, il n'y a pas beaucoup de machine SMP à 1000 coeurs (je connais les Altix de SGI par exemple). Ce sont souvent des clusters et donc les programmes sont réalisés avec MPI.

        OpenMP est en effet bien plus simple à mettre en oeuvre et permet de gagner facilement du temps de calcul. Comme nous avons tous des machines SMP aujourd'hui, cette bibliothèque va être de plus en plus fondamentale sur le bureau.

        Mais pour les gros calculs malheureusement, il faut plus se pencher sur ses algorithmes et prendre le temps de faire du MPI.

        Pour les calculs titanesques (future machine pétaflop), il faut trouver une nouvelle manière de programmer. Ce n'est pas moi qui le dis, ce sont des spécialistes que j'ai rencontrer. Personnellement, je n'ai pas accès à des machines ayant plus de 32 coeurs... Je n'ai donc pas idée des réels problèmes qui se posent.

        En effet, il n'y a quasiment aucun programme qui pourrait partie de 100% de la puissance d'une machine pétaflop aujourd'hui. Il n'y a donc pas encore de réel intérêt à construire une telle machine.
        • [^] # Re: OpenMP

          Posté par (page perso) . Évalué à 1.

          s/pourrait partie/pourrait tirer partie/
        • [^] # Re: OpenMP

          Posté par . Évalué à 3.

          De toute facon, les machines petaflop (enfin plutot les futures machines petaflop) atteindront le petaflop en puissance crete, non pas en puissance soutenue. En principe les applications arrivent a utiliser 60% au maximum de la performance crete (souvent bien moins que ca en fait), en fonction de leurs algorithmes et leur mise en oeuvre.

          Donc pour completer ce que tu dis : aujourd'hui aucune application ne peut utiliser 100% de la puissance d'une machine petaflop.
          • [^] # Re: OpenMP

            Posté par (page perso) . Évalué à 2.

            J'avais écrit 100% pour simplifier...

            Effectivement, dans le classement de l'efficacité des machines, on ne retrouve pas IBM en premier mais NEC avec ses machines vectorielles puis SGI avec ses Altix.

            Comme quoi, il faut toujours se méfier de la manière dont est réalisée un classement ou un comparatif.
        • [^] # Re: OpenMP

          Posté par . Évalué à 4.

          En effet, OpenMP est plus simple à mettre en oeuvre sur un Quad-Core, mais dans ce cas là, tu n'a pas 100 tâches mais au plus 4

          Tout dépend de l'implémentation (tiens, je me répète). Celles que je connais utilisent uniquement les threads POSIX (donc des threads noyau dans le cas de Linux). Lorsqu'on utilise une bibliothèque mixte (par exemple, des threads utilisateurs par-dessus des threads POSIX "vissés" sur des processeurs), alors on peut gagner énormément (je bosse actuellement sur des clusters d'itanium 2... Pour le moment je ne bosse que sur 4 * 2 coeurs, mais l'objectif est de faire du SMP/CMP NUMA).
          • [^] # Re: OpenMP

            Posté par . Évalué à 4.

            OpenMP et MPI ne réponde de toute facon pas au meme besoin.

            Avec MPI il est possible de faire une 'glue' pour sortir un code parallèle threader et 'mpi-er' pour utiliser au maximum un cluster smp (threader sur les noeuds, et par mpi entre les != noeuds par exemple)

            Avec openMP ca risque d'etre bien plus chiant car les dépendances des objets sont bien moins clair (avec le peu que j'ai pu en voir). Cela devrais compliquer énormement la migration de processus.

            Quant aux threads MxN (threads mixtes), en libre, de tête il y a marcel de la librairie PM2 qui permet de le faire.
            http://runtime.futurs.inria.fr/marcel/index.php

            C'est ce que tu utilise ?

            enfin il ne faut pas oublier les problemes d'allocations de mémoire toussa dans le cadre de processus multi threadé.
            libhoard is good for you ;)
            • [^] # Re: OpenMP

              Posté par . Évalué à 2.

              Il existe des implementations d'OpenMP qui supportent un model hybride entre memoire partagee et memoire distribuee.
              En effet, c'est pas du pur openMp, car pour etre efficace, tu dois utiliser des options supplementaires. Mais c'a utilise MPI derriere pour la communication entre les noeuds.

              Comme c'est du proprio, je ne donnerais pas le nom.
            • [^] # Re: OpenMP

              Posté par . Évalué à 3.

              Quant aux threads MxN (threads mixtes), en libre, de tête il y a marcel de la librairie PM2 qui permet de le faire.
              http://runtime.futurs.inria.fr/marcel/index.php

              C'est ce que tu utilise ?


              Non, j'utilise des threads concurrents, programmés par le thésard du monsieur en charge de Marcel/Madeleine (thésard qui est docteur maintenant). Il a développé pendant sa thèse une bibliothèque qui utilise des threads MxN, reproduit l'API MPI (avec quelques contraintes dues au fait qu'on parle de threads), et se charge comme une grande de faire la migration de pages, de faire des appels à MPI quand c'est nécessaire, etc. Un jour peut-être, on pourra la voir non-propriétaire ...

              Dernière petite chose : je ne connais pas d'implémentation de MPI qui soit threadsafe ET performante. Si quelqu'un en connaît une, ça m'intéresse.
              • [^] # Re: OpenMP

                Posté par . Évalué à 2.

                Si par "implémentation de MPI qui soit threadsafe ET performante" tu veux dire une mise en oeuvre de MPI qui tire profit de la memoire partagee sur les noeuds SMP, LAM-MPI et Open MPI font ca. A priori c'est vraiment thread-safe et ca marche plutot bien (j'utilise de temps en temps LAM-MPI je n'ai jamais eu de reels problemes).
                http://www.lam-mpi.org/
                http://www.open-mpi.org/
              • [^] # Re: OpenMP

                Posté par (page perso) . Évalué à 1.

                Mmm, tu parles de MPC ? Il me semble qu'il est prévu qu'elle passe sous licence CeCILL.
                • [^] # Re: OpenMP

                  Posté par . Évalué à 2.

                  Oui, exactement. Sauf que même s'il est prévu qu'il soit libéré en CeCILL-B, tant que c'est pas fait, je ne présage de rien.
              • [^] # Re: OpenMP

                Posté par . Évalué à 2.

                Dernière petite chose : je ne connais pas d'implémentation de MPI qui soit threadsafe ET performante. Si quelqu'un en connaît une, ça m'intéresse.

                Marcel+Madeleine+mpich=http://runtime.futurs.inria.fr/mpi/

                Tu as testé ? Si tu as rencontré des cas pathologiques, ils seront intéressés par les infos. Et passe le bonjour de ma part à Marc ;-)

                Pour geoffroy, "threadsafe ET performante" ça veut dire ne pas faire du tout d'attente active, recouvrir correctement calcul et comm, faire progresser les comm MPI pendant que les autres threads calculs, ...
                A priori, LAM et Open MPI étaient assez décevants quand les processus avaient quelques centaines de threads de calcul... Ça peut-être changé, ça fait un moment que je n'ai pas regardé.
                • [^] # Re: OpenMP

                  Posté par . Évalué à 2.

                  Pour Marcel+Madeleine+mpich, je n'ai pas encore testé, pour cause de « je suis déjà bien occupé avec des threads MxN à fourrer dans une implémentation OpenMP » (pas MPC pour le moment, mais bientôt, j'espère).

                  <hs>
                  « Et passe le bonjour de ma part à Marc ;-) »
                  Je n'oublierai pas. :-) Tiens d'ailleurs, on risque de se servir de tes outils de trace, dans un avenir proche (attends-toi à un mail de ma part).
                  </hs>
                  • [^] # Re: OpenMP

                    Posté par (page perso) . Évalué à 1.

                    Juste pour être sûr: tu sais qu'on a mis Marcel en-dessous de la libgomp (et ça marche plutôt bien) ?
                    • [^] # Re: OpenMP

                      Posté par . Évalué à 2.

                      Oui oui, mais GOMP implique gcc, et nous avons besoin d'être indépendants du compilateur...
                • [^] # Re: OpenMP

                  Posté par . Évalué à 1.

                  Je n'avais pas essaye avec plusieurs centaines de threads, ca explique certainement pourquoi je n'avais pas eu de probleme. ;-)

                  En plus, la combinaison Marcel/Madeleine/MPICH reste une valeur sure (que j'avais oublie). D'ailleurs ca fait longtemps que je ne l'ai pas utilise...
    • [^] # Re: OpenMP

      Posté par (page perso) . Évalué à 3.

      OpenMP est une fonctionnalité majeur de cette version de GCC mais que je vois mal être utilisé en dehors du calcul scientifique. Déja que la vectorisation est peu utilisé... :(

      Mais il y a une optimisation dans GCC 4.3 qui me semble beaucoup plus interessante. Celle de remplacer à la compilation les valeurs mathématiques constantes tel que acos(45), log(64) par leur résultats final au lieu de les calculer à l'exécution. Il me semble que cela aurait du être fait il y a des années !
      Seulement je n'ai aucune idée du gain de performance que cela va apporter, est-ce que cela concerne beaucoup de code genre plusieurs centaines de milliers de variables pour l'ensemble d'une distrib Linux, ou seulement quelques centaines... :/
      • [^] # Re: OpenMP

        Posté par . Évalué à 2.

        Recompile ta Gentoo et fait nous part de tes résultats.
        • [^] # Re: OpenMP

          Posté par (page perso) . Évalué à 3.

          Le problème étant alors de savoir si le gain de performance vient de l'ensemble des améliorations de GCC 4.3 ou juste de cette optimisation.

          J'ai déja comparé gcc 4.1 avec gcc 4.2 et gcc 4.3, et on gagne bien plusieurs % de performances a chaque fois.
          Mais je ne sais pas si il y a moyen d'avoir des stats concernant cette optimisation en particulier... soit à la compilation, soit via un analyseur de source distinct.
          • [^] # Re: OpenMP

            Posté par . Évalué à 3.

            IIRC pour supporter a la compil les acos(45) & co, il faut compiler GCC avec les lib gmp et mpfr.

            Je sais pas si on peut toujours compiler gcc-4.3 sans auquel cas pourrait voir la difference.

            Plus simplement, il y a peut etre une option pour activé/désactivé cette option.

            PS : je pense pas qu'on gagne grand chose dans les appli courante avec ca.
    • [^] # Re: OpenMP

      Posté par . Évalué à 1.

      La NASA ne semble pas avoir de probleme avec 512 taches en parallel sur la meme machine.

      Les problemes de performance a ce niveau la, ca depend surtout:
      - De l'implementation d'OpenMP
      - Du choix judicieux des sections critiques
      - De l'algorithm lui meme.
      • [^] # Re: OpenMP

        Posté par (page perso) . Évalué à 2.

        Cette machine ne serait-elle pas un Altix4700 de SGI ? En effet, sur ce type de machine complètement SMP, tu peux, selon ton nombre de noeud, avoir sans problème 512 tâches puisque la plus grosse Altix peut avoir 4096 noeud SMP !

        Je doute qu'avoir 512 tâches sur un quadri-processeurs dual-core soit efficace devant une autre implémentation faisant appel à mon de tâches et travaillant plus sur les caches.
        • [^] # Re: OpenMP

          Posté par . Évalué à 1.

          Je crois que je commence a comprendre ce que tu disais. Effectivement, faire tourner 100 taches concurrentes sur un quad, tu vas payer le cout de changement de context. Mais c'est pas trop le probleme d'openMP..
          • [^] # Re: OpenMP

            Posté par . Évalué à 4.

            Et le même problème se pose avec MPI...
            Bref, tout dépend de ... Non, je me tais. :-)
  • # Itanium

    Posté par (page perso) . Évalué à 5.

    Par rappport à la dépêche que j'avais proposé (qui était pas si mal rédigé, snif snif...), le point que j'avais laissé de coté est la partie Itanium.

    GCC était complètement largué sur Itanium par rapport au compilateur Intel car l'architecture EPIC oblige le compilateur à faire le boulot de l'optimisation des instructions. En effet, si on regarde l'architecture d'un Itanium par rapport à un x86, c'est beaucoup plus simple et du coup, Intel peut mettre bien plus de cache pour la même surface de silicium.

    Cependant, on est en pratique obligé de travailler avec le compilateur Intel... J'espère que l'accélération dù à la version 4.2 va nous permettre de retravailler avec gcc.
    • [^] # Re: Itanium

      Posté par . Évalué à 3.

      Tient, une question: les optimisations Out Of Order pour l'itanium ne pourrai pas profiter au cell? (ou au powerPC de la Xbox360 mais là, on s'en tape...). Est-il bien vrai que le cell contient un PowerPC qui n'optimise pas l'ordre des instructions?
      (A part ça, je n'ai pas de PS3, trop cher...)
      • [^] # Re: Itanium

        Posté par . Évalué à 3.

        Le Cell peut etre associe a d'autres processeurs ; son architecture ne fait pas qu'il doit etre obligatoirement associe au PowerPC. D'ailleurs une version associee a un Opteron a ete annoncee : http://www-03.ibm.com/press/us/en/pressrelease/20210.wss
        • [^] # Re: Itanium

          Posté par . Évalué à 3.

          En théorie tu as raison, les PPE et SPE n'ont aucune raison d'avoir la même architecture, même si dans le Cell ils sont tous les deux basés sur PowerPC (le PPE étant un vrai PowerPC): on pourrait imaginer un PPE étant un opteron et des SPE inchangé.

          Cependant dans l'annonce que tu présente a mon avis, le processeur Cell est toujours inchangé, ils sont juste mis en tant que co-processeur d'une machine a base d'opterons, donc de ce point de vue la il est toujours basé sur PPC.
          • [^] # Re: Itanium

            Posté par . Évalué à 1.

            Tu as raison, j'ai un peu trop simplifie... Pour completer un peu, a priori ils font ca pour que le PowerPC soit utilise uniquement dans son role initial, i.e. servir de front-end pour les coeurs Cell. Actuellement, il semble que le probleme est que les utilisateurs ont commence a utilise le PowerPC pour faire du calcul, ce qui pose pas mal de probleme. En mettant un Opteron devant le Cell, ils esperent que les gens vont arretes de faire cela. Du coup, les utilisateurs devraient reutiliser le SDK pour le Cell comme IBM le voudrait (le code arrivant sur le PPC est donc compile avec le compilo d'IBM et execute uniquement des taches de base pour les SPEs).

            Enfin c'est ce que j'ai retenu des differentes discussions que j'ai pu avoir avec des gens utilisant le Cell, je ne suis pas non plus specialiste, je peux me tromper. :-)

            Reste qu'a mon avis ca va toujours etre un cauchemar a programmer dans pas mal de cas. Par exemple a cause du bus entre les coeurs est tres rapide mais le lien entre le bus et les coeurs eux-memes sont beaucoup plus lents (je ne souviens pas des chiffres exacts), creant de gros problemes lorsque l'on deplace pas mal de donnees entre les coeurs. En meme temps ca reste une architecture interessante. :-)
      • [^] # Re: Itanium

        Posté par . Évalué à 3.

        >les optimisations Out Of Order pour l'itanium ne pourrai pas profiter au cell?

        Tu n'as pas marqué ce que tu voulais dire: les optimisations sont pour les processeur 'In Order' et oui, le PPE et les SPE d'un processeur Cell sont 'in order' comme l'Itanium.

        Donc potentiellement un optimisation prévu pour l'Itanium pourrait être utile a un processeur type Cell, bon il y a des *grosses différences* entre un processeur VLIW comme l'Itanium et superscalaire dual issue comme le PPE donc c'est quand même loin d'être évident.
      • [^] # Re: Itanium

        Posté par . Évalué à 2.

        Tient, une question: les optimisations Out Of Order pour l'itanium ne pourrai pas profiter au cell?

        Précision : pour à peu près toute personne cherchant à comprendre comment se comporte un programme très finement, l'OOO est quelque chose de cauchemardesque -- surtout sur les core (2) duo, qui ont des hardware prefetchers pour le cache (2 mini), 2 HP pour les données et un autre pour les instruction sur chaque coeur ... Bref, ça devient sportif de comprendre pourquoi telle ou telle façon de programmer apporte (ou pas) des performances.

        Concernant les histoires de spéculation pour Itanium, ça n'a RIEN à voir avec de l'out-of-order. Un Itanium 2 est un VLIW : le parallélisme d'instruction est explicite, et oui, tout repose donc sur le compilateur. D'un autre côté, la littérature concernant les transformations optimisantes en compilation est foisonnante, et énormément de choses intéressantes peuvent être implémentées au niveau du compilo... Le seul problème étant que c'est vraiment pas évident de hacker dans un compilateur.

        Bref, je suis content que GCC aille dans le bon sens, mais je doute malheureusement que ses performances soient comparables à celles d'ICC ... :-/
        • [^] # Re: Itanium

          Posté par (page perso) . Évalué à 4.

          >>> je doute malheureusement que ses performances soient comparables à celles d'ICC ... :-/

          Ce qui est un peu normal quand même non ? Le constructeur du CPU est normalement le mieux placé pour écrire un compilo aux petits oignons pour son processeur.
          • [^] # Re: Itanium

            Posté par . Évalué à 2.

            Et encore, avant de comparer faut-il encore s'assurer que les compilateurs respectent bien les mêmes normes. Voir par exemple ce billet : http://david.monniaux.free.fr/dotclear/index.php/2006/03/17/(...)
          • [^] # Re: Itanium

            Posté par (page perso) . Évalué à 2.

            surtout qu'on parle à ma connaissance de differences qui sont de l'ordre de 15% de vitesse en plus pour icc si on le compare à un gcc pas trop vieux (cad pas gcc 3.2). Pas de quoi tomber à la renverse.
            • [^] # Re: Itanium

              Posté par (page perso) . Évalué à 4.

              On a de l'Itanium pour faire du calcul parallèle. Si ton calcul dure 3 semaines, 15% c'est énorme.

              C'est pour cela que sur Itanium, on utilise ICC et non GCC.
              • [^] # Re: Itanium

                Posté par . Évalué à 2.

                Sans compter que Itanium 2, à quelques exceptions près, c'est plutôt du 20 à 30 % de perfs en plus.
                • [^] # Re: Itanium

                  Posté par (page perso) . Évalué à 2.

                  Mais avec Gelato et toutes ces initiatives l'écart va se réduire non ?
                  • [^] # Re: Itanium

                    Posté par . Évalué à 6.

                    Oui, mais ca prend du temps.

                    Les algos qui vont ameliorer les performances ont besoin d'information qui ne sont pas, ou difficilement accessible, ce qui ralentit beaucoup la compilation.

                    Le probleme est lie au fait que les optimisations existantes sur le papier se basent su la semantique du code haut niveau. Cependant, dans GCC, les optimisations se font a un moment ou le code n'a acces qu'a la representation bas niveau du code (RTL).
                    Pour l'instant, pas mal de travail est fait pour developer une API qui va enregistrer les informations interessantes lorsque le compilateur travaille sur la representation haut niveau, et rendre l'information disponible plus tard. Par exemple, treeSSA.

                    D'autres travaux sont fait pour effectuer des transformations sur le code qui en soit ne produit pas forcement de gain en performance, mais offre plus de flexibilite de transformation pour des algos a venir.
              • [^] # Re: Itanium

                Posté par (page perso) . Évalué à 2.

                bah non c'est pas énorme c'est deux ou trois jours de plus. Ou un cpu de plus. Avec l'avantage d'avoir un compilo plus fiable et moins buggé que icc.
                • [^] # Re: Itanium

                  Posté par (page perso) . Évalué à 4.

                  En pratique, c'est du Fortran donc ifort et non icc. Or g95 ou gfortran ne sont pas encore au niveau de ifort, notament si on utilise les bibliothèque OpenMP et MPI du constructeur.

                  Par ailleurs, mes chercheurs ont tendance a travailler en temps constant. C'est à dire que quel que soit la machine, il s'arrange pour avoir un calcul qui dure toujours le même temps. Donc un programme 20% moins rapide signifie en pratique que le problème étudié sera plus petit.
          • [^] # Re: Itanium

            Posté par . Évalué à 2.

            Oui... Mais non. :-)

            Après tout, en moyenne, il n'y a qu'une différence de 5% entre un gcc récent et un icc 9.x d'Intel sur x86. Sur des codes de calcul scientifique par contre, icc creuse encore l'écart, c'est vrai. Mais le système d'OOO du x86 permet de compenser certaines faiblesses du compilateur.
        • [^] # Re: Itanium

          Posté par . Évalué à 5.

          Concernant les histoires de spéculation pour Itanium, ça n'a RIEN à voir avec de l'out-of-order. Un Itanium 2 est un VLIW : le parallélisme d'instruction est explicite, et oui, tout repose donc sur le compilateur.

          Comment ca, RIEN?
          Pour faire du parallelisme explicite, il faut savoir, statiquement and non dynamiquement, quelles sont les instructions que tu peux deplacer afin de faire des groupes d'instructions les plus grand possibles, et de mettre un maximum de distance entre un chargement de valeur depuis la memoire et son utilisation effective afin de ne pas bloquer le pipeline.

          Tout cela necessite une analyse prealable poussee afin de determiner quels sont les deplacements d'instruction autorises qui ne vont pas modifier le resultat de l'execution. Ces meme informations peuvent etre utilisees par un non-VLIW, in order pipeline.

          Exemple trivial:
          A et B sont des tableaux d'entiers. C un pointeur d'un entier.
          for(i=0; i<n; ++i) {
          A[i]=(*C)*B[i];
          }

          Si tu ne peux pas prouver que C ne pointe pas sur une valeur de A[i], tu dois charger la valeur pointee par C a chaque iteration.

          Un pipeline Out-of-order va se rendre compte, en regardant l'adresse de A[i] que *C n'est pas modifie et va donc annuler le chargement. Il sera meme capable d'executer le chargement de B[i+1], le calcul de (*C)*B[i] et le stockage de A[i-1] en meme temps.

          Dans le cas d'un VLIW, si tu peux prouver que c'est different, ca se fera dans le meme cycle aussi.

          Dans le cas d'un non-VLIW, in-order, au moins tu fais juste le chargement de *C avant la boucle, et t'affranchis du chargement dans la boucle.

          Donc la meme information (pas d'alias entre A et C) va donner certes des resultats differents, mais benefiques pour les deux.

          Donc oui, au moins dans ce cas, les development actuels pour Itanium auront des consequences sur d'autres architectures.

          Cela est d'ailleur une source de ralentissement (sain) pour le development de ceux qui travaillent pour Itanium: Il serait beaucoup plus simple de ne se pencher que sur le cas de l'Itanium. Mais ils travaillent de facon generique afin que d'autres architectures puissent en profiter. Et comme un meme concept se traduit par des approches differentes au niveau des instructions, c'est un peu plus complexe a developer.
          • [^] # Re: Itanium

            Posté par (page perso) . Évalué à 4.

            Exemple trivial:
            A et B sont des tableaux d'entiers. C un pointeur d'un entier.
            for(i=0; i<n; ++i) {
            A[i]=(*C)*B[i];
            }


            Tiens d'ailleurs icc a repris un pragma bien sympathique de feu le compilateur sgi à l'époque des mips, c'est le #pragma ivdep, qui dit en gros au compilateur "vas-y mon gars, je te garantis que les iterations sont independantes les unes des autres tu peut me reordonner/vectoriser tout ça comme tu le sens". ça évite de tout faire reposer sur une analyse d'aliasing et de dependance complexe et hasardeuse, dommage que gcc n'ait pas celui-là.
  • # Pseudo code

    Posté par . Évalué à 3.

    Ce n'est pas possible de créer un pseudo-code, puis de compiler d'abord chaque language dans ce pseudo code (Java, C, Fortran...) et ensuite de se concentrer sur la compilation et l'optimisation de ce pseudo code ?
    Je me doute que ce n'est pas possible sinon ça serait déjà fait, mais la question que je me pose est pourquoi ?
    • [^] # Re: Pseudo code

      Posté par . Évalué à 3.

      C'est exactement ce qui est fait dans GCC, comme dans la plupart des compilateurs. Tu avais une bonne idée mais d'autres y ont pensé avant toi....
      http://fr.wikipedia.org/wiki/Compilateur
      • [^] # Re: Pseudo code

        Posté par . Évalué à 2.

        J'ai dû mal à penser que c'est ce qui est fait exactement. Sinon pourquoi le caml et consort peuvent se compiler en C et ne se compilent pas en pseudo-code gcc par ex. ? Pourquoi les compilateurs prennent un pseudo code différent les uns les autres ? Pourquoi je ne vois pas de gcc-premiere-phase dans mes programmes ? Pourquoi Python et Perl sont en train d'inventer un nouveau pseudo-code ? Et pourquoi dans la niouz c'est marqué : "OpenMP est disponible pour les langages C, C++ et Fortran.", et pas les autres langages ? Bref POURQUOI POURQUOI ?? Il me semble que l'implication d'un tel pseudo-ultra-code dépasse les limites de l'imagination et devrait se nommer pseudo-babel pour la forme.
        • [^] # Re: Pseudo code

          Posté par . Évalué à 1.

          Bon j'ai l'air de tout mélanger là mais c'est parce que je ne savais pas comment formuler ma question. Supposons que gcc possède un tel pseudo-code; qu'il soit spécifique ou pas à gcc on s'en fou (mais quand même !) :
          Pourquoi est-ce qu'on entend parler de "optimisation du C" ou de "optimisation de XXX, langage supporté par gcc", au lieu de simplement "optimisation du peudo-code gcc" ?
          • [^] # Re: Pseudo code

            Posté par . Évalué à 9.

            va jeter un coup d'oeil vers http://en.wikipedia.org/wiki/Compiler

            C'est exactement comme ca que sont fait la plupart des compilateurs multilanguages comme GCC. Le "pseudo code" dont tu parles, c'est la représentation intermédiaire de l'article wikipedia. D'ailleurs je trouve que l'expression pseudo-code n'est pas très heureuse dans ce cas puisqu'il s'agit plutôt d'une autre représentation du programme. Et pour être plus précis, cette représentation intermédiaire n'est pas forcement représenté par un fichier, mais peut être une structure de données en mémoire.

            Pour tes autres question:

            Sinon pourquoi le caml et consort peuvent se compiler en C et ne se compilent pas en pseudo-code gcc par ex. ?
            Parce-que c'est plus simple ? Mais pour gcj c'est exactement, il ne passe pas par le C ;)

            Pourquoi les compilateurs prennent un pseudo code différent les uns les autres ?
            Parce que c'est assez lié a la facon de faire des analyse/optimisations d'un compilateur donné? Mais il n'est pas rare de voir un nouveau front-end ajouté a gcc pour un nouveau langage (java par exemple)

            Pourquoi je ne vois pas de gcc-premiere-phase dans mes programmes ?
            Parce que tu t'en fous ? ;) Il y a beaucoup d'autres choses qui sont faites par gcc sans que tu ne le sache.

            Pourquoi Python et Perl sont en train d'inventer un nouveau pseudo-code ?
            Parceque leur but c'est d'exécuter ce pseudo code, pas de l'analyser et de le transformer en un autre code comme c'est le cas des compilo "classiques". C'est une différence fondamentale il me semble mais je suis pas un spécialiste de compilation.

            Et pourquoi dans la niouz c'est marqué : "OpenMP est disponible pour les langages C, C++ et Fortran.", et pas les autres langages ?
            Pas d'API sans doute. Le code est peut être là, mais si t'as d'interface pour l'appeler tu vas pas aller loin. Je pense que c'est plus un manque de ressources/temps qu'une limitation technique.

            Bref POURQUOI POURQUOI ?? Il me semble que l'implication d'un tel pseudo-ultra-code dépasse les limites de l'imagination et devrait se nommer pseudo-babel pour la forme.
            Il a rien de pseudo ton code :) Regarde les machines virtuelles de Java ou .NET par exemple.

            Pourquoi est-ce qu'on entend parler de "optimisation du C" ou de "optimisation de XXX, langage supporté par gcc", au lieu de simplement "optimisation du peudo-code gcc" ?
            La transformation de C (ou autre) vers la representation intermediaire (IR) n'est pas triviale et peut faire l'objet d'optimisation. Ensuite, j'imagine que meme si c'est une IR commune a tout les languages, il existe des constructions particuliere pour certains aspects d'un langage donné. J'ai pas d'exemple precis mais ca me semble pas surrealiste. Enfin, on entend souvent parler d'optimisation pour une architecture particuliere (genre IA64 dans la news) et ce quel que soit le langage (en theorie ;) )
            • [^] # Re: Pseudo code

              Posté par . Évalué à 3.

              « Et pourquoi dans la niouz c'est marqué : "OpenMP est disponible pour les langages C, C++ et Fortran.", et pas les autres langages ?
              Pas d'API sans doute. Le code est peut être là, mais si t'as d'interface pour l'appeler tu vas pas aller loin. Je pense que c'est plus un manque de ressources/temps qu'une limitation technique.»

              C'est aussi que la norme OpenMP ne parle que de C/C++ et FORTRAN, tout simplement. Certaines constructions n'existent d'ailleurs que pour FORTRAN ou que pour C/C++, car elles tirent parti des spécificités de chaque langage.
              • [^] # Re: Pseudo code

                Posté par . Évalué à 1.

                C'est effectivement un probleme de syntaxe et d'API non definit.
    • [^] # Re: Pseudo code

      Posté par (page perso) . Évalué à 4.

      >>> Ce n'est pas possible de créer un pseudo-code

      Y'a une excellente vulgarisation pour monsieur tout-le-monde disponible ici (elle date un peu mais cela permet de bien comprendre quand on n'est pas un spécialiste) =>

      http://www.onversity.com/cgi-bin/progactu/actu_aff.cgi?Eudo=(...)
  • # Concurrence et OpenMP

    Posté par . Évalué à 3.

    Il n'y a que deux façons de traiter d'une manière propre la concurrence : le message passing ou la software transactional memory.
    Les deux sont génériques et peuvent s'appliquer à tous types d'architecture parallèle. Erlang implémente le premier modèle, Haskell le second.

    OpenMP n'apporte aucune de ces deux solutions.
    La seule chose relativement utile, ce sont ses algorithmes pré-écrits qui exploitent le parallélisme. Algorithmes qui seraient bien mieux sous forme de bibliothèque comme par exemple ceux de la bibliothèque standard de C++, plutôt que sous forme de macros horribles intégrées au langage.
    • [^] # Re: Concurrence et OpenMP

      Posté par . Évalué à 2.

      Euh pourquoi tu te focalise sur la concurrence?
      Si j'ai bien compris OpenMP permet d'exploiter relativement facilement du parallélisme de donnée pour certains problèmes, c'est mieux adapté que le message passing ou le STM.

      Je ne vois pas ce que la "propreté" viens faire la dedans.
    • [^] # Re: Concurrence et OpenMP

      Posté par . Évalué à 4.

      « Il n'y a que deux façons de traiter d'une manière propre la concurrence »

      Déjà, dire ça sans argumenter correctement, c'est très limite. Ensuite, le passage de message c'est très bien, mais ça nécessite énormément de boulot car il faut vraiment TOUT gérer. Pour le moment, les mécanismes de mémoire transactionnelle proposent une solution très intéressante, mais du point de vue performance, c'est franchement pas encore ça (mais j'ai bon espoir que ça s'améliore).

      OpenMP n'est pas là pour faire du passage de message, ni pour faire dans la transaction mémoire. En fait, Il pourrait tout à fait utiliser ces deux mécanismes si les mécanismes étaient présents sur la machine cible, puisqu'il y a une partie compilation, et une partie runtime.

      Les pragmas OpenMP ne sont PAS des macros. Il existe une API standard tout à fait utilisable par l'utilisateur, pour permettre d'exploiter plus finement le parallélisme. Le standard ne décrit aucun des algorithmes que tu cites, il spécifie juste les constructions qui sont obligatoires, leur syntaxe, et leurs effets, ainsi que les construction facultatives. Pourquoi en faire quelque chose de dynamique uniquement, quand on est potentiellement capable de détecter à la compilation certaines propriétés importantes pour le parallélisme ? Pour pouvoir paralléliser le code, il faut pouvoir l'analyser en premier lieu ; ce n'est pas avec un code machine où tu as perdu une grande part de la sémantique de ton programme que ça va se faire.

      Du point de vue du programmeur d'applications scientifiques, l'utilisation d'OpenMP simplifie grandement la programmation d'applications ayant des sections parallèles : sans avoir à mettre en oeuvre toute la mécanique nécessaire à la parallélisation façon MPI, un programmeur qui sait qu'une portion de son code est parallèle pourra facilement découper celui-ci, en rajoutant un bête
      #pragma omp parallel
      {
      ____#pragma omp for
      ____for (i = 0; i < N; i++) {
      ________/* code parallèle ici */
      ____}
      }


      Et je passe sur le fait qu'on peut donner des indications sur la façon de paralléliser (taille des « chunks », c'est-à-dire le nombre d'itérations d'une boucle à donner à chaque thread, nombre de threads à utiliser, variables qui sont privées ou partagées, etc.).

      Certains codes se prêtent vraiment très bien à la parallélisation, par exemple tout ce qui est chiffrement par bloc, et le simple fait de faire un #pragma omp parallel for suffit à exploiter correctement le parallélisme du moment qu'on indique au runtime combien de threads créer. Ce code n'est pas isolé.
      • [^] # Re: Concurrence et OpenMP

        Posté par . Évalué à 5.

        Les techniques usuelles pour gérer la concurrence, à base de verrous etc., ne sont pas génériques et applicables de manière sûre dans tous les cas.
        C'est pour cela qu'on a élaboré des modèles sûrs, avec des abstraction de haut niveau, pour la programmation concurrentielle : le message passing surtout, mais aussi un peu les transactions.

        On le voit bien avec l'avènement des langages orientés concurrence comme Erlang, Concurrent Haskell, (ou même JOCaml ou C-omega pour les fans du Join-calcul, création française), ou avec des bibliothèques comme CCR (Coordination and
        Concurrency Runtime -- truc .NET) ou Intel Threading Building Blocks.

        OpenMP n'est pas là pour faire du passage de message, ni pour faire dans la transaction mémoire.

        En effet, il est là pour introduire des algorithmes exploitant le parallélisme d'une manière peu élégante.

        Les pragmas OpenMP ne sont PAS des macros.

        Ce sont des pragmas, qui sont des sortes de macros.
        Donc ce sont plus ou moins des macros. Ce que je voulais dire de toutes façons, c'est que cela ne s'intégrait pas au langage.

        Le standard ne décrit aucun des algorithmes que tu cites

        "for" est un algorithme.

        Pourquoi en faire quelque chose de dynamique uniquement, quand on est potentiellement capable de détecter à la compilation certaines propriétés importantes pour le parallélisme ?

        Je serais fort intéressé de voir un cas où un "for" parallélisé avec OpenMP peut être plus rapide qu'avec une solution sous forme de bibliothèque.

        Du point de vue du programmeur d'applications scientifiques, l'utilisation d'OpenMP simplifie grandement la programmation d'applications ayant des sections parallèles : sans avoir à mettre en oeuvre toute la mécanique nécessaire à la parallélisation façon MPI, un programmeur qui sait qu'une portion de son code est parallèle pourra facilement découper celui-ci, en rajoutant un bête
        #pragma omp parallel
        {
        ____#pragma omp for
        ____for (i = 0; i < N; i++) {
        ________/* code parallèle ici */
        ____}
        }


        En quoi est-ce plus simple que
        parallel_for(blocked_range<int>(0, N), /* code parallèle ici sous forme de fonction */);

        deuxième forme qui s'intègre bien mieux dans le langage, bien plus générique par ses aspects fonctionnel et d'intervalle (qui peut fonctionner avec tout type d'itérateur), et qui ressemble fortement à std::for_each ?

        (Cet algorithme est disponible tel quel dans Intel Threading Building Blocks)
        • [^] # Re: Concurrence et OpenMP

          Posté par . Évalué à 1.


          On le voit bien avec l'avènement des langages orientés concurrence comme Erlang, Concurrent Haskell, (ou même JOCaml ou C-omega pour les fans du Join-calcul, création française), ou avec des bibliothèques comme CCR (Coordination and
          Concurrency Runtime -- truc .NET) ou Intel Threading Building Blocks.


          Tiens, j'ai vu passer sur la mailing liste de boost un embryon de bibliotheque inspiree de C-omega:

          C'est par ici:
          Boost.Join
          http://channel.sourceforge.net
  • # strict-overflow

    Posté par . Évalué à 2.

    « GCC 4.2 propose également des options pour rendre plus strict le contrôle du code lors de la compilation. En passant les options -fstrict-overflow et -Wstrict-overflow on peut maintenant se rendre compte d'erreurs du type débordement de la pile. »

    En fait les options -(f|W)strict-overflow font des vérifications sur les débordements d'entiers, ce qui est carrément mieux vu qu'on avais déjà -Wstack-protector et -fstack-protector (+ des choses dans le noyau, dans la glibc, et le bit NX dans les processeurs récents) pour protéger la pile, et que les débordements d'entiers sont vraiment un type de bug fort à la mode dans les problèmes de sécurité depuis quelques temps :

    « -fstrict-overflow tells the compiler that it may assume that the program follows the strict signed overflow semantics permitted for the language: for C and C++ this means that the compiler may assume that signed overflow does not occur. » [http://gcc.gnu.org/gcc-4.2/changes.html].

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.