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 (326 hits)
- Le site de TBB (791 hits)
- Un article ArsTechnica (336 hits)
- Un article eWeek (188 hits)
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.
L'annonce d'Intel (326 hits)
Le site de TBB (791 hits)
Un article ArsTechnica (336 hits)
Un article eWeek (188 hits)
> 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 BOTTIN () 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 BOTTIN () 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...?--
You got the money, I got the soul.-
[^]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, ma
-
-
-
-
-


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.