Articles précédents : Développeur
- [21] Sortie de la version 2.5 du langage Tom
- [15] Ouverture du code de CFE, un nouveau frontend C/C++ et sortie de l'infrastructure de compilation LLVM 2.0
- [21] Jajuk, l'organisateur de collection musicale recherche des développeurs
- [19] Relief 1.1, visualisation 3D de projets Java
- [119] Zend Framework 1.0.0 : PHP à la suite de Ruby on Rail
- [17] Mesa 7.0 : OpenGL 2.0 et 2.1
- [50] Anjuta 2.2.0 - Hurricane - est sorti
- [23] AJAX Chat Engine a besoin de vous
- [24] Première version stable de la forge CodingTeam
- [40] Akrogen, greffon Eclipse de génération de code, avec wizard pages décrits en XML/XUL
Liens connexes
- L'annonce d'Intel (448 clics)
- Le site de TBB (956 clics)
- Un article ArsTechnica (446 clics)
- Un article eWeek (309 clics)
Dépêche modérée par
Dépêche éditée par
Cet outil développé en C++ permet d'abstraire au maximum les détails complexes de la programmation multicoeur. Ainsi un développeur n'a plus à se soucier d'écrire son code pour les threads POSIX ou pour les threads Windows car c'est TBB qui s'occupe de tous les détails spécifiques.
La version commerciale de TBB continue d'exister (299$) et elle contient exactement le même code que la version libre et ne se distingue que par le support technique d'une durée d'un an. Elle supporte Windows, GNU/Linux et Mac OS X, alors que la version libre y ajoute Solaris 10, FreeBSD et le support des processeurs PowerPC G5 sur Mac OS.
La bibliothèque TBB fonctionne sur différents compilateurs (Intel, Microsoft et GCC) et se veut donc parfaitement indépendante par rapport à l'architecture sous-jacente, comme par rapport à l'environnement logiciel.
![[en]](../../../images/en.png)
L'annonce d'Intel (448 clics)-
Le site de TBB (956 clics)
-
Un article ArsTechnica (446 clics)
-
Un article eWeek (309 clics)
> Lire la suite (126 commentaires, moyenne: 2,7). [dépêche : 2324 caractères]
Intel désire évidemment démocratiser ce type de programmation afin de vendre ses produits. L'idéal pour cette firme serait que TBB devienne la méthode standard de programmation pour le multicoeur et elle s'en donne les moyens. Outre la facilité annoncée de programmation et la libération du code, on note qu'un site spécifique vient d'ouvrir (avec tous les attributs habituels : documentation, FAQ, CVS, forums, listes de diffusion, etc.).
C'est la première fois qu'Intel choisit de libérer une grosse application commerciale et cette démarche s'accompagne de toute la puissance de feu d'une multinationale décidée à imposer son produit. Un livre de la collection O'Reilly sort simultanément et un chapitre est même téléchargeable gratuitement au format PDF. Intel participe à toutes les conventions du libre (OSCON, Ubuntu Live, Linux World, etc.) en envoyant des ingénieurs faire des sessions de démonstrations pour "évangéliser" les programmeurs et les convaincre de la facilité d'utilisation de TBB.
Bien entendu toute cette machine promotionnelle peut agacer, mais de toute façon il est vraisemblable que TBB ne s'imposera que s'il apporte réellement une plus-value en terme de facilité de codage, de performance et d'indépendance vis-à-vis du système d'exploitation, du compilateur et de l'architecture CPU.
Alors ca c'est du bon
Autant les annonces d'Apple me laissait froid et limite méfiant...
Mais la c'est vraiment du bon ^^
(Enfin pour moi :p)
On vous ment! Mais pas moi...
-
[^]Re: Alors ca c'est du bon
Posté par ethtezahl () le 25/07/2007 à 09:40. (lien). Évalué à 2.Je n'ai pas le niveau pour développer avec cela, mais tout comme vous, je me réjouis de la nouvelle!
Merci Intel.
De plus, ils prouvent que Libre != gratuit-
[^]Re: Alors ca c'est du bon
Posté par Amand Tihon (page perso, ) le 25/07/2007 à 11:59. (lien). Évalué à 2.De plus, ils prouvent que Libre != gratuit
Oui, enfin, d'autres l'ont prouvé depuis longtemps déjà. Je pense par exemple à Trolltech, qui utilise pour Qt le même principe de double licence.-
[^]Re: Alors ca c'est du bon
Posté par farib () le 25/07/2007 à 12:34. (lien). Évalué à 5.Oui, enfin Trolltech a prouvé qu'on vivait et qu'on mangeait de la version commerciale et non de la version libre...
-
[^]Re: Alors ca c'est du bon
-
-
[^]Re: Alors ca c'est du bon
Posté par koyz () le 25/07/2007 à 13:00. (lien). Évalué à 3....pour Qt le même principe de double licence
Ici Intel utilise uniquement la licence GPLV2, avec une petite restriction [1] et propose un support payant, mais le code doit rester ouvert.
Alors que Trolltech propose QT sous plusieurs licences : Qt Commercial License, GPL et d’autres [2]. Dans ce cas tu payes Trolltech pour fermer ton code.
Même si ces deux modèles de financement sont intercompatibles ils sont bien différents.
[1] ...released it under the GPL v2.0 with a runtime exception (the runtime exception allows template code generated by the compiler to not be subject to the GPL). [http://www.oreillynet.com/conferences/blog/2007/07/intel_rel(...)]
[2] [http://trolltech.com/products/qt/licenses/licensing/licensin(...)]-
[^]Re: Alors ca c'est du bon
Posté par sobek () le 26/07/2007 à 06:51. (lien). Évalué à 1.Ici Intel utilise uniquement la licence GPLV2, avec une petite restriction [1]
La vision du libre par les GPListes me surprendra toujours...
Personellement, j'aurai mis "modification" ou "exception" plus que "restriction" pour traduire ce qui est en note. A croire que le GPL sans son aspect contaminant, c'est le mal absolu...
mais le code doit rester ouvert.
Heu... non, justement : tu peux mettre la license que tu veux, pas besoin que le code soit en GPL ni même ouvert. C'est justement le sens de l'exception en [1], et ça en fait un peu un intermédiaire entre GPL et LGPL...
PS: en tant que BSDiste, j'assume le mot "contaminant" qui, contrairement à "virulant" n'a pas le coté actif (et même si virulant irait à certains GPListes intaigristes ;)-
[^]Re: Alors ca c'est du bon
Posté par IsNotGood () le 26/07/2007 à 14:18. (lien). Évalué à 0.> PS: en tant que BSDiste, j'assume le mot "contaminant" qui, contrairement à "virulant" n'a pas le coté actif (et même si virulant irait à certains GPListes intaigristes ;)
Je suis un "GPListe". La GPL n'est pas contaminante ou virulante ou autre connerie venue droit du bureau de communication de MS.
Peux-tu donner un seul programme qui a été "contaminé" par la GPL ?
NON.
*BSD a beaucoup de programme sous GPL. T'as des exemples de programme qui ont été contaminés par la GPL ?
NON.-
[^]Re: Alors ca c'est du bon
Posté par lasher () le 26/07/2007 à 15:06. (lien). Évalué à 3.« *BSD a beaucoup de programme sous GPL. T'as des exemples de programme qui ont été contaminés par la GPL ? »
Si tu parles des systèmes d'exploitation BSD, tu as raison, ils embarquent aussi des softs sous GPL (GCC n'étant pas des moindres). Maintenant, c'est clairement plus parce qu'ils n'ont pas de main d'oeuvre pour faire leurs propres outils sous BSD.
make, par exemple, est fournie version BSD sur les systèmes, et est bien différenciée de gmake (qu'il faut explicitement installer).-
[^]Re: Alors ca c'est du bon
Posté par IsNotGood () le 26/07/2007 à 15:48. (lien). Évalué à 0.Je ne reproche pas à BSD d'utiliser des programmes GPL ou de faire ses propres programmes si la GPL leur sorte par les trous de nez.
Je tiens à dire que "la GPL est contaminante" est une connerie.
> Maintenant, c'est clairement plus parce qu'ils n'ont pas de main d'oeuvre
Ben Linux aussi utilise du BSD parce (peut-être, entre autre, notamment, etc) qu'ils n'ont pas assez de main d'oeuvre.
-
-
[^]Re: Alors ca c'est du bon
Posté par Xavier Teyssier (Jabber id, page perso, ) le 27/07/2007 à 14:19. (lien). Évalué à 0.La GPL n'est pas contaminante
Voyons voir.
D'après le TLFI, pour contaminant, on peut donner la définition suivante :
"Qui change la nature de quelque chose."
J'ai un bout de code que je suis en train de développer, et que je voudrais diffuser.
Je veux y insérer du code en GPL.
Comment diffuser mon code ? Obligatoirement en GPL, puisque sa licence se retrouve imposée du fait de sa cohabitation avec le code importé. J'ai donc été contaminé.
Note : je le constate froidement, comme un fait. Ce n'est absolument pas dans un sens péjoratif !-
[^]Re: Alors ca c'est du bon
Posté par François B. () le 27/07/2007 à 14:48. (lien). Évalué à 4.Tu ne choisis pas de subir une contamination ou non.
Tu choisis d'incorporer ou non du code en GPL.
Conclusion : tu ne veux pas de la GPL, n'utilise pas de code en GPL. Ce n'est pas plus compliqué que ça. Si tu as les compétences intellectuelles pour coder, tu devrais pouvoir comprendre ça !-
[^]Re: Alors ca c'est du bon
Posté par beagf (page perso, ) le 27/07/2007 à 15:46. (lien). Évalué à 6.Il faut bien distinguer deux choses :
1) L'auteur du programme _choisit_ d'utiliser du code sous licence GPL.
2) Ce choix implique _l'obligation_ de passer le programme sous licence GPL.
Le choix de l'étape 1) fait que le code sous GPL impose un changement au programme complet : un passage sous licence GPL. Donc de ce choix résulte une contamination du programme par le code sous GPL.
Il est tout à fait possible de choisir d'être contaminé, une contamination n'est pas forcément négative.
Pour une image glauque et qui vas dans le sens de microsoft, si je choisit de coucher avec une personne atteinte du SIDA, je vais être contaminé. Cette contamination est le résultat du choix fait précédament.
Ce qui est important, à mon avis, c'est que le choix soit fait en ayant toutes les informations nécéssaire. Dans le cas du SIDA si l'on est au courrant que la personne est atteinte, le choix est de ne pas ou coucher ou bien de se protéger puisque cette possibilité éxiste.
Dans le cas de l'écriture d'un programme, avant de choisir d'intégrer un code, il est nécéssaire de lire sa licence et d'accepter toutes les conséquences. Donc si le code est sous GPL, il est nécéssaire d'accepter de modifier la licence de son logiciel. Le code sous GPL contamine donc bien le logiciel hôte puisqu'il modifie une de ses caractéristiques.
Donc à mon avis le terme contaminant est tout à fait applicable et représente bien ce qui ce passe lors de l'inclusion de code sous GPL dans un autre programme. *Par contre*, et c'est un avis personnel, je n'aime pas l'utiliser car un mot ne se résume pas uniquement à sa définition. Le mot contaminant est associé principalement à la transmition d'effets négatifs tel que dans le cas de virus.
Et si l'aspect contaminant de la GPL est vu comme négative par certains, ce n'est pas mon cas. Je respecte le choix de l'auteur, et je comprend tout à fait ce choix.
C'est pour ça que plustôt que dire que la GPL est contaminante, je préfère prendre un peu de temps pour expliquer clairement le principe. Et de manière générale en expliquant simplement comment ça marche je réussit à convaincre beaucoup plus facilement et plus durable les gens que le respect des licence est quelque chose d'important et surtout quelque chose qui devrait être _normal_.
Personnellement je ne suis pas intérgiste. J'utilise principalement de logiciels libres, mais aussi quelques logiciels propriétaires. Je souhaite évidement que tous les logiciels soient libres, mais je suis réaliste et je sais que c'est actuellement impossible, et qu'il faudrat du temps avant que ça arrive. Mais par contre je suis infléxible sur le respect des licences. A partir du moment ou l'on choisit d'utiliser un logiciel sous une certaines licence, on ce doit de la respecter.-
[^]Re: Alors ca c'est du bon
Posté par reno () le 27/07/2007 à 18:42. (lien). Évalué à 3.>Il est tout à fait possible de choisir d'être contaminé, une contamination n'est pas forcément négative.
Certes, c'est un des sens possible du mot contaminé, mais ce n'est pas le sens *usuel* du mot.
Donc libre a toi d'utiliser des mots hors de leur sens usuel, mais bon pour communiquer y a mieux (a part bien sur quand on est de mauvaise foi).
Pour moi la GPL est une license d'échange de code, dans le sens ou si tu veux réutiliser le code dans ton code, tu dois donner l'acces à ton code (la BSC étant une license de don/cadeaux).-
[^]Re: Alors ca c'est du bon
Posté par Guillaume Rossignol () le 27/07/2007 à 19:39. (lien). Évalué à 1.
Le top pour communiquer serait que tout le monde utilise les définitions strictes des mots qu'ils utilisent... le sens usuel d'un mot peut enormement changer selon les personnes avec lesquels on parle (nous sommes bien placé pour le savoir... c'est quoi le sens usuel d'un logiciel libre ? un logiciel gratuit ? et l'inverse est il vrai ?)
Certes, c'est un des sens possible du mot contaminé, mais ce n'est pas le sens *usuel* du mot.
Donc libre a toi d'utiliser des mots hors de leur sens usuel, mais bon pour communiquer y a mieux (a part bien sur quand on est de mauvaise foi).-
[^]Re: Alors ca c'est du bon
Posté par reno () le 27/07/2007 à 21:47. (lien). Évalué à 2.Bof, ton argument est plutôt creux/a coté de la plaque (en Anglais je dirais que c'est un 'straw man' mais je ne connais pas la traduction exacte en Français.).
OK, certains mots sont ambigüs, mais cela n'implique pas que ce soit le cas pour 'contaminer', certes il a plusieurs sens possible mais il a quand même un sens usuel qui est très fortement négatif (c'est même marqué dans le dico)..-
[^]Re: Alors ca c'est du bon
Posté par Pierre Jarillon (page perso, ) le 28/07/2007 à 09:53. (lien). Évalué à 2.straw man = homme de paille. L'expression existe également en fraçais.
-
-
-
[^]Re: Alors ca c'est du bon
Posté par beagf (page perso, ) le 28/07/2007 à 08:26. (lien). Évalué à 1.Hum...
Tu as lu mon commentaire jusqu'au bout ? Si c'est le cas je n'ai pas du être clair. Je n'aime pas l'utilisation du terme "contaminant" pour la GPL *mais* ce terme est applicable.
Il est tout à fait possible de dire que la GPL est contaminante, par contre l'usage à donner une conotation a ce mot, et l'utiliser pour la GPL donne cette ambiance de FUD que Microsoft a voulut lancer en oubliant de préciser que la majoritée des licences propriétaires sont aussi contaminante que la GPL...
-
[^]Re: Alors ca c'est du bon
Posté par Bozo_le_clown () le 28/07/2007 à 14:09. (lien). Évalué à 1.Puisque le coté péjoratif de la contamination est toujours sujet à debat,
je propose ..... transmutante.
C'est beau comme un sous neuf, ca sonne bien
http://www.linternaute.com/dictionnaire/fr/definition/transm(...)
Qui dit mieux ?-
[^]Re: Alors ca c'est du bon
-
-
-
[^]Re: Alors ca c'est du bon
Posté par IsNotGood () le 28/07/2007 à 06:48. (lien). Évalué à 3.Il faut bien distinguer deux choses :
1) L'auteur du programme _choisit_ d'utiliser du code sous licence GPL.
2) Ce choix implique _l'obligation_ de passer le programme sous licence GPL.
Le choix de l'étape 1) fait que le code sous GPL impose un changement au programme complet : un passage sous licence GPL. Donc de ce choix résulte une contamination du programme par le code sous GPL.
Il faut bien distinguer deux choses :
1) L'auteur du programme _choisit_ d'utiliser du code sous licence proprio.
2) Ce choix implique _l'obligation_ de passer le programme sous licence proprio.
Le choix de l'étape 1) fait que le code sous licence propriétaire impose un changement au programme complet : un passage sous licence proprio. Donc de ce choix résulte une contamination du programme par le code sous licence proprio.
Dans le cas de l'écriture d'un programme, avant de choisir d'intégrer un code, il est nécéssaire de lire sa licence et d'accepter toutes les conséquences. Donc si le code est sous GPL, il est nécéssaire d'accepter de modifier la licence de son logiciel. Le code sous GPL contamine donc bien le logiciel hôte puisqu'il modifie une de ses caractéristiques.
Dans le cas de l'écriture d'un programme, avant de choisir d'intégrer un code, il est nécéssaire de lire sa licence et d'accepter toutes les conséquences. Donc si le code est sous licence proprio, il est nécéssaire d'accepter de modifier la licence de son logiciel. Le code sous licence proprio contamine donc bien le logiciel hôte puisqu'il modifie une de ses caractéristiques.
Donc à mon avis le terme contaminant est tout à fait applicable et représente bien ce qui ce passe lors de l'inclusion de code sous GPL dans un autre programme.
Donc à mon avis le terme contaminant est tout à fait applicable et représente bien ce qui ce passe lors de l'inclusion de code sous licence proprio dans un autre programme.
CQFD, la GPL n'est en rien plus contaminante que du proprio (si jamais elle est contaminante).
Réfléchissez du point de vu de la GPL et du point de vu d'une autre licence. Et dans ce cas on constate que la GPL n'a rien de contaminant.-
[^]Re: Alors ca c'est du bon
Posté par Moonz () le 28/07/2007 à 07:45. (lien). Évalué à 1.Et ? Qui a dit que le proprio n'était pas "contaminant" ?
Tu te trompes de troll, là c'est GPL vs BSD, pas GPL vs proprio-
[^]Re: Alors ca c'est du bon
Posté par IsNotGood () le 28/07/2007 à 08:04. (lien). Évalué à 2.Certaines versions de BSD ne sont pas compatibles avec la GPL. Donc, selon ta terminologie, elles sont "contaminantes".
Il n'y a pas de "contaminant" ou "viral", il y a compatible ou non. Si les licences sont compatibles, tu peux mélanger le code. Si elles ne le sont pas, il faut que tu change la licence d'un code. ET PAS FORCÉMENT PASSER LE CODE SOUS GPL ! Tu peux aussi passer ce qui est sous GPL dans la licence de l'autre.
Mais comme d'hab, vous êtes toujours dans le même scénarios. J'ai un truc (avec tous les droits) sous une licence incompatible avec la GPL et je veux incorporer du GPL.
Prend le problème dans l'autre sens :
- J'ai mon code (avec tous les droits) sous GPL et je veux incorporer du code sous une licence incompatible avec la GPL. Ben dans ce cas, t'es "obligé" d'abandonné la GPL pour prendre l'autre licence.
Les problèmes sont parfaitement symétrique et donc je ne comprend pas cet acharnement grotesque sur la GPL.-
[^]Re: Alors ca c'est du bon
Posté par lasher () le 28/07/2007 à 12:00. (lien). Évalué à 0.« Certaines versions de BSD ne sont pas compatibles avec la GPL »
Tu es sûr de toi ? À ma connaissance, mis à part la clause de publicité (donner le nom des codeurs), je ne connais pas de licence BSD impliquant de garder le logiciel sous BSD.-
[^]Re: Alors ca c'est du bon
Posté par IsNotGood () le 28/07/2007 à 17:24. (lien). Évalué à 1.> Tu es sûr de toi ?
Non et je m'en fous.
Dis que la BSD est compatible avec plus de licences que la GPL si c'est ce que tu veux dire.
Mais, par exemple, être compatible avec les brevets, autoriser les accords type MS/Novell, ne plus avoir la garantit d'accès aux sources, etc ce sont des types de compatibilité que je préfère éviter.-
[^]Re: Alors ca c'est du bon
Posté par lasher () le 28/07/2007 à 23:00. (lien). Évalué à 4.Bon, j'ai vaguement essayé de ne rien dire concernant le troll BSD Vs GPL, de savoir à qui avait la plus grosse [1]. Mais, puisque tu te fiches de dire de la merde, je t'avoue que tes arguments, où tu dis que tu te fiches de savoir si ce que tu racontes est vrai, me semblent tout à coup bien moins intéressants à lire. Que tu sois exaspéré par les commentaires de certains, et que tu répondes en conséquence, admettons ; que, pour prouver que tu as raison, tu te permettes de mentir, c'est autrement plus gênant.
[1] liberté, évidemment.
-
-
-
-
-
-
-
-
[^]Re: Alors ca c'est du bon
Posté par Guillaume Rossignol () le 27/07/2007 à 17:56. (lien). Évalué à 2.En meme temps, la nature du code que tu veux inclure est sous GPL... au départ, il ne faut pas oublier que c'est le personnes utilisant du code GPL qui voudraient changer sa nature pour en faire autre chose.
-
[+] [^]Re: Alors ca c'est du bon
Posté par IsNotGood () le 28/07/2007 à 06:41. (lien). Évalué à -2.> Je veux y insérer du code en GPL.
J'ai un code GPL et je veux insérer du proprio.
> Comment diffuser mon code ? Obligatoirement en GPL, puisque sa licence se retrouve imposée du fait de sa cohabitation avec le code importé. J'ai donc été contaminé.
Comment diffuser mon code ? Obligatoirement en proprio, puisque sa licence se retrouve imposée du fait de sa cohabitation avec le code importé. J'ai donc été contaminé.
Si la GPL est contaminance, le proprio aussi.
LA GPL N'EST PAS CONTAMINANTE !!!!
ARRÊTEZ AVEC CE FUD DE MS !!!!-
[^]Re: Alors ca c'est du bon
Posté par beagf (page perso, ) le 28/07/2007 à 08:34. (lien). Évalué à 2.> Si la GPL est contaminance, le proprio aussi.
> LA GPL N'EST PAS CONTAMINANTE !!!!
Tu saute un peu vite au conclusions...
La GPL est contaminante tout comme de nombreuses licences propriétaires.
Le FUD de Microsoft n'est pas l'utilisation du terme "contaminant" mais le fait de ne pas dire que c'est le cas de la majorité des licence, y compris celles qu'ils utilisent.-
[^]Re: Alors ca c'est du bon
Posté par IsNotGood () le 28/07/2007 à 17:28. (lien). Évalué à 0.> La GPL est contaminante tout comme de nombreuses licences propriétaires.
Sauf qu'aucune licence n'a jamais rien contaminé.
Tu peux dire contaminant pour plein plein de truc alors. Dès que deux (ou plus) accords sont incompatibles, les protocoles incompatibles, etc...
Dit incompatible au-lieu de reprendre du FUD du bureau de communcation de MS.
> Le FUD de Microsoft n'est pas l'utilisation du terme "contaminant"
Viral. Ce n'est pas mieux ni pire.
> mais le fait de ne pas dire que c'est le cas de la majorité des licence
Aucune licence n'est contaminante. Fin.
-
-
-
-
-
-
-
-
Petites précisions?
Si je comprends bien, il existe 2 versions: l'une libre (et gratuite?) incluant plus d'architectures et d'OS que la version payante (qui reste propriétaire?) mais qui fournit un support d'un an?
Il semblerait qu'il y ait un léger cafouillage à ce niveau-là, non? Car la news met en opposition une version commerciale et une version libre.
-
[^]Re: Petites précisions?
Posté par patrick_g (page perso, ) le 25/07/2007 à 10:17. (lien). Évalué à 10.Ben la version commerciale vend du support donc elle restreint l'éventail des configurations qui sont supportées. La version libre elle n'a pas cette contrainte donc elle supporte bien plus de trucs.
-
[^]Re: Petites précisions?
Posté par Damien Cassou () le 25/07/2007 à 10:44. (lien). Évalué à 1.C'est aussi comme cela que je l'ai compris.
--
Damien Cassou
-
[^]Re: Petites précisions?
Posté par xander_1 () le 25/07/2007 à 11:43. (lien). Évalué à 5.Si j'ai bien retenu les concepts :
La licence GPL étant contaminante, tout programme utilisant TBB avec la licence libre devra aussi être livré en licence GPL.
Pour fournir le programme sous une autre licence il faut utiliser la licence commerciale.
Sauf erreur c'est la même chose avec QT.-
[^]Re: Petites précisions?
Posté par zimmermann jérémie (page perso, ) le 25/07/2007 à 11:58. (lien). Évalué à 8.il y a un léger problème sémantique dans ce que tu dis :
- le terme "contaminant" est un terme de propagande utilisé pour répandre du FUD sur le libre et la licence GPL. Il est d'ailleurs absurde, vu que quelque chose de "contaminant" est actif (comme un agent infectieux), alors que la licence est passive, vu que ce sont ses utilisateurs qui choississent ou non de l'employer.
- on pourrait dire que la GPL est "prophylactique" car elle protège les libertés en empêchant à ses utilisateurs de les restreindre pour les utilisateurs successifs.
- en réalité la GPL interdit à quiconque d'utiliser le code source et le logiciel qu'elle protège à partir du moment ou cette personne ne souhaite pas respecter les libertés d'autrui.
- tout programme intégrant tout ou partie des sources de TBB devra être sous licence GPL, sinon son auteur perdra le droit de bénéficier des 4 libertés accordées par la licence.
- tout programmeur souhaitant ne pas accorder ces 4 libertés à tout le monde sur son programme est libre si j'ai bien compris, d'acheter la version commerciale de TBB.
-
[^]Re: Petites précisions?
Posté par CrEv (page perso, ) le 25/07/2007 à 12:23. (lien). Évalué à 10.- en réalité la GPL interdit à quiconque d'utiliser le code source et le logiciel qu'elle protège à partir du moment ou cette personne ne souhaite pas respecter les libertés d'autrui.
en réalité non...
Ceci est valable à partir du moment ou cette personne ne souhaite pas respecter la GPL et c'est tout.
GPL != "libertés d'autrui"
D'ailleurs c'est bien pour ça que les BSD existent par exemple...
Faut pas oublier une chose :
GPL != libre
il y a de multiples définitions de libre, et respecter les libertés d'autrui ne permet pas nécessairement de respecter la gpl...
-
-
[^]Re: Petites précisions?
Posté par François B. () le 25/07/2007 à 11:59. (lien). Évalué à 1.s/contaminante/curative/
Simple question de point de vue (et à mon avis de bon sens, mais ça se discute).
-
[^]Re: Petites précisions?
Posté par Dinofly (page perso, ) le 25/07/2007 à 12:12. (lien). Évalué à 5.La licence GPL étant contaminante
Il faudrait éviter ce mot qui fait penser à un virus et qui joue le jeu des détracteurs de la GPL. Héréditaire est le mot "officiel" de la FSF je crois.--
Je connais bien l'algèbre de Boole, et j'ai même vu tous ses flims.-
[^]Re: Petites précisions?
Posté par baud123 (Jabber id, page perso, ) le 25/07/2007 à 12:36. (lien). Évalué à 2.vaccin c'est pas mal aussi : c'est choisir la liberté. Le virus tu ne choisis effectivement pas de l'attraper, c'est insidieux ; se faire vacciner c'est une attitude active et un choix fait en toute conscience.
-
-
[^]Re: Petites précisions?
Posté par reno () le 25/07/2007 à 12:37. (lien). Évalué à 5.Primo, le terme contaminant/viral est péjoratif, en plus d'être incorrect (j'aimerai que les vrai virus me laisse le choix de les utiliser ou pas comme le fait la GPL).
Secondo, TBB sera disponible sous GPLv2+linking exception (la même license qu'utilise libstd++) et donc pas de problème pour son utilisation par du code propriétaire.
Qt est en GPLv2 classique lui.-
[^]Re: Petites précisions?
Posté par Pierre Jarillon (page perso, ) le 26/07/2007 à 07:58. (lien). Évalué à 7.Plutôt que contaminant ou viral, je préfère associer l'idée de fécondité. Le mot héréditaire convient car il implique une ascendance féconde.
Un programme sous GPL peut toujours avoir une descendance car son code est toujours disponible.
A contrario, la licence BSD permet d'inclure le code dans des logiciels fermés, donc sans descendance. Elle a d'autres avantages mais elle conduit souvent à la stérilité. Je la compare souvent à l'élevage des mulets dans le Poitou : Le mulet est fort comme un cheval, intelligent comme un âne, mais il est stérile.-
[^]Re: Petites précisions?
-
-
-
-
G5
il me semble que TBB ne supporte pas encore les cpu non intel tels que les G5 (c'est logique en même temps)
-
[^]Re: G5
Posté par Troy McClure (page perso, ) le 25/07/2007 à 11:19. (lien). Évalué à 3.je pense que j'ai dit une connerie, si la version macos n'utilise que les fonctions bas-niveau de Darwin, sans assembleur maison, alors il n'y a pas de raison que ça ne fonctionne pas sur G5.
-
[^]Re: G5
Posté par scls19fr (page perso, ) le 25/07/2007 à 11:47. (lien). Évalué à 2.Bonjour,
Par contre il n'est pas indiqué si ce genre de lib supporte aussi les processeurs utilisés dans l'embarqué (genre ARM, SuperH...)
En effet, si à priori, l'annonce est très intéressante, il faut bien aussi voir que si cette lib est abondamment utilisée (pour des questions d'efficacité, de facilité...) elle pourrait aussi risquer d'empêcher de porter vers des systèmes embarqués (et donc avec architecture exotique) l'ensemble des logiciels l'utilisant...
Je ne suis pas spécialiste... mais je me pose quand même ce genre de question car le marché de l'embarqué augmente pas mal... Intel assure l'interopérabilté avec d'autres processeur pour le deskop... car ils savent bien que l'enjeu n'est peut-être plus là...
@+-
[^]Re: G5
Posté par kowalsky () le 25/07/2007 à 11:57. (lien). Évalué à 4.Reel question :
Il y a beaucoup d'embarqué multiprocesseur...?-
[^]Re: G5
Posté par reno () le 25/07/2007 à 12:41. (lien). Évalué à 7.Bin ça dépend de ce que tu entends par multiprocesseur..
Au sens propre: multi == plusieurs, dans ce cas la oui, il y a beaucoup d'embarqué avec plusieurs processeurs: le iPhone a 3 ARM par exemple.
Maintenant des multiprocesseurs SMP, il doit pas y en avoir beaucoup dans l'embarqué non.
-
-
[^]Re: G5
Posté par patrick_g (page perso, ) le 25/07/2007 à 12:00. (lien). Évalué à 4.>>> Intel assure l'interopérabilté avec d'autres processeur pour le deskop... car ils savent bien que l'enjeu n'est peut-être plus là
Ce qui est important c'est le passage en GPL.
Si il y a un besoin réel dans l'embarqué et qu'Intel ne veut pas y répondre alors les développeurs du monde libre auront la possibilité d'améliorer TBB pour répondre à ce besoin.
-
-
Multicoeur ?
Multicoeur c'est du multi-cpu. Au niveau appli/programmation on ne voit pas la différence.
> le défi est bien entendu d'arriver à programmer efficacement pour ces nouvelles architectures, ce qui s'est révélé très difficile et réservé à une élite de codeurs.
C'est vrai que coder en multi-thread est très très casse couille. Ce n'est pas l'utilisation de nptl ou autre qui est casse couille. Le programme devient très compliqué (et très "fragile") dès qu'il passe en multi-thread pour tirer profit d'une architecture multi-cpu.
L'intérêt de TBB est surtout pour le portage. Mais il doit bien exister des librairies thread qui sont portables. Glib ? GnuPthread ? Je ne dis pas ça pour retirer les mérites de TBB que je ne connais pas.
-
[^]Re: Multicoeur ?
Posté par Troy McClure (page perso, ) le 25/07/2007 à 12:05. (lien). Évalué à 8.Si tu regardes la doc tu verras que tbb est de bien plus haut niveau qu'une bete abstraction des pthreads/winthreads, c'est très orienté algorithmes (parallel_for etc, ça c'est comme openmp) et conteneurs thread-safe (queue lock-free , etc là dessus openmp ne propose rien)
en cherchant sur google je suis tombé sur ce post d'un des auteurs, pas ininteressant:
http://groups.google.com/group/comp.lang.c++.moderated/msg/9(...)-
[^]Re: Multicoeur ?
Posté par patrick_g (page perso, ) le 25/07/2007 à 12:15. (lien). Évalué à 6.y'a aussi ces deux articles qui ont l'air pas mal pour se faire une idée :
http://www.devx.com/cplus/Article/33334
http://www.devx.com/go-parallel/Article/34951-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 25/07/2007 à 12:46. (lien). Évalué à 4.enfin ils me semblent quand meme orientés les articles.
le premier il prend comme exemple que map est pas thread_safe. Soit.
Donc il essaie de mettre un mutex win32 ou une section critique win32 (je connais pas trop la différence, ne codant pas sous win32).
Mais on ne sait pas ce qu'il fait , il les met comment ses mutex ? ou?
Sans compter qu'il explique que les mutex win32 sont partagé entre les processus !, ce qui ressemble plus a des semaphores nommés qu'a des mutex la.
Je dis pas que les TBB ne sont pas bien, je n'en sais rien (et je pense qu'ils sont bien), mais les articles ne sont pas forcément très clair non plus.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par pasBill pasGates () le 26/07/2007 à 05:48. (lien). Évalué à 6.Sans compter qu'il explique que les mutex win32 sont partagé entre les processus !, ce qui ressemble plus a des semaphores nommés qu'a des mutex la.
Il a raison, il y a plusieurs primitives de synchro differentes sous Windows :
- Mutex
- Semaphore
- Timer
- Event
- Critical Section (c'est un mutex tres tres rapide mais c'est pas utilisables par plusieurs processus, uniquement threads d'un meme processus)
Tu peux meme synchroniser sur un thread, job ou un processus si tu veux (tu bloques jusqu'a ce qu'il se termine)
La difference entre un mutex et un semaphore c'est qu'un semaphore a un compteur associe et que des threads peuvent :
- incrementer le compteur et bloquer si le compteur est a une valeur >= X
- decrementer le compteur et bloquer si le compteur est a 0
alors qu'un mutex c'est en gros un semaphore dont la limite superieure(X) est 1
Mutex/Semaphore/Event/Timer peuvent etre nommes ou pas-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 26/07/2007 à 07:29. (lien). Évalué à 2.alors qu'un mutex c'est en gros un semaphore dont la limite superieure(X) est 1
Mais le mutex win32 permet il de libérer une section critique si on est pas le thread/process appellant ?
Parce que c'est ca aussi la grande force des semaphores posix par rapport aux mutex posix.
Question subsidiaire.
Les mutex windows peuvent ils être récursifs ?--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 26/07/2007 à 14:44. (lien). Évalué à 2.> Mais le mutex win32 permet il de libérer une section critique si on est pas le thread/process appellant ?
Peut-être, je n'ai jamais essayé. Mais le faire montre une erreur de conception à mon sens.
Win32 a mutex et critical section. Sous Linux, les deux sont la même chose (du moins s'utilise avec la même API). Un critical section sous Linux est un mutex "intra-process" (si j'ai bonne mémoire, les mutex sous Linux sont par défaut équivalent aux critical section de Windows).
> Parce que c'est ca aussi la grande force des semaphores posix par rapport aux mutex posix.
Libérer un mutex ou semaphore par une thread qui ne l'a pas acqui est généralement une erreur ou signe d'un conception "pas terrible". Ça peut être utile pour les cas d'erreur en inter-process (par exemple le process qui a pris le mutex est mort suite à une erreur et donc ne va pas le libérer). Il y a peut-être d'autre cas où c'est pratique, mais je préfère éviter cette pratique.-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 26/07/2007 à 19:43. (lien). Évalué à 3.(si j'ai bonne mémoire, les mutex sous Linux sont par défaut équivalent aux critical section de Windows).
Les mutex pthreads sont en tout cas extrêmement optimisé (bout écrit en asm itou itou itou).
Il y a aussi les futex (fast mutex) mais j'ai jamais touché.
Mais le faire montre une erreur de conception à mon sens.
Ben si tu n'as pas de sémaphore, tu fait comment ?
Libérer un mutex ou semaphore par une thread qui ne l'a pas acqui est généralement une erreur ou signe d'un conception "pas terrible".
Question de point de vue.
Tu as un pool d'utilisateur, par exemple 100.
Chaque utilisateur fait quelquechose.
Tu injecte un utilisateur tant que tu es inférieur à 100, et si tu atteint 100, tu attend qu'un parte.
Alors tu peux t'amuser à le faire avec des conditions et un compteur a coté mais bon, mais ca va etre assez lourd a gerer quand meme, et plus lent qu'avec un sémaphore. Et surtout ne vas pas régler le probleme que tu as soulevé : tu ne sera plus à 100 si un client "oublie" de lancer le signal quand il quitte la condition.
(par exemple le process qui a pris le mutex est mort suite à une erreur et donc ne va pas le libérer).
Enfin la ton mutex il est mort meme si il n'est pas appelable par un autre thread que l'appelant, donc tu es en deadlock.
A toi de vérifier tes critical section aussi.
tu voulais peut etre dire 'le process qui devait le libérer est mort' , et encore une fois tu es en section critique dans ce cas, c'est a TOI de coder pour qu'il n'y ait pas de deadlock. C'est vrai meme avec un mutex (cf plus haut)).--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par pasBill pasGates () le 26/07/2007 à 20:48. (lien). Évalué à 2.Le probleme d'essayer de releaser une section critique avec un Mutex (ou l'inverse) c'est qu'ils n'ont pas le meme objectif et ne fonctionnent pas de la meme maniere.
Une section critique c'est 3 choses :
a) une structure de donnees avec plusieurs champs
b) un spin lock pendant un nombre d'iterations determine (changeable par l'utilisateur)
c) Si apres la fin du spin lock, la region est toujours lockee, alloue un semaphore et bloque dessus
Alors qu'un mutex, ben... c'est un mutex(semaphore idem c'est pas le probleme).
T'as des cas ou la section critique est lockee, et il n'y a pas de semaphore, resultat ben tu peux pas relacher un semaphore qui n'existe pas, tout ce que tu peux relacher c'est une section critique.
Quand a la raison pour laquelle tu peux pas l'utiliser pour synchroniser plusieurs processus, c'est simplement que c'est une structure de donnees dans l'espace d'addressage du processus qui l'a allouee, bref un autre processus n'y aura pas acces.-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 26/07/2007 à 21:33. (lien). Évalué à 1.je parlais de section critique au sens "section d'exécution atomique". C'est à dire accès à une ressource partagée de façon protégée.
Je pense que la tu parle de la 'critical section' de windows, non ?--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par pasBill pasGates () le 26/07/2007 à 21:43. (lien). Évalué à 4.Ben oui, "section critique" et "critical section" c'est un peu la meme chose une fois traduit :)
-
-
-
-
[^]Re: Multicoeur ?
Posté par Laurent Pointal (page perso, ) le 27/07/2007 à 11:03. (lien). Évalué à 4.Libérer un mutex ou semaphore par une thread qui ne l'a pas acqui est généralement une erreur ou signe d'un conception "pas terrible".
D'accord pour les mutexs, qui protègent des éléments de possibles accès concurrents, c'est le thread qui a pris la ressource qui doit la libérer.
Mais pas d'accord pour les sémaphores. Il est courant dans les algos de les utiliser comme des compteurs de ressources dans des cadres producteur/consomateur, et dans ce cas le thread qui fait un P() n'est généralement pas celui qui a fait un V().-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 28/07/2007 à 07:00. (lien). Évalué à 1.> Mais pas d'accord pour les sémaphores. Il est courant dans les algos de les utiliser comme des compteurs de ressources dans des cadres producteur/consomateur, et dans ce cas le thread qui fait un P() n'est généralement pas celui qui a fait un V().
Pas d'accord. C'est généralement le même thread qui fait un GetSemephore (ou équivalent en fonction de l'api) et un ReleaseSemaphore. Forcément.
Le thread prend/demande la ressource, il fait GetSemaphore. Il libère la ressource, il fait ReleaseSemaphore. Il n'y a que le thread qui sait quand il n'a plus besoin de la ressource.
> D'accord pour les mutexs, qui protègent des éléments de possibles accès concurrents
Par forcément.
- Thread 1 prend un lock et lance Thread 2 qui fait le traitement.
- plus tard Thread 1 demande encore le lock mais ne l'obtient que lorsque Thead 2 l'a libéré (une fois qu'il a fini son traitement).
Tu peux avoir la même chose avec un semaphore. Mais un semaphore c'est surtout pour des ressources, pour signaler que tu utilises une ressource. Tu peux utiliser un lock (en général 2) pour synchroniser des threads (et non seulement que protéger des données). Mais en général, c'est à éviter (il est plus clean d'utiliser les signaux ou event). Mais les locks sont extrêmement rapides.-
[^]Re: Multicoeur ?
Posté par Thomas Gueze () le 28/07/2007 à 09:09. (lien). Évalué à 3.Sauf que pour les producteurs/consommateurs, il y a les consommateurs qui veulent prendre et consommer les ressources, et les producteurs qui produisent des ressources.
On arrive donc à des cas, ou des consommateurs sont bloqué car il n'y a plus de ressources (ils font bien le getSemaphore) et lorsqu'un producteur produit une ressource, il effectue un releaseSemaphore pour signaler qu'il a déposé une ressource prête à être consommé.
L'utilisations des sémaphores dépend du cadre ou tu te place.
-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 28/07/2007 à 15:46. (lien). Évalué à 3.Pas d'accord. C'est généralement le même thread qui fait un GetSemephore (ou équivalent en fonction de l'api) et un ReleaseSemaphore. Forcément.
Le thread prend/demande la ressource, il fait GetSemaphore. Il libère la ressource, il fait ReleaseSemaphore. Il n'y a que le thread qui sait quand il n'a plus besoin de la ressource.
Dans ce cas il a pas besoin d'un semaphore mais d'un mutex.
Et la on parle d'un semaphore.
- Thread 1 prend un lock et lance Thread 2 qui fait le traitement.
- plus tard Thread 1 demande encore le lock mais ne l'obtient que lorsque Thead 2 l'a libéré (une fois qu'il a fini son traitement).
Dans ce cas
1°) tu attend que thread 2 a fini avec un join
2°) tu utilise des conditions qui sont tres bien pour ca
3°) ...
Mais un semaphore c'est surtout pour des ressources, pour signaler que tu utilises une ressource. Tu peux utiliser un lock (en général 2) pour synchroniser des threads (et non seulement que protéger des données).
Un sémaphore est une généralisation d'un lock exclusif, mais lui c'est que pour les données (en réalité pas du tout, mais dans ton mode de programmation threadé visiblement si). mais pas le lock exclusif?
Un semaphore laisse n processus accéder a une ressource. Si n>1, tu empeche aucun probleme de race condition, donc c'est des merdes pour l'accés en tant que tel a des ressources exclusives.
Ensuite pour la synchronisation il existe des truc comme barrier par exemple...--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
[^]Re: Multicoeur ?
Posté par Laurent Pointal (page perso, ) le 28/07/2007 à 17:35. (lien). Évalué à 0.Je crois que tu devrais aller faire les cours du CNAM à la place de Kaiser...
-
[^]Re: Multicoeur ?
Posté par Laurent Pointal (page perso, ) le 29/07/2007 à 17:54. (lien). Évalué à 3.Compteur à zéro... quelqu'un ne connais pas...
http://deptinfo.cnam.fr/Enseignement/CycleProbatoire/SRI/Sys(...)
Pour IsNoGood, la lecture de la page du Wikipedia sur les sémaphores devrait permettre de corriger certaines erreurs (tout le monde peut se tromper) http://fr.wikipedia.org/wiki/S%C3%A9maphore_%28informatique%(...)
Et il y a sûrement d'autres sites avec des infos correctes.-
[^]Re: Multicoeur ?
Posté par Laurent Pointal (page perso, ) le 29/07/2007 à 17:57. (lien). Évalué à 2.J'oubliais, sur Kaiser: http://cedric.cnam.fr/~claude/
-
-
-
-
-
-
[^]Re: Multicoeur ?
Posté par pasBill pasGates () le 26/07/2007 à 16:41. (lien). Évalué à 2.Non le mutex Win32 ne le permet pas, pour la simple et bonne raison que ce ne sont pas les memes elements et que comme IsNotGood l'a dit cela signifie qu'il y a un bug dans le code.
Sinon oui ils peuvent etre recursifs.-
[^]Re: Multicoeur ?
Posté par Bozo_le_clown () le 28/07/2007 à 14:19. (lien). Évalué à 3.IsNotGood et pBpG sont d'accord sur un point.
Mes très chères moules, nous assistons à un moment d'anthologie DLFPienne.-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 28/07/2007 à 17:39. (lien). Évalué à 1.J'attend avec délice que pBpG dise que le besoin d'un anti-virus sur un OS est la preuve d'un OS mal foutu et non de sa popularité.
Un mec de chez MS a dit que peut-être les prochaines versions de Windows ne nécessiterons pas d'anti-virus (comme Linux). Ce jour la, pBpG sera dans la merde. Enfin, pas vraiment dans la merde. Il dira la même chose que MS.-
[^]Re: Multicoeur ?
Posté par pasBill pasGates () le 29/07/2007 à 19:52. (lien). Évalué à 1.J'attend avec délice que pBpG dise que le besoin d'un anti-virus sur un OS est la preuve d'un OS mal foutu et non de sa popularité.
Oh mais je suis 100% d'accord avec cette phrase.
Le truc c'est que Windows n'a pas besoin d'anti-virus.
-
-
-
-
-
-
-
-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 25/07/2007 à 14:35. (lien). Évalué à 3.> Si tu regardes la doc tu verras que tbb est de bien plus haut niveau qu'une bete abstraction des pthreads/winthreads
Admettons. Mais quand je programme en multi-thread, le problème de l'utilisation de nptl ou le "truc" windows est mineur par rapport à déterminer ce qui doit être locké (protégé), les fifo, rechercher les conditions de deadlock, utiliser un semaphore ou seulement un lock, quand mettre un signal, etc... Surtout si on veut profité à plein d'un système multi-cpu. Mettre un gros lock qui sérialise tout est une solution de facilité.
Et ça TBB ne t'aide pas. C'est à toi de faire tourner ton cerveau.
> parallel_for etc
Ce qui est bien si ce qui est lancé est déjà thread-safe. Le plus dure est de rendre les choses thread-safe (et efficace dans un contexte multi-cpu). C'est un défit à donner des maux de tête (oui, oui).-
[^]Re: Multicoeur ?
Posté par Troy McClure (page perso, ) le 25/07/2007 à 15:40. (lien). Évalué à 5.> Mettre un gros lock qui sérialise tout est une solution de facilité.
Et ça TBB ne t'aide pas. C'est à toi de faire tourner ton cerveau.
Ben si, tbb t'aide. Regarde la doc. ça fait la répartition de charge en gardant un nombre de threads égal au nb de cores, ça propose des structures de données thread-safe qui sont notoirement très difficiles à mettre au point en restant efficaces et scalables et non buguées. ça répond très clairement à un besoin, peut être pas le tien, mais celui de beaucoup de gens. Entre autres tous ceux qui se paluchent sur openmp.-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 25/07/2007 à 16:15. (lien). Évalué à 0.> ça fait la répartition de charge en gardant un nombre de threads égal au nb de cores
C'est bien pour des trucs mathématiques, etc. Des trucs qui se parallélise bien (voire "à l'infini"). Des trucs avec peu de dépendances entre eux. Mais il y a des "trucs" qui demandent 3 threads (et pas plus). Tu ne peux pas tout paralléliser "à l'infini".
> ça propose des structures de données thread-safe
Ça c'est cool.
> ça répond très clairement à un besoin
Je n'ai pas dit que ça ne servait à rien !
Code une applie multi-thread optimisée aux petits oignons pour utiliser à fond du multi-cpu et tu vas comprendre comme c'est hard et difficilement généralisable. Actuellement je fais un programme pour de la vidéo (temps-réel) et c'est un enfer. L'enfer ce n'est pas de mettre un lock ou un signal ici ou là. C'est de savoir où le mettre et s'il faut le mettre. C'est la conception qui est prise de tête, la réalisation est moins prise de tête (il faut coder "comme d'hab"). TBB semble aider à la réalisation. C'est toujours ça de pris. Il y des applis qui se parallélisent bien. Certains calculs mathématiques, les serveurs, etc...
Par exemple pour un serveur avec x clients, tu vas avoir x threads. Et s'il y a deux fois plus de clients, tu as deux fois plus threads. Si tu ne veux pas faire écrouler la bécane avec des milliers de thread, tu mets des clients en attente (pool) et ne fait tourner que le nombre de thread qui correspond au nombre de cpu (ça permet aussi de profiter des spinlock et d'éviter des appels système). Ce type de besoin est assez générique et TBB semble y répondre. Comme make peut faire tourner plusieurs compilations à la fois par exemple. Mais il y a d'autres domaines très dificile. Va par exemple multi-threader Firefox pour que Firefox ne semble pas "freezer" lorsqu'il calcule une page (genre une dépêche linuxfr avec pleins de commentaires). Pour que les menus soit toujours dispos, qu'on puisse se promener dans les tab et les lire alors qu'il calcul le rendu d'une grosse dépêche linuxfr.
Bonne chance :-) Avec TBB ou non.-
[^]Re: Multicoeur ?
Posté par windu.2b (Jabber id, page perso, ) le 25/07/2007 à 17:03. (lien). Évalué à 3.Ben, dans le cas de Fx, le rendu des menus et le fait qu'ils soient dispos est indépendant du rendu d'une page HTML, non?
de-même, le rendu d'une page est indépendant du rendu de la page dans l'onglet d'à coté... Donc ça devrait être assez facilement parallélisable.
À moins que des notions ne m'aient échappé...
En tout cas, ça n'a pas l'air d'être très parallélisé actuellement :-/-
[^]Re: Multicoeur ?
Posté par reno () le 25/07/2007 à 18:14. (lien). Évalué à 3.D'accord avec toi: les applications multi-tab comme FF devraient être très facilement parallélisable: une thread pour le rendu de la "fenetre mère" qui contient les menus et d'autre thread pour le contenu des onglets.
J'ai du mal a comprendre pourquoi il ne l'est pas..
-
-
-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 25/07/2007 à 19:06. (lien). Évalué à 2.oui mais non.
Pour la répartition de charge:
Tu peux vouloir faire plus de thread que le nombre de core : une programmation threader 'normal' (on utilisait des threads avant l'avènement des multi coeur ;)) tout en restant avec une perf proche de l'optimal.
Il existe des librairies de threads dites MxN qui font déja ca avec des pthreads ou autres. Certaines librairies permettent meme un interfacage avec MPI (mpd) pour augmenter encore le parallélisme disponible.
Ensuite les librairies MxN ont déja été utilisé dans des systeme en production autre que des supercalculateur. C'est le cas de solaris 9 par exemple.
Mais pour la nptl il a été jugé que l'apport d'une librairie NPTL n'était pas forcément pertinnent pour une utilisation 'classique' (non hpc), et sont donc en 1x1.
Pour les structures de données thread safe, c'est toujours bon a prendre , mais je ne suis pas assez calé pour en parler plus en avant ;)
ça répond très clairement à un besoin, peut être pas le tien, mais celui de beaucoup de gens. Entre autres tous ceux qui se paluchent sur openmp.
Sont un peu maso quand meme pour openmp. autant partir sur du c et du pthread, parce que openmp je trouve ca assez porc, définir des macros etc...
Mais visiblement tbb ca fait openmp en mieux et en moins porc ;)
Moi ce que je trouvais particulièrement intéressant c'était le thread checker par exemple.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par lasher () le 26/07/2007 à 10:03. (lien). Évalué à 2.« Sont un peu maso quand meme pour openmp. autant partir sur du c et du pthread, parce que openmp je trouve ca assez porc, définir des macros etc... »
Sauf que la notion de thread en FORTRAN, ben ... Elle n'existe pas. D'où le besoin de machins genre OpenMP pour rajouter du parallélisme explicite à un langage qui ne connaît pas ça officiellement.
De plus, en utilisant les pragma en C ou les commentaires correspondants en FORTRAN, tu permets au compilateur de faire tout plein d'analyses en statique (pour peu que le compilateur sache en tirer parti, ce qui n'est pas du tout évident).-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 26/07/2007 à 19:45. (lien). Évalué à 0.Qu'il y ait des raisons ne change pas le fait que je trouve ca porc.
C'est idiot je sais :D--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par lasher () le 26/07/2007 à 21:57. (lien). Évalué à 3.Dans le principe, si le langage pouvait inclure la notion de parallélisme ce serait évidemment mieux.
Après tout dépend du but. Dans le cas de « bêtes » sections parallèles, avec un modèle à la fork/join (comme pour OpenMP), du moment que cette section prend du temps et nécessite réellement du calcul avec des dépendances « lourdes » (qui nécessitent de la synchronisation), alors oui, pourquoi pas.
Mais dans le cas où tu peux t'arranger pour qu'il n'y ai pas de synchro ou presque (par exemple parce que tu peux évaluer - statiquement ou au lancement du programme - le nombre d'opérations qui vont être effectuées, à 0,1% près), et qu'en plus, tu dois absolument aller vite, il ne te reste plus que des langages type C, ou FORTRAN (OCAML me vient aussi à l'esprit, mais je n'ai pas l'impression qu'il y ait de vraies constructions pour le parallélisme dans le langage), car malheureusement, dans la plupart des papiers parlant de parallélisme que j'ai pu voir (et c'est aussi vrai pour les implémentations classiques d'OpenMP), il y a toujours des synchro lourdes dans le cas de déclarations plus ou moins explicites de sections parallèles.
Du coup, il va falloir que je teste un chouilla TBB, mais je pense que ça ne s'interfacera pas trop avec MPC ... :-)-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 27/07/2007 à 07:13. (lien). Évalué à 2.ype C, ou FORTRAN (OCAML me vient aussi à l'esprit, mais je n'ai pas l'impression qu'il y ait de vraies constructions pour le parallélisme dans le langage), car malheureusement, dans la plupart des papiers parlant de parallélisme que j'ai pu voir (et c'est aussi vrai pour les implémentations classiques d'OpenMP), il y a toujours des synchro lourdes dans le cas de déclarations plus ou moins explicites de sections parallèles.
Et erlang ?--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
-
-
-
-
-
-
-
[^]Re: Multicoeur ?
Posté par loufoque () le 25/07/2007 à 20:53. (lien). Évalué à 1.Admettons. Mais quand je programme en multi-thread, le problème de l'utilisation de nptl ou le "truc" windows est mineur par rapport à déterminer ce qui doit être locké (protégé), les fifo, rechercher les conditions de deadlock, utiliser un semaphore ou seulement un lock, quand mettre un signal, etc... Surtout si on veut profité à plein d'un système multi-cpu. Mettre un gros lock qui sérialise tout est une solution de facilité.
Et ça TBB ne t'aide pas. C'est à toi de faire tourner ton cerveau.
Chacun sait que les verrous sont une mauvaise façon de gérer la concurrence.
Utilise plutôt du message passing.-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 25/07/2007 à 22:30. (lien). Évalué à 2.> Chacun sait que les verrous sont une mauvaise façon de gérer la concurrence.
> Utilise plutôt du message passing.
Les deux ont leur intérêt. J'utilise lock (ou mutex), semaphore et signal (pthread_cond_wait pthread_cond_signal par exemple). Chaqu'un a son intérêt bien spécifique. Un signal ne peut remplacer un semaphore ou un lock, un lock ne peut remplacer un semphore ou un signal, etc, etc...
A moins de coder comme un porc avec des boucles de ce type :
while (!condition) {
sleep(1) ;
}
mutex/semaphore/signal sont indispensables.
Je suis sûr que "message passing" doit utiliser un lock ou un semaphore.
En passant, un mutex (ou section critique sous Windows) ça ne bouffe rien si le nombre de thread actif est inférieur ou égal au nombre de cpu/core. Il n'y a même pas un appel système de fait (donc on reste en userland). C'est redoutablement efficace.-
[^]Re: Multicoeur ?
Posté par lasher () le 26/07/2007 à 11:17. (lien). Évalué à 2.« Je suis sûr que "message passing" doit utiliser un lock ou un semaphore. »
C'est vrai, mais c'est laissé au soin de l'implémentation d'une part, et souvent ça utilise les mécanismes matériels mis à disposition d'autre part. Sachant que le passage de message peut se faire en synchrone ou asynchrone.
« En passant, un mutex (ou section critique sous Windows) ça ne bouffe rien si le nombre de thread actif est inférieur ou égal au nombre de cpu/core. »
Euh, tu es sûr de ton coup là ?
De ce que j'avais compris, l'utilisation de mutex te soumet potentiellement à un changement de contexte, quel que soit le nombre de processeurs actif. Je peux me tromper bien sûr.
De plus, dans un contexte plus restreint (le calcul haute performance, où les entrées/sorties sont rares), synchroniser comme un malade est souvent synonyme de mauvaises performances.-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 26/07/2007 à 15:30. (lien). Évalué à 0.> De ce que j'avais compris, l'utilisation de mutex te soumet potentiellement à un changement de contexte, quel que soit le nombre de processeurs actif. Je peux me tromper bien sûr.
"Te soumet potentiellement à un changement de contexte" est vrai.
Mais dans quel cas ?
Il y a changement de contexte s'il n'y a pas assez de cpu (le cpu est alors affecté à un autre thread qui en a besoin). On est dans le cas où il n'y a moins de cpu que de threads actifs/éligibles et au-lieu de laisser un cpu en attende d'un lock, on l'affecte à un autre thread.
Il y a aussi changement de contexte si le thread reste longtemps (c'est très court :-)) en attente du lock. Dans ce cas le thread passe en sommeil et sera réveillé plus tard. On est dans le cas où il n'y a rien à faire pour ce thread/cpu. On ne manque pas de cpu (en nombre, pas forcément en puissance puisqu'on peut attendre le traitement d'un autre cpu). Dans ce cas passer le thread en mode sommeil (et probablement le cpu qui l'exécutait) permet d'économiser de l'énergie. Ceci sans que les performances en souffre ou alors que très faiblement. Le thread qui était en attente (et n'avait rien à faire) sera réveillé un peu moins vite.
Il faut noter qu'on peut faire typiquement des milliers de lock à la second dans une appli multi-threadé. En général il n'y a qu'un faible pourcentage de ces locks qui demande un changement de contexte (si on a un nombre de cpu adapté à l'appli).
Plus techniquement (mais en très simplifié) un mutex fait en premier :
while (!ma_condition && ++compteur < boucle_attente) ;
Si le thread/cpu sort de la boucle et que ma_condition est vrai, il continue, sinon il passe en sommeil et l'OS le réveillera lorsque ma_condition devient vrai.-
[^]Re: Multicoeur ?
Posté par lasher () le 26/07/2007 à 15:46. (lien). Évalué à 2.« Il y a changement de contexte s'il n'y a pas assez de cpu (le cpu est alors affecté à un autre thread qui en a besoin). On est dans le cas où il n'y a moins de cpu que de threads actifs/éligibles et au-lieu de laisser un cpu en attende d'un lock, on l'affecte à un autre thread. »
Je suis un peu sceptique. J'ai déjà eu le cas d'un processus (pas d'un thread, nous sommes bien d'accord) qui était migré d'un coeur à un autre, sans autre raison que l'ordonnanceur l'avait décidé (tu comprends, un coeur travaillait à 100%, pas l'autre, alors forcément, l'ordonnanceur a voulu donner du boulot à ce dernier ...). Du coup je me demande si ce genre de comportement ne peut pas se reproduire -- mais bien évidemment, c'est plus ou moins indépendant du fait qu'on manipule un mutex ou non.-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 26/07/2007 à 17:38. (lien). Évalué à 0.> J'ai déjà eu le cas d'un processus (pas d'un thread, nous sommes bien d'accord) qui était migré d'un coeur à un autre
Ce n'est pas très claire. Un processus n'est pas un thread, c'est un environnement (mémoire, variable d'environnement, etc). Un processus a par défaut un thread (celui qui excécute main()). Un processus n'est pas attaché à un cpu pour la bonne raison qu'un processus peut avoir plusieurs threads.
Par exemple :
processus : toto avec 2 thread.
thread 1 de toto : s'exécute sur le premier cpu
thread 2 de toto : s'exécute sur le second cpu
A quel cpu est attaché le processus ? Aucun.
Sous linux aussi a chaque processus il y a au minimum un thread.
Exemple :
[admin@one rsync]$ ls -d /proc/5551
/proc/5551 // processus 5551
[admin@one rsync]$ ls /proc/5551/task/
5551 // thread 5551
C'est un processus (non multi-thread) qui n'a qu'un thread (il doit obligatoirement en avoir au moins un).
La différence avec Windows est que les numéros de processus et de thread son partagé. Sous Linux le numéro du premier thread d'un processus est égale au numéro du processus.
> l'ordonnanceur l'avait décidé (tu comprends, un coeur travaillait à 100%, pas l'autre, alors forcément, l'ordonnanceur a voulu donner du boulot à ce dernier ...).
Tout est normal, l'OS est là pour utiliser au mieux les ressources. Si deux thread sont attachés à un même cpu et qu'un cpu ne fout rien, l'OS va attacher un thread à un autre cpu.
En fait, on ne peut avoir deux threads sur un même cpu. Un thread est réveillé que s'il y a un cpu de disponible. Tout se faire, l'OS peut décider de mettre en sommeil un autre thread (afin de libérer un cpu).
Notons qu'un thread en sommeil n'est pas attaché à un cpu. Donc lorsque l'OS le réveille il peut l'attacher à n'importe quel cpu. Ça ne fait pas plus de boulot pour l'OS. Mais il vaut mieux le rattacher au cpu où il s'exécutait avant car le cache du cpu a peut-être des données que le thread va utiliser.
> mais bien évidemment, c'est plus ou moins indépendant du fait qu'on manipule un mutex ou non.
Pas vraiment. Tant que le thread est actif, il ne change pas de cpu. Mais dès qu'il est en sommeil il peut changer de cpu. Qu'il possède un lock ou soit en attende d'un lock n'y change rien.
Le thread peut passer en sommeil pour différentes raisons :
- l'ordonnanceur estime qu'il a écoulé son quantum de cpu et donc le passe en sommeil pour donner du cpu à un autre thread.
- le thread est passé en sommeil car il attend un lock, un semaphore, la lecture d'un fichier, etc... L'OS peut le changer de cpu au prochain réveil.
Changer de cpu un thread coûte peu. Il peut y avoir des problèmes d'utilisation du cache du cpu.
Exemple : j'ai trois threads mais 2 seulements s'exécute en même temps. Lorsqu'un thread tourne, il le fait pour très très peu de temps.
Imaginons que j'ai thread_A thread_B thread_C et deux cpu : cpu_1 cpu_2.
On peut avoir ce cas :
cpu_1 : thread_A
cpu_2 : thread_B
// thread_A passe en sommeil et thread_C est réveillé
cpu_1 : thread_C
cpu_2 : thread_B
// thread_B passe en sommeil et thread_A est réveillé
cpu_1 : thread_C // le cache de cpu_1a peut-être des données de thread_A
cpu_2 : thread_A
etc...
Les threads n'arrêtent pas de passer de cpu_1 à cpu_2 et vice versa. Le cache des cpu est mal utilisé.-
[^]Re: Multicoeur ?
Posté par lasher () le 26/07/2007 à 21:42. (lien). Évalué à 3.« Tout est normal, l'OS est là pour utiliser au mieux les ressources. Si deux thread sont attachés à un même cpu »
Non. Je te donne le cas d'un processus unique qui pouvait aléatoirement être migré entre un coeur et l'autre. Il y a quelques générations du noyau de cela, c'était même un ping pong permanent (et très coûteux). Depuis l'ordonnanceur a moins la bougeote, mais il lui arrive encore de migrer un thread/processus d'un processeur à l'autre même lorsque ce n'est pas judicieux.-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 26/07/2007 à 22:10. (lien). Évalué à 1.> Non. Je te donne le cas d'un processus unique qui pouvait aléatoirement être migré entre un coeur et l'autre.
Ce qui est normal. Et ce n'est pas vraiment aléatoire. Fais des setaffinity sur plusieurs programme et tu va voir que les performances vont dramatiquement chuter. Donc déplacer un thread est tout à fait normal. Et c'est peu coûteux. Si tu veux te convaincre que c'est peut couteux, fais un "make -j nb_cpu+2" et un "make -j nb_cpu". Les deux vont s'éxécuter quasiment aussi vite. Pourtant pour le premier il y aura beaucoup plus de "déplacement" de thread d'un cpu à un autre.
Considère ça :
cpu_1 : thread_A
cpu_2 : thread_B
Thread_A passe en sommeil et thread_C est lancé sur cpu_1 (puisqu'il est disponible)
cpu_1 : thread_C
cpu_2 : thread_B
Thread_B passe en sommeil.
Maintenant le thread_A doit être lancé. Que doit faire l'OS ? Arrêter thread_C, le passer sur cpu_2, le lancer, et lancer thread_A sur cpu_1 ? Ça c'est beaucoup plus coûteux que de lancer thread_A sur cpu_2.
> Il y a quelques générations du noyau de cela, c'était même un ping pong permanent (et très coûteux).
Ce n'est pas coûteux du côté OS. Ça bouffe quasiment autant de cycle. Le problème est qu'il peut y avoir une mauvaise utilisation du cache cpu. Le problème peut être "dramatique" pour certaine architecture. Mais pas sur PC.
S'il est possible qu'un thread s'éxécute sur le même cpu, tant mieux. Mais ne chercher que ça ferait chuter les performances (et gravement).
-
-
-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 26/07/2007 à 19:58. (lien). Évalué à 3.J'ai déjà eu le cas d'un processus (pas d'un thread, nous sommes bien d'accord) qui était migré d'un coeur à un autre, sans autre raison que l'ordonnanceur l'avait décidé
Linux a (avait?) la mauvaise manie de faire varier les cpu sur lesquel un processus tourne . Ie tu as un yield (pour une raison ou une autre, par exemple une e/s qui demande un cpu). Linux peut faire une petite boucle : le process 1 sur le cpu ++, etc...
L'intéret des implémentation MxN permet justement d'éviter ca :
tu fout NB_PROC+1 thread noyau et tu les bloque sur un cpu particulier (tu dois pouvoir le faire normalement avec un thread noyau.).
Ensuite tu gere le scheduling en interne (donc tu diminue les appels systeme, et diminue les context switch).--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
-
-
-
-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 26/07/2007 à 19:53. (lien). Évalué à 3.un mutex, si tu n'es pas mis en attente, execute normalement son code dans le thread appelant. Il n'y a donc pas de raison de context switch.
Peut etre que certains (mauvaise) implémentation change de thread, mais il n'y a normalement pas de raison.
Par contre le mutex te bouffe toujours meme si tu as moins de thread que de cpu : c'est une demande de synchro, il y a donc du code, un test_and_set , voir une mise en attente si la ressource est indisponible.
Si tu as plus de thread que de cpu ... ben tu as pu lancer le mutex donc tu as un cpu, donc on est dans le meme cas qu'au dessus.
De plus, dans un contexte plus restreint (le calcul haute performance, où les entrées/sorties sont rares), synchroniser comme un malade est souvent synonyme de mauvaises performances.
Balancer des messages a tire larigo aussi ;).
Mais la c'est pour des problématique de performance 'normale' (la problématique, pas la performance).
Si tu as une ressource qui est utilisé pendant 20% du temps d'execution du thread, et que tu lance 200 thread, il faut pas etre devin pour savoir que tu vas pas avoir un speedup de 200 ;).--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 26/07/2007 à 22:46. (lien). Évalué à 1.> Par contre le mutex te bouffe toujours meme si tu as moins de thread que de cpu : c'est une demande de synchro, il y a donc du code, un test_and_set ,
C'est ridicule, c'est fait en une centaine de cycle cpu maxi. A moins d'avoir plus d'un millions de lock par seconde, ce n'est pas un problème de performance.
> voir une mise en attente si la ressource est indisponible.
Mise en attente qui ne coûte rien puisque le thread n'a rien d'autre à faire.
Si tu ne veux pas de "contexte switch", tu peux remplacer les locks fournit par le système avec un truc dans ce goût :
volatile int i = 0 ;
lock() {
while (true) {
while (i) ;
if (++i == 1) {
break ;
}
else {
// lock déjà pris par un autre
--i ;
}
}
unlock() {
--i ;
}
Ça doit marcher mais tu ne vas pratiquement rien gagner en performance :-(. Si tu as plus de cpu que de thread, tu ne perds pas en performance. Mais si tu as moins de cpu que de thread, tu vas perdre énormément en performance puisque des cpu seront utilisés à faire des "while(i) ;" alors qu'il pourrait faire des trucs vraiment utile.
Donc les locks (mutex, critical section sous windows) ne coûte pratiquement rien et sont très très utiles.-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 27/07/2007 à 08:06. (lien). Évalué à 3.C'est ridicule, c'est fait en une centaine de cycle cpu maxi. A moins d'avoir plus d'un millions de lock par seconde, ce n'est pas un problème de performance.
C'est tres simple d'avoir plus d'un million de lock par seconde. Et quand certains algos sont optimisé en asm pour diminuer tant que faire ce peu le nombre de cycle, ben si tu en rajoute, tu te dis que tu l'optimise pas.
D'ailleur c'est pas pour rien que les mutex pthread sont en partie écrit en asm : pour avoir le moins d'overhead possible : un mutex est extremement souvent appelé sur un vrai code de calcul.
Mise en attente qui ne coûte rien puisque le thread n'a rien d'autre à faire.
La mise en attente demande un context switch entre autre.
Si tu ne veux pas de "contexte switch", tu peux remplacer les locks fournit par le système avec un truc dans ce goût :
ca s'apelle un spinlock; et tu gagne beaucoup plus a faire un test_and_set fait en asm qu'a te le faire a la mano ;) (d'autant que ton code est pas thread safe, vu que deux personne peuvent rentrer avec ton ++i==1. Il faut que le test_and_set soit atomique pour que ce soit viable, ce que fait l'instruction asm)
Les spinlock sont utilisés dans les mutex ou autre.
Donc les locks (mutex, critical section sous windows) ne coûte pratiquement rien et sont très très utiles.
Mais j'ai jamais dis qu'ils n'étaient pas utiles ;).--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par lasher () le 27/07/2007 à 09:59. (lien). Évalué à 2.« ca s'apelle un spinlock; et tu gagne beaucoup plus a faire un test_and_set fait en asm qu'a te le faire a la mano ;) »
Sauf que le T&S ne fonctionne (à ma connaissance) pas pour un grand nombre de processeurs (problèmes liés à la cohérence de cache, etc.).-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 27/07/2007 à 11:14. (lien). Évalué à 2.possible ca.
Mais ils font comment les spinlock alors ?--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par lasher () le 27/07/2007 à 14:20. (lien). Évalué à 3.ben en faisant un bête [1]
while(entier>0) ;
« entier » étant déclaré volatile int entier;
On peut se permettre ça car en pratique, tu n'aura pas d'état inconsistant d'un registre entier (tous les bits sont basculés en même temps). Par contre, ça a un inconvénient si tu t'es planté pour l'attente, notamment pour le multi-coeur : un coeur se retrouve à monopoliser le bus d'accès mémoire, et peut donc empêcher ses petits camarades de travailler (donc il ne faut pas se planter).
[1] en fait il faut raffiner un chouilla plus, mais c'est l'idée.-
[^]Re: Multicoeur ?
Posté par Matthieu C () le 27/07/2007 à 17:33. (lien). Évalué à 4.hum et tu fait comment pour modifier ton entier de maniere atomique (sans que plusieurs process quitte la boucle en meme temps) ?
IRRC le T&S est necessaire, c'est le compare&exchange qui est facultatif...-
[^]Re: Multicoeur ?
Posté par lasher () le 27/07/2007 à 23:08. (lien). Évalué à 2.« hum et tu fait comment pour modifier ton entier de maniere atomique (sans que plusieurs process quitte la boucle en meme temps) ? »
En fait je ne vois pas trop où est le problème de threads quittant la boucle en même temps, étant donné que c'est ce qu'on veut. Plus exactement : si j'ai X threads à synchroniser, et que chacun a un boulot prenant grosso-modo le même nombre de cycles, alors je peux tenter une attente active pour réduire au maximum le temps de synchro. Ensuite, je n'ai plus qu'à avoir un pseudo code du genre
volatile int n = NB_THREADS_TOTAL;
/* début du thread : « fork » */
/* boulot ... */
n--; /* s'effectue atomiquement, sans risque de cafouillage car c'est un volatile int (on suppose un mécanisme de cohérence de cache) */
while (n > 0);
/* join(), ou bien suite du boulot à faire pour le thread */
Évidemment, je ne donne que l'idée principale.-
[^]Re: Multicoeur ?
Posté par Matthieu C () le 28/07/2007 à 08:57. (lien). Évalué à 4.ha ok, mais ton truc il n'y a aucune section critique ...
Le boulot est donc fait dans des données non partagée. C'est quand que tu synchronise tes données ?
A la mort des threads après le join ?
-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 28/07/2007 à 15:53. (lien). Évalué à 3.n--; /* s'effectue atomiquement, sans risque de cafouillage car c'est un volatile int (on suppose un mécanisme de cohérence de cache) */
faux.
n-- (meme --n) dépend du compilateur.
et comme c'est un volatile int il peut etre réecris.
exemple n est a l'adresse 0x12345
T1 :
mv 0x12345 R1
ADD 1 R1
T2
mv 0x12345 R1
T1 :
mv R1 0x12345 ; le volatile demande de remettre en mémoire si un autre thread le demande. Evite qu'une donnée reste en cache/registre par exemple lors d'un context switch
T2 :
ADD 1 R1
mv R1 0x12345 ; le volatile demande de remettre en mémoire si un autre thread le demande.
on aura au final n-1 et pas n-2.
Et donc ton truc ne se terminera jamais.
Je t'invite a faire le test sur un quadri proc, et tu verras que --n ou ++n n'est pas forcément atomique.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 28/07/2007 à 18:03. (lien). Évalué à 1.> n-- (meme --n) dépend du compilateur.
J'ai bien dit que ça dépendait du compilateur (et hardware).
Le C ne garantit l'atomicité que pour l'accès et l'écriture (et pas pour tous les types, il n'y a que le type int qui est garantit je crois). Il (la spec du C) ne garantit pas que --n est thread safe.
> Je t'invite a faire le test sur un quadri proc, et tu verras que --n ou ++n n'est pas forcément atomique.
Déja fait.
Je ne suis pas un spécialiste en assembleur, mais je ne crois pas que les choses soit aussi simple que tu le dis.
Exemple (pour faire hypra court):
volatile int i = 0 ; ; ; ; // volatile ou non
Thread/cpu 1 : while(true) ++i ;
Thread/cpu 2 : while(true) --i ;
Les performances seront assez mauvaise car les caches des cpus ne seront pas utilisés.
Il y a des mécanismes, dont je ne comprend rien, pour que tous les cpu voit la même mémoire. Si une partie de la mémoire centrale est en cache du cpu 1 et cpu 2 veut lire cette partie mémoire, le cache de cpu 1 est invalidé.
Ceci n'existe pas pour tous les hardwares, mais c'est maintenant assez commun.
Tes instructions assembleurs sous-entendent qu'il n'y a pas d'instruction pour incrémenter directement une adresse mémoire (et donc qu'un cpu puisse dire "coucou, j'utilise cette adresse mémoire"). Je n'en suis pas convaincu.-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 28/07/2007 à 19:10. (lien). Évalué à 3.Tes instructions assembleurs sous-entendent qu'il n'y a pas d'instruction pour incrémenter directement une adresse mémoire (et donc qu'un cpu puisse dire "coucou, j'utilise cette adresse mémoire"). Je n'en suis pas convaincu.
Comment peut tu 'incrémenter directement une adresse mémoire' ?
La ram c'est pas un processeur, tu dois forcément récupérer la mémoire a une adresse un moment , l'incrémenter, puis la remonter en ram.
Déja fait.
Fait le pendant 15h, sur un processeur bien chargé par autre chose (pour forcé des context switch).
Moi aussi déja fait, et les résultats sont bien ce que je dis : non déterministes.
(cf plus bas, vu que je l'ai fait, et en 20 sec j'ai montré ca :D )
Le C ne garantit l'atomicité que pour l'accès et l'écriture (et pas pour tous les types, il n'y a que le type int qui est garantit je crois). Il (la spec du C) ne garantit pas que --n est thread safe.
Comme tu peux le remarquer sur le code asm de ++n sur mon autre commentaire ( https://linuxfr.org/comments/854613.html#854613 )avec un volatile int, ce n'est pas atomique.
et la c'est quand meme gcc 4.1 , donc pas le dernier des compilos codé avec les pieds entre deux cours.
Mais bon faut croire qu'il te faut absolument un exemple alors :
j'ai donc fait un petit programme tout comme il le faut.
Il tourne meme pas sur un quadriporc mais sur un amd 1800+. Donc loin d'etre une foudre de guerre, et uniproc meme pas ht
Voici le code :
volatile int n1;
#define NB_ITER 10000000
void* test4(void * a)
{
long i=NB_ITER;
for (;i>0;--i)
n1++;
}
int main()
{
#define NB_THREAD 50
pthread_t thread[NB_THREAD];
int i=0;
n1=0;
for (;i<NB_THREAD;++i)
{
pthread_create(&thread[i],NULL,test4,NULL);
}
for (i=0;i<NB_THREAD;++i)
{
pthread_join(thread[i],NULL);
}
printf("n = %d =?= %d\n",n1,NB_ITER*NB_THREAD);
}
Comme tu peux le constater, relativement simple. Je lance 50 threads, ils opèrent tous sur n1 qui est défini en globale et volatile.
et ils font chacun une incrémentation avec un opérateur d'après toi 'atomique'
Les tests :
[alpha@oni] /tmp/volatile 20:55:30$ make
gcc -g -o test test.c -lpthread
[alpha@oni] /tmp/volatile 20:55:32$ ./test
n = 295501574 =?= 500000000
[alpha@oni] /tmp/volatile 20:55:37$ ./test
n = 280084287 =?= 500000000
Je te rapelle ce que tu as mis > (d'autant que ton code est pas thread safe, vu que deux personne peuvent rentrer avec ton ++i==1.
Il est thread-safe. J'utilise "volatile". Il est thread-safe à un petit soucis près, ça dépend du compilo et du hardware.Mais sur un PC "classique", ça marche.
Pour faire la meme chose avec un a==1 (ce que tu faisais), c'est plus dur . (Trouver un code qui montre facilement ce probleme).
Toutefois on peut a nouveau regarder le code asm que ca peut nous sortir :
int test3()
{
volatile int a;
if (a==1)
return 0;
return 0;
}
va nous donner :
.globl test3
.type test3, @function
test3:
pushl %ebp
movl %esp, %ebp
subl $20, %esp
movl -4(%ebp), %eax ; on récupère a
cmpl $1, %eax ; on compare a un. On compare pas directement sur -4(%ebp). Donc possibilité de race condition si on change la.
jne .L6
movl $0, -20(%ebp) ; valeur de retour.
jmp .L8
.L6:
movl $0, -20(%ebp)
.L8:
movl -20(%ebp), %eax
leave
ret
.size test3, .-test3
Alors je suis désolé, mais pour moi c'est absolument pas probant.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Multicoeur ?
Posté par Laurent Pointal (page perso, ) le 29/07/2007 à 17:40. (lien). Évalué à 1.Il est thread-safe. J'utilise "volatile".
Quel est le rapport ?-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 29/07/2007 à 18:28. (lien). Évalué à 3.ce qui est en italique est une citation, et non pas mes propos ;)
Justement tout le commentaire était pour essayer de démontrer le contraire.--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
-
-
-
-
-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 28/07/2007 à 07:40. (lien). Évalué à 1.> La mise en attente demande un context switch entre autre.
Ce qui ne coûte rien (ou n'impacte pas les performances) puisque le cpu n'a rien d'autre à foutre (cas où il y a plus de cpu que de thread actif).
> (d'autant que ton code est pas thread safe, vu que deux personne peuvent rentrer avec ton ++i==1.
Il est thread-safe. J'utilise "volatile". Il est thread-safe à un petit soucis près, ça dépend du compilo et du hardware. Mais sur un PC "classique", ça marche.
> Il faut que le test_and_set soit atomique pour que ce soit viable, ce que fait l'instruction asm)
Relis bien le code. Ça marche. Ce qui compte, c'est que ++i soit atomique et réalisé par un thread à la fois (ce que nous garantit "volatile").
volatile int i = 0 ;
lock() {
while (true) {
while (i) ;
if (++i == 1) { [1]
break ;
}
else {
// lock déjà pris par un autre
--i ;
}
}
}
Thread 1 fait "++i" et obtient la valeur 1.
Thread 2 fait "++i" et obtient la valeur 2.
Thead 1 compare la valeur de retour de "++i" avec "1" beaucoup plus tard. C'est true, donc il a le lock.
Thead 2 compare la valeur de retour de "++i" avec "1". C'est false, donc il n'a pas le lock. Plus loins il fait un "--i" pour "remettre de l'ordre".
Que l'incrémentation ET la comparaison ne soit pas atomique n'est pas un problème ici. Le "volatile" garantit qu'il n'y a qu'un thread qui accède à i à la fois.
Mais il faut l'utiliser avec beaucoup de précaution.
Pour "++i" ça doit marcher.
Pour :
i = (DoLock == true ? i+1 : i ) ;
ça doit très probablement ne pas marcher. Le résultat de "i+1" peut être mis dans une "variable temporaire" puis copié dans i.
Mon lock ne marcherait pas s'il fait :
if (i==0) { ++i ; }
Mais ce n'est pas ce qu'il fait.
Il y a effectivement des instructions asm pour faire une incrémentation et un test de façon atomique (il y en a plusieurs).
> D'ailleur c'est pas pour rien que les mutex pthread sont en partie écrit en asm : pour avoir le moins d'overhead possible
Les mutex phtread, ne font pas que ce que je fais (avec la fonction lock()). Il y a spinlock pour un nombre de cycle limité, il y a vérification si c'est un système smp ou non (si c'est mono-cpu, inutile de faire le spinlock et il faut passer directement en sommeil), il enregistre l'id du thread qui fait le lock pour donner un warning si le thread qui fait l'unlock n'est pas le même, les mutex phtread sont inter-processus, mon lock() ne l'ai pas, etc...
> C'est tres simple d'avoir plus d'un million de lock par seconde.
Dans ce cas j'ai envis de dire que c'est compliqué pour ne pas faire ce million de lock par seconde.
Avec volatile (et du matos correcte), il y a plein de cas où on peut éviter les locks. Et ça marche, je le fais courrament sur des trucs qui tourne 24h/24. Par contre, je le fait avec beaucoup de précaution et uniquement pour int, long et pointeur. Il y a même des systèmes (nombreux) qui n'ont pas besoin de "volatile" :-) Les cpus/cache vérifient tout.-
[^]Re: Multicoeur ?
-
[^]Re: Multicoeur ?
Posté par Matthieu C () le 28/07/2007 à 09:49. (lien). Évalué à 2.Il est thread-safe. J'utilise "volatile". Il est thread-safe à un petit soucis près, ça dépend du compilo et du hardware. Mais sur un PC "classique", ça marche.
Bof les x86 (ainsi que d'autre proc) sont capable de reordonnancer les instructions. Or le volatile n'est utile que pour le compilo. Donc sans "memory barrier" y a des chances que ca marche pas.
Il y a même des systèmes (nombreux) qui n'ont pas besoin de "volatile" :-) Les cpus/cache vérifient tout.
A bon pourtant les volatiles s'adresse au compilo pour pas lui dire d'essayer d'optimiser les acces memoire. Les "cpus/cache" serait donc capables devinner que le compilo a fait une optimisation et la virer ?
Je sais pas pourquoi, mais j'ai comme un gros doute sur ce que tu dis.-
[^]Re: Multicoeur ?
Posté par lasher () le 28/07/2007 à 11:56. (lien). Évalué à 2.« Bof les x86 (ainsi que d'autre proc) sont capable de reordonnancer les instructions. Or le volatile n'est utile que pour le compilo. Donc sans "memory barrier" y a des chances que ca marche pas. »
Euh, pas que pour le compilateur. Ça te garantit un comportement à l'exécution, et l'Out-of-Order n'y changera rien. Mais c'est vrai que si tu n'as pas de cohérence de cache, l'utilisation de volatile n'est pas bien intéressante.-
[^]Re: Multicoeur ?
Posté par Matthieu C () le 28/07/2007 à 14:00. (lien). Évalué à 2.Euh, pas que pour le compilateur. Ça te garantit un comportement à l'exécution, et l'Out-of-Order n'y changera rien.
Tu as des liens/infos dessus ?
Tous ce que j'ai pu voir, c'est que le volatile te garanti que le compilo s'amuse pas optimiser ton code et a le reordonnancer.
Le comportement à l'exécution ne semble pas garanti par le volatile, mais par les machines qui s'arrange meme s'il elles font du Out-of-Order, a reordonner les resultats pour que ca soit transparent (dixit http://en.wikipedia.org/wiki/Out-of-order_execution).
Mais c'est vrai que si tu n'as pas de cohérence de cache, l'utilisation de volatile n'est pas bien intéressante.
Quel sont les machines qui ont une cohérence de cache ?-
[^]Re: Multicoeur ?
Posté par briaeros007 () le 28/07/2007 à 16:14. (lien). Évalué à 4.- le volatile garantie que les données seront mise a nouveau en mémoire une fois qu'elles sont calculées.
- Elle évite donc qu'elles reste dans des registres pour des optimisations.
- Par exemple j'ai trois variables et 5 registres. Je peux stocker toutes les variables dans les registres et faire toutes mes instructions dessus.
- Si il y a un thread qui en a besoin au milieu (je libère un lock et je le reprend après) je n'ai aucune assurance que les variables qui sont des les registres sont bien pushé en mémoire. Le volatile sert a ca.
- D'ailleur le volatile nous protège tellement peu de ca qu'il y a un spinlock au début des lock ou unlock d'un mutex. Car le spinlock est fait lui sur une véritable instruction atomique (test and set). exemple de code .
toto (){ int a; lock(); ++a; a*=2; unlock(); do_something(); lock(); a/=2; unlock(); }Sans le volatile, au premier unlock, on ne sait pas si a sera en mémoire (donc visible par les autres threads) ou alors encore dans les registres. Si il est encore dans les registres, alors lors du second lock, on n'aura pas une bonne valeur de a car il a pu etre modifié pendant qu'on était dans do_something et qu'on aurait donc une valeur obsolète. le volatile n'est permet pas de faire une fonction atomique. Comme je sens déja l'attaque (pas forcément de lasher ou d'isnotgood, mais mieux vaut prevenir que guerir) du 'tu ne sais pas de quoi tu parle' regardons donc ce que fait volatile :int test1() { volatile int a; ++a; a+=2; return a; } int test2() { int a; ++a; a+=2; return a; } int main() { }Un code relativement simple n'est il pas ? Maintenant regardons l'asm qu'il nous génère pour ca : gcc -S test.ctest1: pushl %ebp movl %esp, %ebp subl $16, %esp movl -4(%ebp), %eax ; on recupere a addl $1, %eax ; ++a movl %eax, -4(%ebp) ; on le remet movl -4(%ebp), %eax ; on le recupere a nouveau addl $2, %eax ; a+=2 movl %eax, -4(%ebp) ; on le remet movl -4(%ebp), %eax ; return a leave ; bye bye ret .size test1, .-test1 .globl test2 .type test2, @function test2: pushl %ebp movl %esp, %ebp subl $16, %esp addl $1, -4(%ebp) ;++a addl $2, -4(%ebp) ;a+=2 movl -4(%ebp), %eax ;return a leave ret .size test2, .-test2je vois mal en quoi faire 3 instructions a la place d'une seule rend ces instructions 'atomiques'. Ps désolé pour la liste en début de commentaire, je sais pas comment incoporer du code , mais pouvoir avoir des retour chariots 'normaux' dans le reste du commentaire.--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
[^]Re: Multicoeur ?
Posté par Nicolas Boulay () le 31/07/2007 à 15:18. (lien). Évalué à 2."Quel sont les machines qui ont une cohérence de cache ?"
toute. Il y avait bien eu certaine machine Cray sans cohérence, mais c'était impossible à coder avec.
Volatile, sert surtout pour l'écriture dans des registres mémoires qui signifie quelques choses (périphérique), globalement changer l'ordre d'accès ou le nombre d'accès est interdit pour resté cohérent. Volatile sert pour le compilo.
Ensuite, le cpu ne fait pas n'importe quoi en fonction du paramétrage du système de mémoire virtuelle (genre non bufferable, non cachable, etc..)--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
-
-
-
-
[^]Re: Multicoeur ?
Posté par pdesarnaud () le 28/07/2007 à 16:12. (lien). Évalué à 3.Il me semble que sur un systeme multi processeurs x86 ( hors Itanium ), l'usage de "volatile" ne garantit pas que l'operation ++i soit atomique.
L'opération ++i est decomposé en fait en trois operations par le cpu
mov eax,dword ptr [ i ] // lecture dans un registre de la variable i
inc eax // Incrementation de ce registre
mov dword ptr [i] , eax // ecriture de la variable
Si deux trheads exexutent en même temps cette operation, le reultat est i==1 pour les deux threads....
-
-
-
-
-
-
-
-
-
-
[^]Re: Multicoeur ?
Posté par lasher () le 26/07/2007 à 09:54. (lien). Évalué à 3.« Multicoeur c'est du multi-cpu. Au niveau appli/programmation on ne voit pas la différence. »
Ça dépend du type d'application. Lorsque deux coeurs partagent le même cache, la notion de localité des données peut prendre une grande importance. La notion de proximité des processeurs aussi, du coup (je pense par exemple aux stations de travail et serveurs SMP/CMP, genre bi-xeon core 2 duo).
Imagine que tu sois sur une station de travail bi-proc, bi-coeur. Tu es graphiste, et tu utilises une application qui modifie tes jolies images. Bon, certains filtres effectuent plusieurs passes sur tes données. Là, avoir un SMP « pur » ou un SMP/CMP peut te faire gagner 50% dans le cas d'une bonne utilisation de la localité des données, ou au contraire te faire perdre 100% de puissance potentielle.
Donc non, SMP != CMP.-
[^]Re: Multicoeur ?
Posté par IsNotGood () le 26/07/2007 à 15:42. (lien). Évalué à 1.Oui. C'est pour ça que j'ai dit "Au niveau appli/programmation" et non performance.
Coder pour tenir compte de la proximité des cpu/core est exceptionnel. Je ne l'ai jamais fait, je ne le ferais sans doute jamais.
Je crois que le noyau Linux affecte les cpu/core au thread en tenant compte de la "proximité" (il ne le fait peut-être que sur certains matos). Mais je ne sais pas du tout ce qui est fait, comment c'est déterminé, etc...
Il y a bien setaffinity() mais ça ne doit être réservé qu'à une appli. Si d'autres applis le font de façon intépendante, c'est une catastrophe en performance. Donc pour moi c'est à éviter.-
[^]Re: Multicoeur ?
Posté par lasher () le 26/07/2007 à 15:53. (lien). Évalué à 4.Depuis Bull a pondu les CPU sets, qui permet de dire exactement sur quel processeur virtuel (thread, coeur, processeur) tu veux « visser » un processus ou un thread (la différence entre les deux étant relativement minime, vu que dans tous les cas on appelle clone()).
Je m'en sers en ce moment pour faire tout un tas de tests et autres benchmarks (notamment, évaluer l'impact des caches partagés par rapport à du SMP classique), et je pense que pour une application mono-utilisateur, on finira par devoir un minimum s'y intéresser, ne serait-ce que pour certaines tâches critiques. C'est un peu ce que fait Mac OS quand de l'OpenGL est exécuté : plutôt que d'avoir un processus affecté à un coeur par le système, et le runtime OpenGL qui s'exécute sur ce même coeur, on le fait se lancer sur l'autre coeur, pour alléger la charge. OpenGL n'en est pas rendu thread-safe pour autant, mais on a au moins découplé le côté « rendu » du côté « traitement ».
-
-
Choix de la licence (GPL) ?
Je comprend qu'Intel offre gratuitement son produit pour qu'on utilise leur matériel : si personne ne sait programme pour un nouveau type de CPU, personne ne va l'acheter (tiens, ça me rappelle l'Itanium tellement révolutionnaire :-/). Par contre, la licence GPL force la licence du logiciel qui l'utilise : le logiciel doit aussi ête sous GPL, ou alors je me trompe ?
« La version commerciale de TBB continue d'exister (299$) et elle contient exactement le même code que la version libre et ne se distingue que par le support technique d'une durée d'un an. » Je dirai aussi que la version commerciale permet de faire du logiciel propriétaire, ou bien ?
-
[^]Re: Choix de la licence (GPL) ?
Posté par Troy McClure (page perso, ) le 25/07/2007 à 12:52. (lien). Évalué à 2.c'est gpl + exception:
http://episteme.arstechnica.com/eve/forums/a/tpc/f/174096756(...)
donc tu peux faire du proprio avec et même la lier statiquement.
-
[^]Re: Choix de la licence (GPL) ?
Posté par nats (Jabber id, page perso, ) le 25/07/2007 à 12:57. (lien). Évalué à 3.Bah ils offrent déjà la doc intégrale en version papier (frais de port gratuit), soit 5 tomes bien gros et trés utile quand tu code dans le domaine.
Surtout qu'au final cette lib ne concerne pas que les processeurs intel.--
On vous ment! Mais pas moi...
GPLv2/v3
« La société Intel vient d'annoncer que sa bibliothèque commerciale (...) passe sous licence GPLv2. (...) La bibliothèque TBB fonctionne sur différents compilateurs (Intel, Microsoft et GCC) »
http://kerneltrap.org/node/13975
« GCC 4.2.1 has been released. (...) All future releases will be released
under GPL version 3. »
Un souci GPLv2/GPLv3 à prévoir ?
-
[^]Re: GPLv2/v3
-
[^]Re: GPLv2/v3
Posté par patrick_g (page perso, ) le 25/07/2007 à 14:40. (lien). Évalué à 3.Etant donné que le but d'Intel est avant tout de favoriser l'utilisation de TBB et étant donné qu'Intel garde le copyright complet sur TBB je pense qu'on peut parier que ce soft passera facilement à la GPLv3 en cas de besoin.
Hello world !
Quelqu'un à un bout de code qui permettrait en deux minute de voir comment on utilise les quelques fonctions de bases ?
-
[^]Re: Hello world !
Posté par reno () le 26/07/2007 à 07:49. (lien). Évalué à 4.Le post de patrick_g contient deux liens vers des articles qui explique comment ça marche, autrement c'est vrai qu'on a du mail a voir de quoi il s'agit..
http://linuxfr.org/comments/853597.html#853597
-
[^]Re: Hello world !
Posté par rewind () le 26/07/2007 à 10:58. (lien). Évalué à 2.En gros, c'est une réimplémentation de primitives haut niveau (for, while, etc) et de containers de la STL. Mais il y a des contraintes, par exemple le parallel_for doit s'éxécuter sur des tâches indépendantes.
C'est pas très nouveau comme concept, il y a notamment STAPL qui existe depuis pas mal de temps [1]. Cette présentation [2] fait un comparatif des fonctionnalités d'autres librairies/langages du même genre.
Je n'ai pas encore jeté un oeil sur le code mais il semblerait que ce soit fait à base de vol de travail comme le suggère [3]. Mais ça m'intéresse de voir comment ils font ça de manière efficace.
[1] http://parasol.tamu.edu/groups/rwergergroup/research/stapl/
[2] http://www.cs.unm.edu/~fastos/06meeting/FASTOS-STAPL_2006.pd(...)
[3] http://assets.devx.com/goparallel/19703.png
Cette page a été générée par Templeet en 0.3767s (dont 0.0304 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.