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.
![[en]](../images/en.png)
L'annonce (534 hits)-
La liste des changements de GCC 4.2 (1488 hits)
-
Le sommet GCC 2006 (239 hits)
> Lire la dépêche (69 commentaires, moyenne: 3).
Vous avez demandé le commentaire #832910.
Run by 
Cette page a été générée par Templeet en 0.0982s (dont 0.008 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
OpenMP
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
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
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
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
s/pourrait partie/pourrait tirer partie/
[^]Re: OpenMP
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
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
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
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 ;)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: OpenMP
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
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
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
Mmm, tu parles de MPC ? Il me semble qu'il est prévu qu'elle passe sous licence CeCILL.
[^]Re: OpenMP
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
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
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
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
Oui oui, mais GOMP implique gcc, et nous avons besoin d'être indépendants du compilateur...
[^]Re: OpenMP
Heu, ok mais ce qu'on fait avec libgomp, on peut le faire avec n'importe quel autre runtime de compilateur OpenMP... Et via l'interface libpthread, on a déjà fait tourner avec le compilo Sun aussi.
[^]Re: OpenMP
Tu aurais un pointeur vers de la doc ou des articles? Ca m'interesse... mais j'ai un peu la fleme de chercher. :-)
[^]Re: OpenMP
Heu, c'est en cours de soumission à IWOMP2007. Une version quasi-définitive est sur http://dept-info.labri.fr/~thibault/iwomp07.pdf
[^]Re: OpenMP
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
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
Recompile ta Gentoo et fait nous part de tes résultats.
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
[^]Re: OpenMP
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
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
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
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
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
Et le même problème se pose avec MPI...
Bref, tout dépend de ... Non, je me tais. :-)