Le problème c'est que pour tirer parti des GPU, il faut avoir des problèmes « intrinsèquement » parallèles, sans trop de synchro. Il faut aussi un problème assez gros pour recouvrir la latence due au passage des données sur le bus. Par contre je pense que le rapprochement CPU/GPU qui va être très rapidement fait [1] permettra à terme de mieux distribuer les tâches et de mieux exploiter le parallélisme lorsqu'il y aura lieu de le faire.
[1] AMD + ATI par exemple, ça va très vite donner des GPU+CPU sur la même puce, d'abord en séparé, puis au final avec partage de registres et d'unités fonctionnelles.
« Je comprend donc que TiVo veux simplement "protéger" son hardware. Le software qui s'exécute, lui est libre, enfin à mon sens. Et ce pourquoi je soutiens la GPL, c'est que le code source est utilisable et modifiable par tout le monde. »
Ben sauf que le matériel en question, il a été acheté. Il n'appartient plus à Tivo. Donc si je veux me pourrir la garantie, et essayer de mettre mon noyau, c'est mon problème.
La vérité, c'est que, comme il a été dit plus haut, tivo, pour garder ses certifs macrovision, etc., a besoin de pouvoir empêcher les gens de couper les pubs par exemple -- et donc il faut pouvoir empêcher les gens de modifier le logiciel qui tourne dans chaque boite.
Pour te donner un ordre d'idée, sur Itanium 2, les perfs crête se situent aux alentours de 6.4 GFLOPS, et une DGEMM tourne autour de 6.2 GFLOPS quelle que soit sa taille, et quel que soit le nombre de procs (au moins jusqu'à 8) avec la MKL. ATLAS fait un peu moins bien (je n'ai pas les chiffres).
Pour info, les noyaux de calcul de la MKL sont faits main (ils y fourrent de l'ASM tout partout) pour avoir la meilleure perf possible.
Sur Xeon je n'ai pas encore effectué toute ma batterie de tests, donc je préfère m'abstenir de commenter.
Quant à ta remarque sur les compilateurs, les intrinsics marchent pas si mal à ce que j'ai vu, vu qu'en fait ça revient juste à avoir une interface C au-dessus des instructions ASM. Pour les vecteurs de taille 16, je vois pas en quoi ce serait plus simple, étant donné le nombre de mailles manipulées simultanément.
Lorsque j'utilise la MKL (biblio propriétaire d'intel pour les maths) avec un produit de matrices carrées denses, j'ai quelque chose comme 97 % des performances crête. Mais je ne pense pas que ce soit vraiment significatif de codes de la vie réelle (en fait j'en suis même sûr).
En pratique, entre la puissance théorique d'un pentium en règle générale, et la performance réelle, l'écart est généralement assez grand. Et effectivement, avoir un IPC de 2 sur pentium, ou 2.5, c'est déjà pas mal du tout (voire carrément très bien).
Sur Itanium2, où tout est in-order sauf certains accès mémoire (et donc où tout est fait par le compilo), on réussit à avoir certains types de codes avec un IPC de 4 voire 4.5 sur les 6 théoriques, et on est extrêmement content quand ça arrive. Et pourtant, contrairement au pentium, dans ce cas précis, on comprend comment ça fonctionne (à peu près ;-) ).
Je suis justement en train de bosser sur Xeon/Core 2 duo. C'est sûr, ça va vite. Mais on est très loin de la performance crête.
...est à mon sens la programmation concurrente, ou multithreading en anglais.
Je ne suis pas d'accord avec cette vision des choses. La prog concurrente existe indépendemment des threads. De plus, on peut très bien avoir des threads de niveau utilisateur qui se coordonnent très bien, voire n'ont absolument pas connaissance de l'existence des voisins, car l'ordonnancement a été fait pour.
Mmmh, ce n'est pas tant un problème de background en maths que d'info théorique (les maths utilisées sont des formules logiques, le plus souvent du premier ordre : ET, OU, etc.). Mais de l'aveu d'un de ses rédacteurs, l'article en lui-même est franchement difficile d'accès. :-)
Un article plus « simple » (même s'il reste très théorique) est « A gentle introduction to semantic subtyping » [1]. Ça reste plutôt difficile à digérer quand on n'a pas l'habitude, mais c'est extrêmement intéressant.
À noter qu'une bonne intro à ces deux articles se trouvent dans le rapport de stage de DEA d'Alain Frisch; pour les courageux, sa thèse (230 pages) explique tout, du côté « semantic subtyping » jusqu'à l'implémentation de CDuce. Là par contre, j'ai décroché assez vite.
En l'occurence, ça ne "ressemble" pas aux ensembles mathématiques. "Semantic subtyping" (l'article fondateur derrière CDuce) montre qu'il y a équivalence parfaite (chose qui était connue intuitivement depuis un moment, mais que personne n'avait jamais démontré avant).
Oui enfin, il y a déjà eu des tentatives, et ce qu'ont fait les gens était tout bête : une ou deux secondes de silence au débout et/ou à la fin d'un morceau, et le hash n'est plus le même ...
« L'informatique n'est pas vraiment une science dure comme la physique, les mathématiques, la médecine »
Pardon ? L'informatique, c'est une branche des maths (comme il a déjà été dit ailleurs). D'un côté, tu as les informaticiens théoriques ; par exemple, qui eut cru que, pour assurer qu'un bête
SELECT * FROM TABLE1 WHERE COND=1
tout une algèbre avait été créée ? Et crois-moi, l'algèbre en question est loin d'être triviale. La sûreté des types (chose qu'on retrouve en OCAML, certes, mais aussi dans des langages aussi communs que Java...), c'est avant tout du lambda calcul, c'est à dire des maths (petite anecdote : Church, à l'origine du lambda-calcul, avait comme thésard un certain Turing, à l'origine des machines du même nom ... Et à eux deux, on peut affirmer qu'ils sont à l'origine des tous les langages informatiques ou presque).
De l'autre, tu as les chercheurs faisant de l'informatique plus appliquée : étant donné un certain type de machine, avec un certain type de processeur, qui possède un certain nombre de caractéristiques (superscalaire, vliw, multithreadé, que sais-je), comment faire pour obtenir la meilleure performance pour un type d'application donné avec une méthode la plus générale possible ?
Il y a trop de paramètres en jeu pour pouvoir répondre à cette question de manière théorique (latence des instructions, latence des accès mémoires, problèmes de faux-partage, de deadlocks, etc) ; on est donc obligé de mesurer la performance de la méthode d'optimisation élaborée.
En fait, je pense que l'informatique est une science au même titre que la physique : comme elle, elle possède deux extrêmes (théorie et application), et une infinité d'intéractions entre les deux.
Contrairement à la médecine ou la pharmacologie, par exemple, qui profite bien entendu des progrès effectués en physique et en chimie, mais qui sont essentiellement expérimentales.
« la vrai vocation des chercheurs universitaire c'est au moins de pousser leurs recherches à la production de quelque chose de tangible »
Pas vraiment ; quand tu es dans le domaine de la recherche fondamentale (en maths ou en physique par ex), tu ne peux pas t'attendre à avoir tout de suite une application plus ou moins directe. En info théorique non plus, globalement (le nombre de papiers d'info théoriques qui traînent des théorèmes et autres équations, mais qui ne comportent pas de ligne de code est loin d'être négligeable). Quand tu es dans le domaine des sciences appliquées, par contre, tu as bel et bien des possibilités ... d'application, et là le chercheur a plutôt intérêt à montrer que ses recherches fonctionnent. Le seul problème, c'est que le chercheur, une fois qu'il a montré que sa solution était viable, il a autre chose à faire comme ... trouver la réponse à un autre problème.
Le seul moyen que je vois pour « proprifier » le travail du chercheur, c'est d'avoir un/des ingénieurs de recherche dans le même labo, qui travaillent avec lui, et implémentent proprement un prototype une fois qu'on sait que ça fonctionne. Seulement voilà : un ingénieur de recherche, c'est pas gratuit, et à moins de pouvoir ensuite se faire des sous avec le prototype, je ne vois pas pourquoi les labos s'embêteraient avec l'embauche de ce genre de gens (ça arrive, ceci dit, même en France).
« Encore une fois, derrière recherche il y a "tentative de démonstration d'une théorie" et l'informatique ne se démontre pas. »
Bien sûr que si. Un algorithme, ça se prouve ; une complexité algorithmique, ça se démontre ; une méthode de parallélisation efficace sur un type d'architecture, ça se conçoit puis se mesure ; les compilateurs passent leur temps à prouver que ton code est (in-)valide, du point de vue du langage utilisé ; les bases de données fonctionnent grâce aux propriétés algébriques grâce auxquelles on assure certaines propriétés (intégrité relationnelle, etc.).
Ou bien tout bêtement, faire en sorte d'avoir des machines 100% compatibles avec le linux qu'ils fournissent est fastidieux étant donné la disponibilité des drivers pour le matériel qu'ils fournissent. Je peux comprendre qu'ils aient autre chose à faire que changer de fournisseur de chipsets/cartes vidéo/carte mère/carte réseau/etc. ...
C'est vrai.
Maintenant de ce que j'ai compris, le monsieur barbu a dit que les méchants d'Al-Qaida mettaient des backdoors dans windows. Je ne vois pas trop comment trouver ce genre d'affirmation crédible ...
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>
« 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é.
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.
« 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.
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.
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 ... :-/
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: Pourquoi ne pas utiliser de processeurs graphiques ?
Posté par lasher . En réponse au journal Super calculateur météo france et langage. Évalué à 2.
[1] AMD + ATI par exemple, ça va très vite donner des GPU+CPU sur la même puce, d'abord en séparé, puis au final avec partage de registres et d'unités fonctionnelles.
[^] # Re: pas tout à fait exact ?
Posté par lasher . En réponse à la dépêche GPL3, TiVo ou TiVo pas ?. Évalué à 6.
Ben sauf que le matériel en question, il a été acheté. Il n'appartient plus à Tivo. Donc si je veux me pourrir la garantie, et essayer de mettre mon noyau, c'est mon problème.
La vérité, c'est que, comme il a été dit plus haut, tivo, pour garder ses certifs macrovision, etc., a besoin de pouvoir empêcher les gens de couper les pubs par exemple -- et donc il faut pouvoir empêcher les gens de modifier le logiciel qui tourne dans chaque boite.
[^] # Re: Comment font-ils ?
Posté par lasher . En réponse au journal Super calculateur météo france et langage. Évalué à 4.
[^] # Re: concours de b*te
Posté par lasher . En réponse au journal Super calculateur météo france et langage. Évalué à 3.
Pour info, les noyaux de calcul de la MKL sont faits main (ils y fourrent de l'ASM tout partout) pour avoir la meilleure perf possible.
Sur Xeon je n'ai pas encore effectué toute ma batterie de tests, donc je préfère m'abstenir de commenter.
Quant à ta remarque sur les compilateurs, les intrinsics marchent pas si mal à ce que j'ai vu, vu qu'en fait ça revient juste à avoir une interface C au-dessus des instructions ASM. Pour les vecteurs de taille 16, je vois pas en quoi ce serait plus simple, étant donné le nombre de mailles manipulées simultanément.
[^] # Re: concours de b*te
Posté par lasher . En réponse au journal Super calculateur météo france et langage. Évalué à 2.
[^] # Re: concours de b*te
Posté par lasher . En réponse au journal Super calculateur météo france et langage. Évalué à 3.
Sur Itanium2, où tout est in-order sauf certains accès mémoire (et donc où tout est fait par le compilo), on réussit à avoir certains types de codes avec un IPC de 4 voire 4.5 sur les 6 théoriques, et on est extrêmement content quand ça arrive. Et pourtant, contrairement au pentium, dans ce cas précis, on comprend comment ça fonctionne (à peu près ;-) ).
Je suis justement en train de bosser sur Xeon/Core 2 duo. C'est sûr, ça va vite. Mais on est très loin de la performance crête.
[^] # Re: Le plus gros défi...
Posté par lasher . En réponse au journal L'expressivité des langages. Évalué à 3.
Je ne suis pas d'accord avec cette vision des choses. La prog concurrente existe indépendemment des threads. De plus, on peut très bien avoir des threads de niveau utilisateur qui se coordonnent très bien, voire n'ont absolument pas connaissance de l'existence des voisins, car l'ordonnancement a été fait pour.
[^] # Re: cduce ? et les sous type ?
Posté par lasher . En réponse au journal L'expressivité des langages. Évalué à 2.
Un article plus « simple » (même s'il reste très théorique) est « A gentle introduction to semantic subtyping » [1]. Ça reste plutôt difficile à digérer quand on n'a pas l'habitude, mais c'est extrêmement intéressant.
À noter qu'une bonne intro à ces deux articles se trouvent dans le rapport de stage de DEA d'Alain Frisch; pour les courageux, sa thèse (230 pages) explique tout, du côté « semantic subtyping » jusqu'à l'implémentation de CDuce. Là par contre, j'ai décroché assez vite.
[1] « gentle », mais bien sûr ...
[^] # Re: cduce ? et les sous type ?
Posté par lasher . En réponse au journal L'expressivité des langages. Évalué à 2.
[^] # Re: Le piratage, c'est m@l !
Posté par lasher . En réponse au journal Une nouvelle saison de chasse commence.... Évalué à 2.
[^] # Re: Dommage...
Posté par lasher . En réponse à la dépêche OCaml 3.10.0 est sorti. Évalué à 2.
Pardon ? L'informatique, c'est une branche des maths (comme il a déjà été dit ailleurs). D'un côté, tu as les informaticiens théoriques ; par exemple, qui eut cru que, pour assurer qu'un bête
tout une algèbre avait été créée ? Et crois-moi, l'algèbre en question est loin d'être triviale. La sûreté des types (chose qu'on retrouve en OCAML, certes, mais aussi dans des langages aussi communs que Java...), c'est avant tout du lambda calcul, c'est à dire des maths (petite anecdote : Church, à l'origine du lambda-calcul, avait comme thésard un certain Turing, à l'origine des machines du même nom ... Et à eux deux, on peut affirmer qu'ils sont à l'origine des tous les langages informatiques ou presque).
De l'autre, tu as les chercheurs faisant de l'informatique plus appliquée : étant donné un certain type de machine, avec un certain type de processeur, qui possède un certain nombre de caractéristiques (superscalaire, vliw, multithreadé, que sais-je), comment faire pour obtenir la meilleure performance pour un type d'application donné avec une méthode la plus générale possible ?
Il y a trop de paramètres en jeu pour pouvoir répondre à cette question de manière théorique (latence des instructions, latence des accès mémoires, problèmes de faux-partage, de deadlocks, etc) ; on est donc obligé de mesurer la performance de la méthode d'optimisation élaborée.
En fait, je pense que l'informatique est une science au même titre que la physique : comme elle, elle possède deux extrêmes (théorie et application), et une infinité d'intéractions entre les deux.
Contrairement à la médecine ou la pharmacologie, par exemple, qui profite bien entendu des progrès effectués en physique et en chimie, mais qui sont essentiellement expérimentales.
« la vrai vocation des chercheurs universitaire c'est au moins de pousser leurs recherches à la production de quelque chose de tangible »
Pas vraiment ; quand tu es dans le domaine de la recherche fondamentale (en maths ou en physique par ex), tu ne peux pas t'attendre à avoir tout de suite une application plus ou moins directe. En info théorique non plus, globalement (le nombre de papiers d'info théoriques qui traînent des théorèmes et autres équations, mais qui ne comportent pas de ligne de code est loin d'être négligeable). Quand tu es dans le domaine des sciences appliquées, par contre, tu as bel et bien des possibilités ... d'application, et là le chercheur a plutôt intérêt à montrer que ses recherches fonctionnent. Le seul problème, c'est que le chercheur, une fois qu'il a montré que sa solution était viable, il a autre chose à faire comme ... trouver la réponse à un autre problème.
Le seul moyen que je vois pour « proprifier » le travail du chercheur, c'est d'avoir un/des ingénieurs de recherche dans le même labo, qui travaillent avec lui, et implémentent proprement un prototype une fois qu'on sait que ça fonctionne. Seulement voilà : un ingénieur de recherche, c'est pas gratuit, et à moins de pouvoir ensuite se faire des sous avec le prototype, je ne vois pas pourquoi les labos s'embêteraient avec l'embauche de ce genre de gens (ça arrive, ceci dit, même en France).
« Encore une fois, derrière recherche il y a "tentative de démonstration d'une théorie" et l'informatique ne se démontre pas. »
Bien sûr que si. Un algorithme, ça se prouve ; une complexité algorithmique, ça se démontre ; une méthode de parallélisation efficace sur un type d'architecture, ça se conçoit puis se mesure ; les compilateurs passent leur temps à prouver que ton code est (in-)valide, du point de vue du langage utilisé ; les bases de données fonctionnent grâce aux propriétés algébriques grâce auxquelles on assure certaines propriétés (intégrité relationnelle, etc.).
[^] # Re: Aucun intérêt ...
Posté par lasher . En réponse à la dépêche Des machines Dell sous Linux. Évalué à 5.
[^] # Re: Un enjeu de société
Posté par lasher . En réponse à la dépêche « Logiciels libres : un enjeu de société » avec Richard Stallman - 19 mai 2007 (Paris). Évalué à 2.
[^] # Re: Un enjeu de société
Posté par lasher . En réponse à la dépêche « Logiciels libres : un enjeu de société » avec Richard Stallman - 19 mai 2007 (Paris). Évalué à 2.
Maintenant de ce que j'ai compris, le monsieur barbu a dit que les méchants d'Al-Qaida mettaient des backdoors dans windows. Je ne vois pas trop comment trouver ce genre d'affirmation crédible ...
[^] # Re: OpenMP
Posté par lasher . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 2.
[^] # Re: OpenMP
Posté par lasher . En réponse à la dépêche Sortie de GCC 4.2. É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 lasher . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 2.
[^] # Re: Concurrence et OpenMP
Posté par lasher . En réponse à la dépêche Sortie de GCC 4.2. É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: OpenMP
Posté par lasher . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 4.
Bref, tout dépend de ... Non, je me tais. :-)
[^] # Re: OpenMP
Posté par lasher . En réponse à la dépêche Sortie de GCC 4.2. É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: Pseudo code
Posté par lasher . En réponse à la dépêche Sortie de GCC 4.2. É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: Itanium
Posté par lasher . En réponse à la dépêche Sortie de GCC 4.2. É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 lasher . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 2.
[^] # Re: Itanium
Posté par lasher . En réponse à la dépêche Sortie de GCC 4.2. É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: OpenMP
Posté par lasher . En réponse à la dépêche Sortie de GCC 4.2. É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).