« pourquoi choisir le C++ si c'est pour encapsuler du C ? »
Une réponse toute bête : parce qu'en C++, tu as les templates et les espaces de nommage, et que ça change la vie de plein de gens (et ça permet de faire exploser les temps de compilation aussi).
Maintenant en pratique je suis d'accord avec toi, souvent, ça ne sert à rien. Mais namespace et templates ne sont pas spécifiquement des constructions liées à la POO, et un langage procédural dérivé de C qui aurait ce genre de mécanisme en plus aurait beaucoup à y gagner je pense ... Sauf qu'au final, il suffit de faire du C en C++ avec ces deux trucs. :-)
Par contre, ce qui m'énerve bien plus, ce sont les gens qui font du C++, avec plein de construction C là où il existe un idiôme purement C++ (genre les casts façon C qui sont très très moches, et suppriment la vérification de type) aurait plus d'intérêt.
Le ... « truc », justement, tient au fait que le monsieur qui écrit le bouquin est professeur. Ça ne le dispense pas de dire des conneries bien sûr, mais si le monsieur écrit un bouquin dans sa spécialité, il y a fort à parier que
1/ Il aura demandé à être relu par au moins un de ses collègues (il suffit de lire les remerciements dans les bouquins pour voir que si une seule personne est référencée sur la couverture, souvent beaucoup d'autres ont participé)
2/ Il citera ses sources, aura vérifié nombre d'entre elles (ou bien aura dépêché un thésard ou un stagiaire pour le faire à sa place ...).
Évidemment, des gens de mauvaise foi, ça existe partout. Et par exemple, lorsque je cherche des infos en informatique relativement pointue sur wikipedia, ça me sert de bonne vulgarisation (en lisant les versions EN et FR, parce qu'une seule langue ne suffit généralement pas à avoir une explication tout à fait précise). Ensuite, je n'ai plus qu'à chercher les papiers de recherche qui vont plus loin.
Lorsque je veux me renseigner sur un autre type de connaissance, je cherche dans wikipedia aussi, mais très très souvent, n'ayant pas le recul nécessaire pour juger de la pertinence de ce que je lis, je dois quand même aller faire un tour du côté de la bibliothèque ou de la librairie du coin.
Si ton algorithme peut être formulé de façon récursive terminale, il existe une transformation « automatique » vers une forme récursive (les bons compilateurs sont capable de l'appliquer de façon limitée).
Sinon, même sans « dérécursiver », une forme récursive terminale en C revient à avoir un pointeur vers les données modifiées, de façon à ne copier que l'adresse du pointeur à chaque appel récursif et à modifier directement ta structure (en gros, ça revient vaguement à gérer toi-même ta pile d'arguments).
... Et sont à l'origine de la méga-dissipation de châleur qu'on observe actuellement sur les processeurs (pas qu'à cause de ces mécanismes, mais quand même ...). Et introduisent aussi une part non-négligeable d'inconnu pour qui veut obtenir des performances maximales, car on ne sait plus trop quoi fait quoi, entre le cache intelligent qui précharge tout seul, le coeur intelligent qui précharge tout seul, le coeur dans le désordre, qui interroge le cache partagé avec le coeur dans le désordre aussi d'à côté ...
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é.
[^] # Re: Le C++ peut être simple
Posté par lasher . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 1.
[^] # Re: peut etre que...
Posté par lasher . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 4.
Une réponse toute bête : parce qu'en C++, tu as les templates et les espaces de nommage, et que ça change la vie de plein de gens (et ça permet de faire exploser les temps de compilation aussi).
Maintenant en pratique je suis d'accord avec toi, souvent, ça ne sert à rien. Mais namespace et templates ne sont pas spécifiquement des constructions liées à la POO, et un langage procédural dérivé de C qui aurait ce genre de mécanisme en plus aurait beaucoup à y gagner je pense ... Sauf qu'au final, il suffit de faire du C en C++ avec ces deux trucs. :-)
Par contre, ce qui m'énerve bien plus, ce sont les gens qui font du C++, avec plein de construction C là où il existe un idiôme purement C++ (genre les casts façon C qui sont très très moches, et suppriment la vérification de type) aurait plus d'intérêt.
[^] # Re: Et ils ont bien raison
Posté par lasher . En réponse au journal Wikipedia encoe attaqué dans l'éducation. Évalué à 3.
1/ Il aura demandé à être relu par au moins un de ses collègues (il suffit de lire les remerciements dans les bouquins pour voir que si une seule personne est référencée sur la couverture, souvent beaucoup d'autres ont participé)
2/ Il citera ses sources, aura vérifié nombre d'entre elles (ou bien aura dépêché un thésard ou un stagiaire pour le faire à sa place ...).
Évidemment, des gens de mauvaise foi, ça existe partout. Et par exemple, lorsque je cherche des infos en informatique relativement pointue sur wikipedia, ça me sert de bonne vulgarisation (en lisant les versions EN et FR, parce qu'une seule langue ne suffit généralement pas à avoir une explication tout à fait précise). Ensuite, je n'ai plus qu'à chercher les papiers de recherche qui vont plus loin.
Lorsque je veux me renseigner sur un autre type de connaissance, je cherche dans wikipedia aussi, mais très très souvent, n'ayant pas le recul nécessaire pour juger de la pertinence de ce que je lis, je dois quand même aller faire un tour du côté de la bibliothèque ou de la librairie du coin.
[^] # Re: Récursivité terminale
Posté par lasher . En réponse au message Optimisation de la récursivité. Évalué à 2.
Je voulais dire « itérative » bien sûr.
# Récursivité terminale
Posté par lasher . En réponse au message Optimisation de la récursivité. Évalué à 2.
Sinon, même sans « dérécursiver », une forme récursive terminale en C revient à avoir un pointeur vers les données modifiées, de façon à ne copier que l'adresse du pointeur à chaque appel récursif et à modifier directement ta structure (en gros, ça revient vaguement à gérer toi-même ta pile d'arguments).
[^] # Re: 68k
Posté par lasher . En réponse au journal Un OS réécrit son code à la volée. Évalué à 2.
[^] # Re: 68k
Posté par lasher . En réponse au journal Un OS réécrit son code à la volée. Évalué à 6.
[^] # 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é.