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
- L'annonce (1 clic)
- La liste des changements de GCC 4.2 (7 clics)
- Le sommet GCC 2006 (2 clics)
# GCJ
Posté par Aurélien Bompard (site web personnel) . Évalué à 7.
[^] # Re: GCJ
Posté par floriang . Évalué à 1.
[^] # Re: GCJ
Posté par freeze . Évalué à 6.
[^] # Re: GCJ
Posté par Etienne Juliot (site web personnel) . Évalué à 5.
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 reno . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 9.
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 lasher . Évalué à 6.
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 Troy McClure (site web personnel) . Évalué à 6.
[^] # Re: OpenMP
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
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 Sytoka Modon (site web personnel) . Évalué à 1.
[^] # Re: OpenMP
Posté par gvallee . Évalué à 3.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 lasher . Évalué à 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 briaeros007 . Évalué à 4.
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 mdlh . Évalué à 2.
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 lasher . Évalué à 3.
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 gvallee . Évalué à 2.
http://www.lam-mpi.org/
http://www.open-mpi.org/
[^] # Re: OpenMP
Posté par Samuel Thibault (site web personnel) . Évalué à 1.
[^] # Re: OpenMP
Posté par lasher . Évalué à 2.
[^] # Re: OpenMP
Posté par Vincent Danjean . Évalué à 2.
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 lasher . Évalué à 2.
<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 Samuel Thibault (site web personnel) . Évalué à 1.
[^] # Re: OpenMP
Posté par lasher . Évalué à 2.
[^] # Re: OpenMP
Posté par Samuel Thibault (site web personnel) . Évalué à 1.
[^] # Re: OpenMP
Posté par gvallee . Évalué à 1.
[^] # Re: OpenMP
Posté par Samuel Thibault (site web personnel) . Évalué à 2.
[^] # Re: OpenMP
Posté par gvallee . Évalué à 1.
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 Christophe Merlet (site web personnel) . Évalué à 3.
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 Beretta_Vexee . Évalué à 2.
[^] # Re: OpenMP
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
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 M . Évalué à 3.
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 mdlh . Évalué à 1.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 mdlh . Évalué à 1.
[^] # Re: OpenMP
Posté par lasher . Évalué à 4.
Bref, tout dépend de ... Non, je me tais. :-)
# Itanium
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
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 Glorbouille . Évalué à 3.
(A part ça, je n'ai pas de PS3, trop cher...)
[^] # Re: Itanium
Posté par gvallee . Évalué à 3.
[^] # Re: Itanium
Posté par reno . Évalué à 3.
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 gvallee . Évalué à 1.
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 reno . Évalué à 3.
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 lasher . Évalué à 2.
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 patrick_g (site web personnel) . Évalué à 4.
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 med . Évalué à 2.
[^] # Re: Itanium
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: Itanium
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
C'est pour cela que sur Itanium, on utilise ICC et non GCC.
[^] # Re: Itanium
Posté par lasher . Évalué à 2.
[^] # Re: Itanium
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Itanium
Posté par mdlh . Évalué à 6.
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 Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: Itanium
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
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 lasher . Évalué à 2.
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 mdlh . Évalué à 5.
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 Troy McClure (site web personnel) . Évalué à 4.
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 ciol . Évalué à 3.
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 Pascal . Évalué à 3.
http://fr.wikipedia.org/wiki/Compilateur
[^] # Re: Pseudo code
Posté par ciol . Évalué à 2.
[^] # Re: Pseudo code
Posté par ciol . Évalué à 1.
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 LeMagicien Garcimore . Évalué à 9.
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 lasher . Évalué à 3.
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 mdlh . Évalué à 1.
[^] # Re: Pseudo code
Posté par patrick_g (site web personnel) . Évalué à 4.
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=(...)
[^] # Re: Pseudo code
Posté par ciol . Évalué à 2.
# Concurrence et OpenMP
Posté par loufoque . Évalué à 3.
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 reno . Évalué à 2.
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 lasher . Évalué à 4.
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 loufoque . Évalué à 5.
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.
En effet, il est là pour introduire des algorithmes exploitant le parallélisme d'une manière peu élégante.
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.
"for" est un algorithme.
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.
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 Sebastien Binet . Évalué à 1.
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 herodiade . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.