- libdispatch : l'implémentation en espace utilisateur (disponible sur macosforge)
- support noyau de GCD dans XNU (le noyau de Mac OS X) : contient des optimisations au support de GCD mais n'est pas strictement requise. Ce qui semble de bonne augure pour la portabilité de GCD.
- support des blocs dans le compilateur C fourni dans le compilateur libre LLVM.
Partant du constat que l'avenir est au multi-coeur et que la programmation concurrente est fastidieuse, GCD transfère la gestion des threads du développeur au système.
Cela permet une meilleure gestion des tâches, le noyau pouvant répartir celles-ci de manière plus efficace sur les cœurs disponibles, et il est capable de libérer les ressources tout seul si besoin en est. De plus, GCD maintient un réservoir de threads (threadpool), permettant une gestion dynamique du nombre de threads disponibles selon l'état du système et des besoins des applications.
GCD repose sur l'utilisation de blocs (closures) qui permettent de décomposer les tâches, différents types de files d'expédition (FIFO) où sont stockés les tâches en attendant que l'ordonnanceur défile les tâches et les exécute, et divers moyens de synchronisations.
D'autres frameworks de programmation concurrentes existent comme OpenMP intégré à la plupart des compilateurs C et C++ majeurs, la bibliothèque C++ Intel Threading Building Blocks dont l'approche est similaire à GCD (on regrettera le retard de C++0x et des expressions lambdas). La particularité de GCD est son utilisation intensive dans un système d'exploitation afin d'améliorer non seulement les performances des applications mais également la réactivité du système.
Pour le moment, très peu d'applications tirent profit de GCD hormis les applications Cocoa qui en bénéficient automatiquement de par l'intégration de celui-ci au framework propriétaire d'Apple.
La libération de libdispatch relance également la (saine) concurrence entre LLVM et GCC ...
Aller plus loin
- Page d'accueil du projet libdispatch (22 clics)
- Page d'accueil du compilateur LLVM (9 clics)
- Dépêche à propos de LLVM 2.5 (17 clics)
- Article d'introduction à GCD (14 clics)
- Référence de l'API GCD (9 clics)
- Guide de programmation en C et Objective-C (13 clics)
# Merci Apple.
Posté par Pierre . Évalué à 2.
[snip]
Total Physical Source Lines of Code (SLOC) = 32,861
Development Effort Estimate, Person-Years (Person-Months) = 7.83 (93.91)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 1.17 (14.05)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 6.69
Total Estimated Cost to Develop = $ 1,057,198
(average salary = $56,286/year, overhead = 2.40).
1 million de dollar donné a la communauté, c'est pas mal!
Non sérieux, ca m'a pas l'air complique ça. C'est plus qu'une classique bibliothèque de gestion de delayed function calls ala worker thread dans linux?
[^] # Re: Merci Apple.
Posté par Brioche4012 (site web personnel) . Évalué à 5.
[^] # Erreurs de calcul...
Posté par Zenitram (site web personnel) . Évalué à 10.
Hum... ou alors c'est que ton outil est faux.
Exemple appliqué à moi-même :
sloccount MediaInfo_CLI_GNU_FromSource
Total Physical Source Lines of Code (SLOC) = 96,167
Development Effort Estimate, Person-Years (Person-Months) = 24.17 (289.99)
Je n'ose pas afficher le coût estimé tellement il est énorme.
24 années affichées par l'outil, pour une personne, sachant que je suis seul à 99% et que mon propre calcul amène plutôt à 4 ans mis bout à bout (phase d'apprentissage du C++ inclus), ça fait une erreur d'un facteur de 6 quand même!
sloccount (un projet de développement que j'ai commencé il y 10 jours)
Total Physical Source Lines of Code (SLOC) = 5,618
Development Effort Estimate, Person-Years (Person-Months) = 1.22 (14.70)
1.2 an affichés par l'outil pour 0.05 années (un demi-mois) de travail, facteur de 30! Et j'ai bien fait attention d'enlever tout ce qui est généré automatiquement (Qt...) sinon le chiffre explose encore plus, et si je prend le répertoire source uniquement (hors fichier de configuration configure.ac et compagnie), il en reste toujours 6 mois de travail estimé.
Un facteur de 6 ou 30 entre l'estimé et le réel sur deux cas de tests, ça remet quand même beaucoup en cause la pertinence des valeurs de l'outil que tu utilises... A prendre avec des pincettes géantes, ou sinon dire que je suis génial, j'ai fais un don de plusieurs millions de $ à la communauté moi aussi (sic).
(...) donné a la communauté
Le don n'est absolument pas gratuit, le but étant juste que la technologie se développe partout, car Apple sait très bien que si ça reste que pour Mac OS X, les développeurs ne l'utiliseront pas, et donc que l'avantage de son OS ne sera pas utilisé. "Donné" n'est pas vraiment le bon mot... Je dirais plus "fourni pour que déployer sur les autres OS revienne moins cher à Apple". C'est donnant-donnant.
(note: je ne remet pas en question le gain qu'Apple apporte à la communauté, juste qu'il faut bien savoir que ce n'est pas un don" sans arrières pensées.)
[^] # Re: Erreurs de calcul...
Posté par Jak . Évalué à 10.
Autre possibilité : les développeurs sont tous des branleurs qui passent leur temps à fumer des pétards et à jouer au baby-foot. D'où les temps indiqués. CQFD
[^] # Re: Erreurs de calcul...
Posté par zebra3 . Évalué à 10.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Erreurs de calcul...
Posté par gallenza . Évalué à 4.
Tu évalues le code de manière biaisée.
Le facteur 6 à 30 couvre de manière honnête la "pertinence" du code.
Pour les 20 lignes de code que j'ai rajouté à txt2tags il y avait pas loin d'une année entière de réflexion sur ce genre d'outils, ce à quoi ça pouvait servir, ce qu'il y manquait, etc...
En parlant d'un outil aussi complexe que la gestion des threads au niveau d'un OS et des problèmes de parralélisation du code, je pense que l'implémentation est beaucoup moins importante en terme de temps de travail, que le développement d'un design efficace et novateur au fait des dernières recherches en la matière.
[^] # Re: Erreurs de calcul...
Posté par Zenitram (site web personnel) . Évalué à 7.
Ces deux choses, le programme ne le connait pas. Si j'avais pris le temps de codage uniquement, le rapport entre pourrait passer à 100...
Tout ce qu'on peut conclure de notre discussion est qu'il est impossible à un logiciel de calculer le prix d'un développement sans qu'il ai accès au CVS/SVN/GIT et à notre cerveau (pour savoir combien de temps on a réfléchi dessus!).
Bref, par design, ce genre de logiciel est faux, et ne peut même pas donner d'approximation.
[^] # Re: Erreurs de calcul...
Posté par Jean B . Évalué à 1.
Sans déconner ?
Constructive_Cost_Model
[^] # Re: Erreurs de calcul...
Posté par lasher . Évalué à 2.
Évidemment je fais exprès de prendre un cas extrême. L'autre bout de la chaîne serait du code généré à 90% par un IDE (génération des setters/getters, refactorisation de code semi-automatique, etc.). Sans parler que quand un modèle essaie de parler de « mois-hommes » je pense directement au « Mythical Man-Month » de Brooks.
[^] # Re: Erreurs de calcul...
Posté par Sylvain Sauvage . Évalué à 2.
Non, ce genre de logiciel n’est pas faux.
Tu l’utilises pour des petits projets (100 lignes) alors qu’il a été conçu pour des gros projets (plusieurs milliers).
[^] # Re: Erreurs de calcul...
Posté par Zenitram (site web personnel) . Évalué à 3.
Je t'invite à relire le chiffres que j'ai fourni, le logiciel que j'ai testé (le mien) ayant 3x plus de lignes de code que GCD, et répond à ton critère (est que 96 000 lignes est bien "plusieurs milliers"?), et ça donne un facteur de 6.
Je l'ai testé aussi sur un petit projet, mais celui-ci aussi répond à ton critère (6 000 lignes, c'est pour moi "plusieurs milliers"), bien que je conçoit à 100% que c'est un petit projet (10 jours, c'est rien!)
Non, ce genre de logiciel n’est pas faux.
Bon, peut-être pas faux, mais l'utilisation brute qui en a été faite pour mesure GCD est lui fausse.
Tu parles dans ton autre message des valeurs de paramétrage, qui ont sans doute une très grande importance.
Mais si il faut passer tout le temps à choisir ces valeurs, qui dépendent énormément de chaque développeur (comme le dit gallenza, on peut passer 1 an pour 20 lignes de code... Ou 10 minutes), l'intérêt des chiffres fournis est très discutable.
Dans quel cas est-il utile? Certains en voit l'utilité (sinon il n'existerait pas), j'en ai perso de gros doutes tellement des éléments extérieurs au code peuvent changer la donne, et ça aucun logiciel ne peut le savoir.
En tous cas, tirer des conclusions ("1 Million de $ donné par Apple" auquel je répondais), c'est un peu étrange à moins d'être sûr que les paramètres sont bons (et comment on sait ça?)
[^] # Re: Erreurs de calcul...
Posté par Sylvain Sauvage . Évalué à 3.
Oui, désolé, j’ai mal lu. 96000 lignes, ça fait effectivement un projet sur lequel c’est applicable.
Pour le reste de ton message :
Paramètres : COCOMO prévoit trois modèles de base (cf. l’article Wikipedia). Bon, celui utilisé par sloccount par défaut est le modèle « simple » (programme sans difficulté), donc celui qui donne la plus petite valeur. (En fait, l’écart entre les trois modèles est assez faible.)
En réalité, il y a plus que le simple nombre de ligne de code qui entre en jeu dans COCOMO (cf. les articles français et anglais pour voir l’usine à gaz).
À noter aussi que le principe est de calibrer le modèle suivant ses propres projets (on prend les anciens et on trouve un ratio à appliquer pour les suivants).
Utilité : d’abord, le but est prévisionnel, donc utilisé a priori, pas a posteriori. Il doit servir aux mêmes qui pensent que compter les trombones est une bonne méthode de gestion. Ça les rassure d’avoir un alibi mathématique. (C’est un modèle statistique, hein, on sait tous ici ce que ça veut dire…)
Le modèle doit être assez correct pour les développements en équipe.
Conclusion : oui, la déduction est fausse. Ça permet d’évaluer combien ça coûte(rait) de réaliser un logiciel du même nombre de lignes de code. P.ex. ça ne dit pas combien Apple aurait gagné à le vendre (si quelqu’un avait voulu l’acheter), donc combien Apple perd(rait) à le donner. Ça ne compte pas non plus combien Apple gagne en le donnant (pub, instauration d’un standard de fait, etc.).
[^] # Re: Erreurs de calcul...
Posté par totof2000 . Évalué à 2.
Une ligne en Perl peut avoir demandé plus de réflexion que 100 lignes de code C.
[^] # Re: Erreurs de calcul...
Posté par Troy McClure (site web personnel) . Évalué à -1.
[^] # Re: Erreurs de calcul...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Erreurs de calcul...
Posté par auve . Évalué à 2.
[^] # Re: Erreurs de calcul...
Posté par totof2000 . Évalué à 3.
[^] # Re: Erreurs de calcul...
Posté par Sylvain Sauvage . Évalué à 2.
Et oui, ils n’ont utilisé que des résultats finals. Or le code évolue, des parties sont constamment réécrites, peaufinées. Prendre le nombre de ligne de code écrites (donc y compris celles qui ont été écrasées ou supprimées) serait sans doute une meilleure mesure. Ça marcherait en tout cas beaucoup mieux pour les petits projets (comme ceux sur lesquels Zenitram voit ces facteurs de 30).
Utiliser les données des VCS pourrait sans doute permettre d’avoir de meilleurs estimations. On imagine aussi que l’accès à ces données n’est pas toujours facile de l’extérieur pour des produits commerciaux.
# C'est plutôt: "Apple ouvre Grand Central Dispatch".
Posté par NickNolte . Évalué à 4.
suivez mon regard -> Gallium3D
Ce n'est pas parce que nous sommes libristes et pragmatiques qu'on ne peut pas avoir de goûts.
Bon, oké on a JACK :)
---->>>>| aïe!
[^] # Re: C'est plutôt: "Apple ouvre Grand Central Dispatch".
Posté par loufoque . Évalué à -1.
Les noms d'Apple c'est la classe ?
C'est plutôt la grosse crise de mégalomanie.
[^] # Re: C'est plutôt: "Apple ouvre Grand Central Dispatch".
Posté par GeneralZod . Évalué à 10.
C'est pas si mal choisi, l'analogie entre la gestion des trains et celles des threads est frappante: ordonnanceur/gare, files/voies, tâches/trains, nombre limité de voies/threads disponibles etc ... Je ne sais pas si c'est mégalomane, mais j'y verrais plutôt l'ambition de faire de GCD le framework de programmation concurrente la plus efficace possible.
En tout cas, c'est l'une des plus élégantes.
[^] # Re: C'est plutôt: "Apple ouvre Grand Central Dispatch".
Posté par thedude . Évalué à -1.
c'est techniquement Grand Central Terminal et pas Station.
Grand central station est, au choix, le batiment usps a cote, ou une ancienne gare a chicago.
cf l'intro de l'article sur vikipedia: http://en.wikipedia.org/wiki/Grand_Central_Station
# Attention au français
Posté par rpnpif . Évalué à -4.
À part ce détail, cette dépêche donne une information intéressante.
[^] # Re: Attention au français
Posté par Pierre Carrier . Évalué à 1.
[^] # Re: Attention au français
Posté par Mathias Bavay (site web personnel) . Évalué à 0.
Apple vient de mettre, sous licence Apache 2.0, les principaux composants de Grand Central Dispatch :
Mais en fait, ta version ne me choque pas du tout...
[^] # Re: Attention au français
Posté par rpnpif . Évalué à 2.
[^] # Re: Attention au français
Posté par beagf (site web personnel) . Évalué à 3.
Ça me fait penser à un passage du livre «L'élégance du hérisson» de Muriel Barbery :
«Le chat dort.»
La lecture de cette petite phrase anodine n'a éveillé en vous aucun sentiment de douleur, aucun flamboiement de souffrance ? C'est légitime.
Maintenant :
«Le chat, dort.»
Je répète, pour qu'aucune ambiguïté ne demeure :
«Le chat virgule dort.»
D'un côté, nous avons ce prodigieux usage de la virgule qui, prenant des libertés avec la langue parce que d'ordinaire on n'en place point avant une conjonction de coordination, en magnifie la forme :
«M'a-t-on fait assez de reproches, et pour la guerre, et pour la paix...»
Et de l'autre, nous avons les bavouilleries sur vélin de Sabine Pallières transperçant la phrase d'une virgule devenue poignard.
[^] # Re: Attention au français
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 6.
« coeur » s'écrit « cœur ».
« blocs (closures) » Pour moi, « closure » c'est une « fermeture » ou une « clôture », mais pas un bloc. Je suis curieux de savoir d'où cette traduction vient.
« où sont stockés les tâches » -> « stockées », évidemment. Ou même « enfilées », tant qu'à faire. (Puis bon, la structure de la phrase complète est à revoir.)
« programmation concurrentes », c'est presque bien, mais sans le « s » à « concurrente », c'est mieux.
« expressions lambdas » serait « lambda expressions », sinon on a une belle ambiguité en français.
« de par l'intégration de celui-ci » -> « de par » c'est mal. Et c'est tellement plus simple à lire quand on dit « par son intégration », ou « grâce à son intégration. »
Voila qui signe la fin du commentaire chiant sur l'orthographe et la grammaire.
Vous pouvez donc à votre tour commenter mon commentaire, comme quoi j'ai mal écrit « ambiguité »
[^] # Re: Attention au français
Posté par Boa Treize (site web personnel) . Évalué à 6.
Elle vient de block, fortement utilisé dans GCD.
# Pour la programmation parallele, il y a aussi Pop-C++!
Posté par Mathias Bavay (site web personnel) . Évalué à 2.
http://gridgroup.hefr.ch/popc/doku.php
et http://linuxfr.org/forums/20/27417.html
Mathias
PS: et je suppose que les critiques qui aient été faites contre cette approche à l'époque de la dépêche citée plus haut sont toujours d'actualité vis à vis de GCD!
# Commentaire risqué
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -10.
C'est vraiment des **** chez Apple, ils respectent rien !
--
Les gens qui prennent mal ce post ont le droit de comparer à l'accueil d'une autre libération récente, en provenance de chez MS.
[^] # Re: Commentaire risqué
Posté par monde_de_merde . Évalué à 6.
[^] # Re: Commentaire risqué
Posté par pampryl . Évalué à 3.
Ce n'est pas un commentaire risqué, c'est un commentaire inutile.
# A quoi jouent les 2 plus grands géants du logiciel??
Posté par turanga leela . Évalué à -2.
Je trouve personellement qu'ils parlent un double langage.
Même si c'est une bonne nouvelle la libération de cette technologie, je me demande quand quel profit App£e peut en tirer.
Sinon merci pour cette dépèche très complète et facile à comprendre même pour une profane comme moi.
[^] # Re: A quoi jouent les 2 plus grands géants du logiciel??
Posté par Zenitram (site web personnel) . Évalué à 8.
Rien de caché, rien de bien vicieux :
- Microsoft cherche à ce que Windows soit bien supporté par les OS tiers, afin de faire la pub "ma solution de virtualisation est cross-platform, elle passe partout"
- Apple cherche à ce que l'interface Grand Central devient un standard de fait, et comme il maitrise la technologie il pourra dire que Mac OS X est mieux adapté pour la performance.
C'est le jeu, la saine concurrence entre différents acteurs, chacun des "fournisseurs d'OS" cherche à ce que son OS soit le meilleur dans tous les domaines, et pour ça il faut un support des outils tiers.
[^] # Re: A quoi jouent les 2 plus grands géants du logiciel??
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Bref, il y a plein de bonne raison pour ne pas garder cela pour soit, surtout lorsqu'on est pas en position de monopole.
[^] # Re: A quoi jouent les 2 plus grands géants du logiciel??
Posté par djibb (site web personnel) . Évalué à 3.
1) celui qui maîtrise le mieux la vente liée
2) celui qui maîtrise le mieux l'enfermement matériel
Après, le contenu en lui-même...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.