Apple libère Grand Central Dispatch

Posté par . Modéré par Bruno Michel.
Tags :
15
12
sept.
2009
Apple
Apple vient de mettre sous licence Apache 2.0 les principaux composants de Grand Central Dispatch :
  • 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.
Grand Central Dispatch (GCD) est avec OpenCL l'une des technologies phares de Mac OS X 10.6 (aka Snow Leopard).
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 ...
  • # Merci Apple.

    Posté par . Évalué à 2.

    $ sloccount libdispatch/trunk
    [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 (page perso) . Évalué à 5.

      La prochaine fois, vous pouvez le virer dans mon compte en banque directement?
    • [^] # Erreurs de calcul...

      Posté par (page perso) . Évalué à 10.

      1 million de dollar donné (...), c'est pas mal!

      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 . Évalué à 10.

        * Hum... ou alors c'est que ton outil est faux.

        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 . Évalué à 10.

          C'était un communiqué du CCD, le comité contre les développeurs.

          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 . Évalué à 4.

        C'est peut-être toi qui oublie beaucoup de chose.
        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 (page perso) . Évalué à 7.

          Dans mon calcul du temps passé, j'ai aussi pris en compte le temps passé pour trouver les algorithmes, ainsi que les ré-écritures de code.
          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 . Évalué à 1.

            Bref, par design, ce genre de logiciel est faux, et ne peut même pas donner d'approximation.
            Sans déconner ?
            Constructive_Cost_Model
            • [^] # Re: Erreurs de calcul...

              Posté par . Évalué à 2.

              Oui, et ? J'ai passé 1 an et demi sur un noyau de calcul. À tout péter, je dois avoir au final 50 lignes « utiles ». Sauf qu'en fait, la moindre modif de code implique une différence importante en termes de perf. Comment tu évalues ça ? :)

              É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 . Évalué à 2.

            (Zut, j’aurais dû recharger avant d’envoyer…)

            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 (page perso) . Évalué à 3.

              Tu l’utilises pour des petits projets (100 lignes) alors qu’il a été conçu pour des gros projets (plusieurs milliers).

              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 . Évalué à 3.

                Je t'invite à relire le chiffres que j'ai fourni,

                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 . Évalué à 2.

                Bah ..... Le ombre de lignes en lui même n'est pas pertinent .... Surtout si c'est du Perl.

                Une ligne en Perl peut avoir demandé plus de réflexion que 100 lignes de code C.
        • [^] # Re: Erreurs de calcul...

          Posté par . Évalué à 2.

          Les facteurs utilisés par COCOMO (les formules sont données par sloccount) sont empiriques (p.ex. puissance 1,05, puissance 0,38, ce ne sont pas des valeurs courantes). Ils ont pris des projets finis et ont essayé de faire coller des formules pour relier les données ; p.ex. le temps passé au nombre final de lignes de code.

          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 . Évalué à 4.

    En tout cas, merci Apple, ça fait plaisir d'avoir accès à une telle techno et en plus qui porte un nom "classe". :)

    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 . Évalué à -1.

      En tout cas, merci Apple, ça fait plaisir d'avoir accès à une telle techno et en plus qui porte un nom "classe". :)
      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 . Évalué à 10.

        Le nom a été choisi d'après Grand Central Station une gare ferroviaire New-Yorkaise, c'est accessoirement la plus grande au monde.
        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.
  • # Attention au français

    Posté par . Évalué à -4.

    Une lecture rapide m'a fait lire qu'Apple avait mis Apache sous licence. Une virgule bien placée éviterait d'avoir des palpitations cardiaques inutiles. Bon d'accord, c'était absurde et le titre de la dépêche enlevait toute ambiguïté mais des tournures de phrases mieux léchées faciliterait la lecture. Je sais que c'est une faiblesse de trop de techniciens, informaticiens compris. Mais relire trois fois sa dépêche en se mettant dans la peau d'un novice serait un plus pour Linuxfr. Certains rédacteurs le font très bien.

    À part ce détail, cette dépêche donne une information intéressante.
    • [^] # Re: Attention au français

      Posté par . Évalué à 1.

      Tu peux me dire où tu mettrais la virgule ? En l'état ta suggestion m'a l'air vraiment moche.
      • [^] # Re: Attention au français

        Posté par (page perso) . Évalué à 0.

        je pense qu'il veut dire quelque chose comme cela:
        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 . Évalué à 2.

          C'est bien ça. L'idéal serait : Apple vient de mettre les principaux composants de Grand Central Dispatch sous licence Apache 2.0.
        • [^] # Re: Attention au français

          Posté par (page perso) . Évalué à 3.

          Cette formulation n'est plus vraiment correcte, une virgule ça ne s'utilise pas n'importe comment.

          Ç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 (page perso) . Évalué à 6.

      Bon, tant qu'à faire,

      « 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 (page perso) . Évalué à 6.

        > « 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.

        Elle vient de block, fortement utilisé dans GCD.
  • # Pour la programmation parallele, il y a aussi Pop-C++!

    Posté par (page perso) . Évalué à 2.

    En effet, Pop-C++ est une autre alternative possible et semble avoir un certain nombre de points communs avec GCD (du moins en terme d'objectifs et d'approche, Pop-C++ ne s'adressant qu'au C++ donc se basant sur des objets au lieux de blocks)

    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 (page perso) . Évalué à -10.

    J'espère que ces **** de gens d'Apple ont respecté la mise en forme du code du noyau linux en refilant leur code sale, car nous, les gens du logiciel libre, on n'est pas obligé du tout de les respecter d'autant plus qu'ils nous filent encore plus de code à maintenir dont on n'avait pas forcément envie.
    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.
  • # A quoi jouent les 2 plus grands géants du logiciel??

    Posté par . Évalué à -2.

    D'abord Micro$oft qui libère du code pour la communauté open-source puis App£e qui libère GCD puis à nouveau Micro$oft qui ouvre sa communauté open-source!!
    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 (page perso) . Évalué à 8.

      je me demande quand quel profit App£le peut en tirer

      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 (page perso) . Évalué à 3.

      c'est pas les plus grands géants du _logiciel_ , c'est :
      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.