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. Tous les acteurs de l'informatique mondiale se tournent de plus en plus vers des architectures à c½urs multiples car la course à la fréquence est devenue presque impossible. 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.
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.
Aller plus loin
- L'annonce d'Intel (10 clics)
- Le site de TBB (23 clics)
- Un article ArsTechnica (4 clics)
- Un article eWeek (3 clics)
# Alors ca c'est du bon
Posté par nats . Évalué à 9.
Mais la c'est vraiment du bon ^^
(Enfin pour moi :p)
[^] # Re: Alors ca c'est du bon
Posté par ethtezahl . Évalué à 2.
Merci Intel.
De plus, ils prouvent que Libre != gratuit
[^] # Re: Alors ca c'est du bon
Posté par Amand Tihon (site web personnel) . Évalué à 2.
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 . Évalué à 5.
[^] # Re: Alors ca c'est du bon
Posté par paul . Évalué à 9.
[^] # Re: Alors ca c'est du bon
Posté par koyz . Évalué à 3.
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 . Évalué à 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...
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 . Évalué à 0.
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 . Évalué à 3.
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 . Évalué à 0.
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 (site web personnel) . Évalué à 0.
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. . Évalué à 4.
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 (site web personnel) . Évalué à 6.
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 . Évalué à 3.
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 . Évalué à 1.
[^] # Re: Alors ca c'est du bon
Posté par reno . Évalué à 2.
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 (site web personnel) . Évalué à 2.
[^] # Re: Alors ca c'est du bon
Posté par beagf (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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
Posté par Sylvain Sauvage . Évalué à 3.
[^] # Re: Alors ca c'est du bon
Posté par IsNotGood . Évalué à 3.
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 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 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 . Évalué à 1.
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 . Évalué à 2.
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 . Évalué à 0.
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 . Évalué à 1.
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 . Évalué à 4.
[1] liberté, évidemment.
[^] # Re: Alors ca c'est du bon
Posté par Guillaume Rossignol . Évalué à 2.
[^] # Re: Alors ca c'est du bon
Posté par IsNotGood . Évalué à -2.
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 (site web personnel) . Évalué à 2.
> 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 . Évalué à 0.
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?
Posté par windu.2b . Évalué à 0.
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 (site web personnel) . Évalué à 10.
[^] # Re: Petites précisions?
Posté par Damien Cassou . Évalué à 1.
[^] # Re: Petites précisions?
Posté par xander_1 . Évalué à 5.
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 (site web personnel) . Évalué à 8.
- 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 (site web personnel) . Évalué à 10.
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. . Évalué à 1.
Simple question de point de vue (et à mon avis de bon sens, mais ça se discute).
[^] # Re: Petites précisions?
Posté par Dinofly (site web personnel) . Évalué à 5.
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.
[^] # Re: Petites précisions?
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Petites précisions?
Posté par reno . Évalué à 5.
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 (site web personnel) . Évalué à 7.
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?
Posté par IsNotGood . Évalué à 1.
Pour moi la GPL représente : "du code libre, un programme libre qui reste libre".
La BSD est tellement "libre" qu'elle permet de faire des programmes pas libres.
# G5
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: G5
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: G5
Posté par scls19fr (site web personnel) . Évalué à 2.
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 . Évalué à 4.
Il y a beaucoup d'embarqué multiprocesseur...?
[^] # Re: G5
Posté par reno . Évalué à 7.
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 (site web personnel) . Évalué à 4.
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 ?
Posté par IsNotGood . Évalué à 1.
> 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 (site web personnel) . Évalué à 8.
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 (site web personnel) . Évalué à 6.
http://www.devx.com/cplus/Article/33334
http://www.devx.com/go-parallel/Article/34951
[^] # Re: Multicoeur ?
Posté par briaeros007 . Évalué à 4.
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.
[^] # Re: Multicoeur ?
Posté par pasBill pasGates . Évalué à 6.
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 . Évalué à 2.
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 ?
[^] # Re: Multicoeur ?
Posté par IsNotGood . Évalué à 2.
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 . Évalué à 3.
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)).
[^] # Re: Multicoeur ?
Posté par pasBill pasGates . Évalué à 2.
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 . Évalué à 1.
Je pense que la tu parle de la 'critical section' de windows, non ?
[^] # Re: Multicoeur ?
Posté par pasBill pasGates . Évalué à 4.
[^] # Re: Multicoeur ?
Posté par lolop (site web personnel) . Évalué à 4.
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().
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Multicoeur ?
Posté par IsNotGood . Évalué à 1.
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 . Évalué à 3.
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 . Évalué à 3.
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...
[^] # Re: Multicoeur ?
Posté par lolop (site web personnel) . Évalué à 0.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Multicoeur ?
Posté par lolop (site web personnel) . Évalué à 3.
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.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Multicoeur ?
Posté par lolop (site web personnel) . Évalué à 2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Multicoeur ?
Posté par pasBill pasGates . Évalué à 2.
Sinon oui ils peuvent etre recursifs.
[^] # Re: Multicoeur ?
Posté par Bozo_le_clown . Évalué à 3.
Mes très chères moules, nous assistons à un moment d'anthologie DLFPienne.
[^] # Re: Multicoeur ?
Posté par IsNotGood . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 5.
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 . Évalué à 0.
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 . Évalué à 3.
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 . Évalué à 3.
J'ai du mal a comprendre pourquoi il ne l'est pas..
[^] # Re: Multicoeur ?
Posté par IsNotGood . Évalué à -4.
Puisque ça tu parais facile et que tu es motivé : fait le !
[^] # Re: Multicoeur ?
Posté par briaeros007 . Évalué à 2.
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.
[^] # Re: Multicoeur ?
Posté par lasher . Évalué à 2.
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 . Évalué à 0.
C'est idiot je sais :D
[^] # Re: Multicoeur ?
Posté par lasher . Évalué à 3.
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 . Évalué à 2.
Et erlang ?
[^] # Re: Multicoeur ?
Posté par lasher . Évalué à 2.
[^] # Re: Multicoeur ?
Posté par loufoque . Évalué à 1.
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 . Évalué à 2.
> 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 . Évalué à 2.
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 . Évalué à 0.
"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 . Évalué à 2.
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 . Évalué à 0.
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 . Évalué à 3.
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 . Évalué à 1.
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 . Évalué à 3.
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).
[^] # Re: Multicoeur ?
Posté par lasher . Évalué à 2.
... Et c'est exactement ce que je fais. :-)
[^] # Re: Multicoeur ?
Posté par briaeros007 . Évalué à 3.
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 ;).
[^] # Re: Multicoeur ?
Posté par IsNotGood . Évalué à 1.
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 . Évalué à 3.
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 ;).
[^] # Re: Multicoeur ?
Posté par lasher . Évalué à 2.
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 . Évalué à 2.
Mais ils font comment les spinlock alors ?
[^] # Re: Multicoeur ?
Posté par lasher . Évalué à 3.
« 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 M . Évalué à 4.
IRRC le T&S est necessaire, c'est le compare&exchange qui est facultatif...
[^] # Re: Multicoeur ?
Posté par lasher . Évalué à 2.
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
Évidemment, je ne donne que l'idée principale.
[^] # Re: Multicoeur ?
Posté par M . Évalué à 4.
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 . Évalué à 3.
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.
[^] # Re: Multicoeur ?
Posté par IsNotGood . Évalué à 1.
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 . Évalué à 3.
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 :
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 :
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 :
va nous donner :
Alors je suis désolé, mais pour moi c'est absolument pas probant.
[^] # Re: Multicoeur ?
Posté par lolop (site web personnel) . Évalué à 1.
Quel est le rapport ?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Multicoeur ?
Posté par briaeros007 . Évalué à 3.
Justement tout le commentaire était pour essayer de démontrer le contraire.
[^] # Re: Multicoeur ?
Posté par IsNotGood . Évalué à 1.
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 ?
Posté par IsNotGood . Évalué à 1.
[^] # Re: Multicoeur ?
Posté par M . É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.
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 . É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. 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 M . Évalué à 2.
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 . Évalué à 4.
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.[^] # Re: Multicoeur ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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..)
"La première sécurité est la liberté"
[^] # Re: Multicoeur ?
Posté par pdesarnaud . Évalué à 3.
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 . Évalué à 3.
Ç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 . Évalué à 1.
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 . Évalué à 4.
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) ?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
« 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 (site web personnel) . Évalué à 2.
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 . Évalué à 3.
Surtout qu'au final cette lib ne concerne pas que les processeurs intel.
# GPLv2/v3
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
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
Posté par IsNotGood . Évalué à 6.
Non. Tu peux aussi compiler du proprio avec GCC.
[^] # Re: GPLv2/v3
Posté par patrick_g (site web personnel) . Évalué à 3.
# Hello world !
Posté par Paul Chavent (site web personnel) . Évalué à 2.
[^] # Re: Hello world !
Posté par reno . Évalué à 4.
http://linuxfr.org/comments/853597.html#853597
[^] # Re: Hello world !
Posté par rewind (Mastodon) . Évalué à 2.
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
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.