Fermer

  • AgoraVox sur Twitter
  • RSS
  • Agoravox TV
  • Agoravox Mobile

Accueil du site > Actualités > Technologies > Puce multi-cœur contre programmeur

Puce multi-cœur contre programmeur

Étape majeure vers l’informatique super-intelligente, les puces à quatre, six ou huit cœurs donnent du fil à retordre aux programmeurs-développeurs.  

Histoire de cœurs

Les firmes techno évoquent sans cesse l’imminence d’environnements intelligents qui révolutionneront nos usages de l’informatique. Lenovo, Apple, Toshiba, LG et Nokia entrevoient déjà des ordinateurs et des mobiles cent fois plus puissants pour la prochaine décennie, la fin du tandem clavier-souris et le début d’interfaces multimédias capables de voir, de comprendre, de parler et de prendre des décisions complexes. Directeur recherche-développement de Microsoft, Craig Mundie affirme que « grâce à la puce multi-cœur, le PC deviendra enfin un vrai assistant personnel. La nuit, il triera mes e-mails prioritaires, analysera leurs contenus sémantiques, déterminera avec qui je dois correspondre ou non, établira deux ou trois brouillons de réponses pour chacun d’eux et me les soumettra à mon réveil pour validation ».

Reste à savoir si ces promesses hyperboliques seront effectivement tenues et comment le marché réagira face à ce déluge d’innovations. Cependant, nous avons constaté que la puissance hard est au rendez-vous : le Dual Core a vite fait oublier le Pentium 4. Les interfaces tactiles du iPhone et de ses émules doivent beaucoup aux double voire triple cœurs inside. Ce n’est qu’un début.

Depuis les années 60, les processeurs s’infinitésimalisaient perpétuellement pour une puissance constamment accrue. Toutefois, vers 2005-2006, les deux géants de la microélectronique furent confrontés à la surchauffe puis à la fusion des processeurs. D’où la fabrication de puces multi-processeurs (multi-core chips). Chaque processeur ou cœur étant inférieur/égal à ses ancêtres en termes de performances, la puce devient beaucoup moins énergivore, mais drastiquement plus puissante du fait d’une exploitation parallèle de tous ses cœurs. Point besoin de mettre la pression quand plusieurs canaux sont simultanément ouverts.

Les puces à quatre cœurs sont déjà disponibles, le Dunnington à six cœurs d’Intel équipe déjà les serveurs IBM, HP, Sun, Dell et Fujitsu-Siemens. Tout récemment, le géant de la micro a dévoilé son Nehalem à huit cœurs dont la commercialisation est prévue pour 2009. Grâce à son Turbo Mode intégré, le Nehalem met en veille les cœurs inutilisés et redirige l’énergie économisée vers les cœurs actifs (dont la puissance unitaire est augmentée par incrément de 133 Mhz), en toute transparence pour les applications courantes... A l’image d’un lanceur spatial dont les autres moteurs pousseraient un peu plus fort lorsqu’un d’eux s’arrête.

A terme, l’industrie microélectronique manufacturera de véritables orchestres sur silicone : au lieu d’une rangée de processeurs identiques, un ensemble de différents cœurs plus ou moins spécialisés. Dans ses prochaines puces, AMD combinera processeurs classiques et processeurs graphiques. La start-up micro californienne Tilera Corp prévoit l’apparition de puces à mille cœurs vers 2014.

Divers domaines comme la prévision météorologique, l’analyse financière, la modélisation-simulation à grande échelle, l’intelligence artificielle, la robotique, la traduction automatique, les jeux vidéo et la CAO bénéficieront amplement de ces micro-merveilles.

Le cœur du problème

Actuellement, les logiciels reposent sur un traitement séquentiel des données, profitant pleinement de la puissance linéaire des puces mono-processeurs d’antan. Pour faire de même avec les puces multi-cœurs, les logiciels devront effectuer des traitements parallèles/distributifs entre les différents processeurs en fonction de leurs différentes specialités. De telles optimisations ne sont certes pas indispensables pour un traitement de texte ou un navigateur internet, mais le deviennent pour un outil de modélisation climatique, un logiciel d’édition DVD, un mobile multimédia à écran tactile ou un jeu vidéo massivement multi-joueurs.

A ce jour, la programmation en parallèle, thème classique de la science informatique, demeure réservée à quelques aficionados et à la recherche de pointe.

Afin que leurs incontournables partenaires soft rattrapent le coche, les industries hard puisent à grandes brassées dans leurs cassettes. En mars 2008, Microsoft et Intel ont chacune fait don de 10 millions de dollars aux universités de Berkeley et de l’Illinois afin que celles-ci développent des logiciels parallèles pour les ordinateurs et les mobiles. Sun Microsystems, NVIDIA, AMD, HP et IBM ont versé des sommes avoisinantes à l’université de Stanford qui créa consécutivement le Pervasive Parallelism Lab. Celui-ci fédère développeurs chevronnés et débutants autour de la programmation en parallèle et élabore une matrice programmatique, voire des solutions clés en main pour les mondes virtuels, la robotique et l’analyse de données scientifiques et financières.

A l’automne 2008, Intel publiera la version bêta de Parallel Studio, sa suite de programmation en parallèle pour puces à double/triple/quadruple cœurs, intégrable au Visual Studio de Microsoft. La firme de Redmond veut faire de Windows 7 le premier système d’exploitation véritablement dédié aux puces multi-cœurs... En espérant que ses ingénieurs et ses développeurs se réconcilient enfin avec la fiabilité, Vista n’ayant pas été très dolce pour plusieurs utilisateurs.


Moyenne des avis sur cet article :  4.77/5   (87 votes)




Réagissez à l'article

72 réactions à cet article    


  • TALL 27 août 2008 10:59

    A propos de Windows, personnellement j’attends toujours 1 à 2 ans avant d’acheter la dernière version, vu que Microsoft se sert toujours des 1ers clients comme cobayes smiley
    Et je n’achèterai même pas Vista.

    Pour Windows 7 par contre, il paraît que dès le début, le truc sera très performant grâce à de nouvelles techniques d’intelligence artificielle appliquées à la programmation. Un système révolutionnaire.
    Conséquence, dès les 1ères ventes, il y en aura sans doute pas pour tout le monde. On suggère donc de faire des réservations chez son vendeur habituel.
    Pour moi, c’est déjà fait ... smiley ... smiley


    • foufouille foufouille 27 août 2008 11:57

      a chaque c’est toujours le meilleur, en relite toujours plus bogue, incompatible et gourmand en ressources.

      seul xp fonctionne a peu pres. apres le sp1, sp2 merdique et bientot le sp3

      en plus pour le prix, pourrait y avoir plus de chose dedans


    • Stephan Hoebeeck Stephanesh 27 août 2008 14:06

      À tous les pauvres windowseurs

      Vive le Macintosh

      Continuez de vous faire chier avec les super programmes de la firme de redmond...

      La seule firme informatique qui dépense plus en promo qu’en développement...

      LOL


    • Siko 27 août 2008 18:53

      Stephanesh
      Euh, le mac actuellement est fait comme un PC, il n’est plus à base de MPC 7450 (POwer G4) qui avait une originalité architecturale assez impressionante (RISC), c’est maintenant un processeur intel (CISC, bien chiant) qui est donc exactement le même. D’ailleurs, est-ce qu’on peut faire tourner MacOs sur un PC ? Il me semble que non, mais je vois pas pourquoi ?

      Le mieux, c’est encore le gratuit et donc Linux !



    • kabreras kabreras 31 août 2008 13:37

      90% des bogues et des plantages viennet de conflits materiels / drivers, etc.

      Meme si les macs sont avec des puces intels, le controle d’apple sur les materiels / applications fait que ceux ci ne plantent pas.
      Ce n’est pas une histoire de puce.


    • pallas 27 août 2008 11:40

      Vivement que les machines deviennent consciente, avec notre technologie, vous avons reussie a crée des ordinateurs neuronaux capable d’apprendre et de ce developper tout seul, et c’est un bien, l’informatique devient pratiquement moleculaire, et donc la capacité des machines en devient tres grande, des calculs qui vont bientot depassé celui du cerveau humain. L’emergence de la nano technologie et les nano machines, vont accroitre encore un peut plus la capacité de nos machines, les rendant a breve echeance, maximum une 10 enes d’années, consciente et auto suffisante, ainsi, nous serons plus que des Etres obsolete, l’emergence d’une nouvelle espece, que nous avons fabriqué de nos mains, qui nous sera totalement superieur dans tous les domaines. Personnelement, j’attend sa avec impatience, sa sera bien plus interessant, car les Humains, sont des etres primaires pour la plupart.


      • foufouille foufouille 27 août 2008 11:59

        bientot matrix ou la revolte des robots...........


      • foufouille foufouille 27 août 2008 11:50

        interessant

        ca continuera tant qu’il ne trouveront pas une autre technique pour faire les puces

        par contre six puces doivent consommer enormement....


        • Siko 27 août 2008 19:12

          En fait, la technologie utilisée dans tout ce qui est numérique aujourd’hui, c’est le CMOS (transistors). Les CMOS ont la particularité de ne quasi rien consommer lorsqu’ils ne changent pas d’état, en fonctionnement leur consommation est proportionnel à la fréquence de changement d’état. 

          Vous avez donc raison puisqu’en augmentant le nombre de coeur, on augmente le nombre de transistors et donc à même fréquence, on augmente la consomation.

          Ceci dit un autre facteur est en prendre compte, la science des matériaux permet de réduire la taille de ces transistors au cours des ans(65 10^(-9) mètres pour la taille des éléments actuellement je crois), ceci a pour effet de réduire la consommation par porte car ça réduit la taille des capacités d’entrée des CMOS.

          Ca compense plus ou moins l’effet de l’augmentation de transistors sur la consommation.


        • pallas 27 août 2008 12:12

          Matrix, non, evidemment, cela dependra de la programmation de base qu’ont leurs incultera, rien de plus, si ont veux rendre nos machines violentes et agressives, pourquoi pas, mais si ont leurs donnent la capacité d’auto apprentissage, alors je ne pense pas qu’elles deviennent aussi Belliqueuse que nous les Humains, nous sommes des etres totalement imparfait, agressif, destructif, les enfants le sont instinctivement, c’est comme sa, si un jour nos machines veulent nous detruire, elles le feront, et deviendront maitre du monde. Apres tout, notre espece a detruit la planete, et detruit les autres especes et nous nous entre tuons, donc je ne vois pas le mal, d’une espece robotique voulant se defendre. Le jour ou la Machine deviendra consciente, nous voudrons la detruire, et celle ci reagira en auto defense, rien de plus, sa se passera comme sa et non inversement. De toute maniere, une machine est bien plus interessante qu’un etre humain, car celle ci est Logique, alors que l’etre humain a des pensées totalement illogiques, c’est tout.


          • floruf floruf 27 août 2008 16:26

            Sinon , à part Terminator , t’as rien vu d’autre récemment  ??


          • Traroth Traroth 27 août 2008 16:50

            Oui, tout dépendra de la programmation...
            Les robots autonomes existent depuis peu de temps. Et quelle a été la première application pratique ?

            http://fr.wikipedia.org/wiki/SWORDS

            Sans commentaire...



          • foufouille foufouille 27 août 2008 22:36

            un robot qui apprend devient intelligent......... et demande son autonomie


          • kolymine 28 août 2008 03:00

            y a encore beaucoup de chemin avant une vraie IA.
            mais la logique n’empeche pas la violence. si on etais logique on eradiquerais les humains pour que la biosphere ne disparaisse pas.
            Donc l’extase sur la logique....

            sinon en terme de puissance, je crois me souvenir qu’en R&D intel on aligner entre 30 et 300 processeur ensemble.

            au niveau de la capacité de calcul on peu d’ici tres peu de temps depasser le cerveau humain, mais ca reste sur des operations, logique, type 1 AND 1 , rien à voir avec des operations complexe (ne serait ce u’un calcul de virgule)

            on as le temps :)


          • Marc Bruxman 27 août 2008 12:12

            Attention, la puissance n’est plus du tout le critére principal lors du choix d’un microprocesseur. Pourquoi ? Parce que par exemple j’ai tout un datacenter en supervision et que mes machines se branlent la nouille pour la plupart. 

            C’est pour cela que les marchés "hots" sont la virtualization et le grid computing qui permettent de mieux utiliser les ressources hardware. Et par la même d’économiser en achat de serveurs et surtout en cout énergétique (et oui, un serveur même haut de gamme coute plus cher en courant électrique lors de toute sa durée de vie qu’il n’a couté à l’achat). Rajoutez à tout cela les problèmes de refroidissement (une clim pour salle serveur c’est très cher) et vous trouverez pourquoi en ce moment la course est à la performance par watt. Dans cette course, des bons systèmes de virtualization et de distribution sont plus importants que les innovations purement matérielles. Le mot clé serait donc plutot exploiter le matériel au mieux. Parce qu’au rythme ou on empile le hardware dans les différents datacenter de Paris, on va vers une impasse. Bref la aussi on va vers une réduction de la production physique, au profit d’une meilleure utilisation. 

            Maintenant ca, Intel ne va pas avoir trop envie de l’admettre car ce n’est pas bon pour les ventes de puces. Du moins pas bon pour les ventes de puces que vend Intel. La loi de moore continue à jouer, mais elle joue dans le sens de la miniaturization et de la réduction des couts. Les produits comme l’iPhone et l’eeePC sont ainsi trendy. Peu puissants mais ils rendent service. Alors que plus de puissance dans mon core2 quad et bien a part le jeu je n’ai pas beaucoup d’applications qui le justifient pour l’instant. (Si ce n’est le calcul scientifique). 

            Quand au fait de rédiger automatiquement un brouillon de réponse à un mail ce n’est pas tant la puissance de calcul qui manque mais des techniques d’intelligence artificielle. Même avec un supercalculateur, la compréhension du langage naturel est un probléme non résolu. (Ou du moins très imparfaitement résolu). 


            • Charles Bwele Charles Bwele 27 août 2008 12:30

              @ Marc Bruxman

              En effet, il y a deux visions qui semblent s’opposer : la vision plutôt matérielle "parallel computing" ou de Microsoft-Intel et la vision plutôt virtuelle "grid computing" de Google (cf. L’entreprise virtuelle agile). J’insiste sur le terme "plutôt".

              Pour ma part, je perçois de plus en plus d’indices de leur complémentarité/convergence à des fins d’optimisation des ressources hardware + software + netware. Je reviendrais sur ce point dans les qq semaines à venir.

              Amicalement smiley


            • Charles Bwele Charles Bwele 27 août 2008 12:35

              @ Philippe Renève,

              Vous avez qq explications simples et détaillées du grid computing dans cet article : L’entreprise virtuelle agile ,
              ainsi que ses multiples implications économiques, cybersécuritaires, entrepreneuriales, technologiques et professionnels.

              Amicalement smiley


            • HELIOS HELIOS 27 août 2008 12:55

              La reponse n’etant pas dans le lien, la virtualisation consiste a installer sur une machine, généralement puissante et dotée de beaucoup de memoire, un logiciel qui vient se rajouter juste au dessus de la couche materiele et du bios.
              Ce logiciel, par exemple VMWare, permet d’installer non pas un mais plusieurs OS par derriere, comme windows server 2003, les linux et certains unix etc... en partageant les ressources materielles. Chaque OS va se croire seul sur la machine physique...

              A quoi ça sert. Sur la puissance machine, cela ne sert a trien puisque le perimetre est constant, mais, sur la praticité cela est vraiment genial.

              Prenons un exemple (les chiffres ne sont pas a la mesure) : vous avez une machine capable de fournir 1000 transactions, si vous n’installez pas de virtualisation vous avez un seul client installé qui va utiliser seulement une partie de la machine si le dimensionnement a été fait de manière prudente.

              Si vous avez 3 clients qui desirent des serveurs pour 300 transactions, au lieu de mettre 3 serveurs, vous mettez 3 serveurs virtuels dans une machine unique.
              Vous economisez sur les serveurs mais aussi sur l’energie etc.... de plus vous pouvez equilibter les charges si un client depasse ses 300 transactions alors que les autres n’utilisent pas leur quota.
              Enfin, imaginez que le serveur devienne defaillant ou que le client veuille augmenter sa puissance, changer un serveur virtuel de machine c’est pratiquement comme faire la copie d’un fichier d’une machine a une autre... pas d’installation nouvelle etc...

              Voila c’est dit simplement, il y a d’autres avantages economiques, techniques etc, mais ceci est suffisant pour comprendre sans devenir ingenieur


            • Marc Bruxman 27 août 2008 13:13

              Bon et bien Helios et Charles ont bien expliqué avec pour Helios une vision plus technique et pour Charles une vision plus "opérationelle" avec de bonnes informations sur les conséquences que tout cela va avoir pour toute l’industrie. Rien à ajouter :) Si ce n’est que comme dit dans l’article sus-mentionné le génie de Google n’est pas tant leur moteur de recherche que leurs techniques de grid computing qui sont l’infrastructure de tous leurs produits. C’est cela qui rend le moteur de recherche possible. Et c’est cela qui met une vériable barriére à l’entrée entre eux et la concurrence. 


            • Ranjo 27 août 2008 15:47

              D’autant plus que la fiabilité des systemes comporte deux parametres qui influent toujours négativement dans le calcul d’un MTBF : La complexité et la température qui intervient au cube dans le taux de defaillance de composants electroniques.

              note MTBF = temps moyen de bon fonctionnement entre 2 pannes

              exemple Le MTBF d’un helico moderne comme le NH 90 est de 4 heures !! il faut dire qu’un helico c’est particulierement complexe


            • Traroth Traroth 27 août 2008 16:58

              Pour faire simple :

              Virtualisation : exécution simultanée de plusieurs systèmes d’exploitation sur une même machine, au sein d’une machine virtuelle, type VMWare, Virtual PC ou Xen
              Grille de calcul (Grid computing) : mutualisation de la puissance de calcul d’un réseau hétérogène (à la différence d’un cluster), c’est à dire sur lequel on peut trouver des machines de puissance très différentes, potentiellement du téléphone portable au super-calculateur. L’idée derrière le grid computing est de permettre l’utilisation de la puissance non-employée. C’est donc un système de calcul distribué.


            • blaz 27 août 2008 13:01

              concernant la programmation en parrallèle, effectivement, il ya comme un problème. Si le matériel est disponible pour effectuer des traitements en parralèle, nous n’avons pas de framework de développement (sauf celui cité qui s’intégrera dans le studio dot net) . Par ailleurs, comme le dit l’article, les techniques de développement ne sont pas encore très répandues parmi les développeurs en place dans les entreprises.
              Pour ma part, je suis développeur dans une grosse banque. Mon job consiste à maintenir et alimenter les entrepôts de données. Dans le cadre de mon travail, j’essaie de voir ou on pourrait bien mettre du traitement parralèle, mais honnêtement, je ne vois pas trop où. (mais il est fort possible qu’il me manque tout bêtement le niveau conceptuel nécessaire). Nos traitements sont massivement séquentiels pour la bonne raison, que le traitement N+1 s’appuie sur le résultat du traitement N. Ce chaînage des traitements est la résultante de ce qu’est le fonctionnel.
              Aussi, je me pose la question de savoir, si le traitement massivement parrallèle est applicable à tous les domaines du traitement de l’information. (il y aurait donc un travail à faire sur la conceptualisation, le passage du fonctionnel à la logique de prog. parralèle, snas compter la formation idoine pour les développeurs en place - comme à l’époque on a pu le faire avec la méthode merise appliquée aux bases de données )

              Par ailleurs, concernant le processeurs à 1000 coeurs, est ce vraiement réalisable ?
              Je prends l’exemple du threading en programmation java (ce qui est le début du traitement de données en parrallèle). Au dela d’un certain nombre de threads/processus lancés, la courbe de performance s’aplatit, car finalement le système passe plus de temps à gérer les accès en concurrence de tous les processus, voire à lancer et éteindre les différents processus que d’effectuer le travail en lui même (je sais c’est un résumé un peu grossier mais bon). Dans le cadre d’un processeur à 1000 coeurs, combien de coeurs seront uniquement dédiés à la gestion de l’ensemble ?

              Comme dit dans un autre commentaire, l’optimisation des ressources existantes est sans doute plus intéressante. Le grid computing pourrait même sauver la planète (soyons visionnaire smiley)) . prenez une tour à la Défense. Environ 3000 personnes y travaillent. Ce qui signifie, 3000 pcs, et mettons 500 serveurs. la nuit, les serveurs tournent à plein régime pour effectuer les traitements de données (par exemple l’intégration des flux d’informations des filiales de toute la planète, ce qui peut représenter 10Go de données à ingurgiter par nuit), pendant ce temps là, les 3000pcs, sont occupés à afficher l’écran de veille. en distribuant le calcul sur les 3000pcs, on pourrait faire baisser la pression sur les serveurs, rentabiliser au mieux les machines, et payer l’électricité du bazar pour autre chose, que les écrans de veilles (et au passage éviter de construire une centrale nucléaire pour alimenter tous les datas centers de paris par exemple).


              • Marc Bruxman 27 août 2008 13:32

                on pourrait faire baisser la pression sur les serveurs, rentabiliser au mieux les machines, et payer l’électricité du bazar pour autre chose, que les écrans de veilles (et au passage éviter de construire une centrale nucléaire pour alimenter tous les datas centers de paris par exemple).

                Pour mettre en lumiére les datacenters modernes (les derniers construits) sont construits sur une densité de 3kVA par métre carré. Soit environ 12 Ampéres (c’est une estimation, cela dépend du facteur de puissance de votre matériel) par métre carré. Sachant que ca, c’est la capacitée fournie au client. Par dessus, il faut mettre encore plus pour assurer la climatisation. (L’électricité fournie pour alimenter les serveurs est entiérement convertie en chaleur qu’il faut impérativement évacuer). Si vous coupez la clim dans une telle salle, il faut moins de 10 minutes pour que la température atteigne 50 degrés. La conséquence c’est que tout doit être redondant pour ne pas qu’il y ait de panne de clim. 

                L’espace dans une telle salle se loue mensuellement pour environ 1000 € du m2. (Prix variable selon votre négociation votre conso électrique réelle, la surface louée, etc, etc, ...).

                Maintenant que vous avez ces informations, il faut savoir que beaucoup de ces datacenters ont des surfaces utiles qui dépassent les 10 000 m2 et donc une consommation électrique absolument gigantesque. Et qu’actuellement une salle de 10 000 m2 se remplit de clients en moins de 4 ans. (Sachant qu’il y a de la concurrence dans toutes les capitales d’europe sur ce marché). A Paris, environ 4 grandes salles de ce type existent et il y en a également de plus petites (dont certaines dépassent les 3000 m2 quand même). De nouvelles sont actuellement en construction. 

                Rajoutez que construire a 3kVA le m2 est un challenge d’ingénierie. Des datacenters ouverts à la fin des années 90 étaient construits sur la base de 1 kva par m2. Et que malgrés cette augmentation de densité électrique, elle n’est toujours pas suffisante. Il faudrait construire avec un objectif de 6kVA/m2 et plus. Mais à partir de la, la seule solution devient le refroidissement liquide. (Des armoires ("rack") pour cela sont en vente). 

                Rajoutez encore que cette quantité d’énergie colossale doit être livrée avec la même priorité et la même sécurité que pour un hopital (les contrats auprès d’edf sont identiques) tant une panne de courant sur un de ces sites a des conséquences graves. 

                Et vous comprendrez que la meilleure rentabilisation du matériel est effectivement un problème complétement nécéssaire non seulement d’un point de vue environemental mais aussi du point de vue de l’ingénierie. La croissance actuelle des systèmes de traitement de l’information force à une utilisation optimale du matériel. Sinon elle ne sera rapidement plus soutenable. Mais ca tombe bien les solutions existent déja !



              • plume plume 27 août 2008 13:27

                et l’homme , c’est quand qu’il évolu ???
                 parce que avoir une technologie poussé pour dire : salut , MDR , LOL , A+
                 pour retouche une image de vacance au bord de l’eau
                ou joué au tennis en virtuel
                excuses moi mais c’est nul
                un exemple simple :
                internet est de plus en plus rapide , peut stocker de plus en plus d’information , réunir des personne des 4 coins de la planète , en clair un FORMIDABLE outil 
                mais il devient plat , bourré d’information inutile

                vous pourrez avoir une F1 si vous mettez un canard derrière le volant vous n’irai pas bien loin


                • Traroth Traroth 27 août 2008 17:02

                  Franchement, c’est un peu une tarte à la crème, ça. L’informatique, comme toute technologie, est neutre, tout dépend de ce qu’on en fait. En l’occurence, on utilise les nouveaux moyens informatiques pour "tchater" avec de parfaits inconnus sur des sites de rencontre, mais aussi pour la recherche médicale ou pour rester en relation avec les gens qu’on aime et qui sont loin. Comme pour toute activité humaine, le pire voisine avec le meilleur, sur Internet.


                • pallas 27 août 2008 13:58

                  C’est pour sa Plume, que l’homme est obsolete et qu’il n’a aucune utilité. Les machines sont Logiques et je ne pense pas qu’elles soient belliqueuse, l’homme crée une nouvelle espece, qui bientot le supplantera, deja sans les Machines, nous ne somms rien, quand celle ci, seront consciente, nous n’aurons plus la place en ce monde et je ne pense pas que cela soit un mal, bien au contraire.


                  • fb 27 août 2008 14:18

                    Mouaip, Charles tu as été plus inspiré dans d’autres articles...

                    Concernant la programmation parallèle massive, les multi-coeurs sont particulièrement inadaptés à cause des invalidations de cache inhérentes aux commutations de contextes engendrées. La nouvelle tendance en matière de programmation efficace consiste plutôt à aller vers l’asynchrone (multiplexage d’état non temporel) en opposition avec le paradigme venant d’Unix (un client égal un serveur égal un process ou un thread plus multiplexage temporel).
                    Intel veut faire croire que ses processeurs sont excellents et que les programmeurs sont en retard mais qu’un super outil de développement résoudra le problème, la réalité est loin d’être aussi simple.
                    S’il est vrai que les programmeurs doivent se faire violence pour tirer parti des qualités des processeurs multi-coeurs (et surtout pour éviter leurs défauts), malheureusement un très faible pourcentage sera en mesure d’intégrer des notions comme les spinlocks, futex, RCU, barrières... pourtant essentielles à la synchronisation des coeurs.
                    En revanche, l’intégration CPU+GPU pourrait donner lieu à des choses très intéressantes, mais en l’absence de normalisation entre Nvidia et ATI cela reste hypothétique sans compter que cela fait belle lurette que les serveurs n’ont plus de carte vidéo smiley

                    PS : désolé pour les acronymes divers et variés difficilement explicables en commentaires.


                    • Marc Bruxman 27 août 2008 14:43


                      Concernant la programmation parallèle massive, les multi-coeurs sont particulièrement inadaptés à cause des invalidations de cache inhérentes aux commutations de contextes engendrées.


                      Tout à fait. Il y a une différence entre multiprocesseur et multi-coeur. 

                      La nouvelle tendance en matière de programmation efficace consiste plutôt à aller vers l’asynchrone (multiplexage d’état non temporel) en opposition avec le paradigme venant d’Unix (un client égal un serveur égal un process ou un thread plus multiplexage temporel).

                      Ca aussi. Mais c’est baléze à coder. 

                      Intel veut faire croire que ses processeurs sont excellents et que les programmeurs sont en retard mais qu’un super outil de développement résoudra le problème, la réalité est loin d’être aussi simple.

                      Oui et Intel est coutumier de cette connerie. Ses processeurs Itanium (surnommés Itanic dans le millieu par référence à un célébre bateau) ont longtemps soufferts du manque d’outils de développement pour finir grosso modo à la poubelle. 

                      S’il est vrai que les programmeurs doivent se faire violence pour tirer parti des qualités des processeurs multi-coeurs (et surtout pour éviter leurs défauts), malheureusement un très faible pourcentage sera en mesure d’intégrer des notions comme les spinlocks, futex, RCU, barrières... pourtant essentielles à la synchronisation des coeurs.

                      Ca il faudra bien qu’ils l’intégrent. Mais c’est vrai que ce sont des notions pas évidentes. La formation la dessus est défficiente dans les écoles d’ingé. Et ils n’ont pas assez d’expérience en sortant. Mais ce sont des choses qui peuvent se régler sans problème si les écoles d’ingés veulent bien se remettre à faire de la technique plutot que des pseudos cours de management. 

                      Si elles ne le font pas et bien vous pourrez vous faire un gros salaire si vous savez faire ca (c’est déja le cas) et un moins bon sinon. 


                    • HELIOS HELIOS 27 août 2008 15:38

                      Tiens, je suis d’accord avec vous mr Bruxman, Les ecoles d’ingenieurs devraient recentrer leur formation ce sur quoi on les attend : la technologie.

                      pour refondre a Fb...

                      Cela dit, tout ce qu’on appelle l’Overhead (désolé, vous savez pourtant que je prefère le français) c’est a dire toute les tâches que le système (processeur ou OS) doit faire en plus que le traitement qu’on lui demande, par exemple pour gerer ses tâches, augmente avec le nombre de tâches justement et donc indirectement de coeur, même si on dedit un coeur a celui çi. Cela nous donne déjà une image de l’architecture a venir... a l’instar des moteur de formule 1 dont l’optimal en terme de cylindres semble etre limité a 10. 

                      En ce qui concerne donc les tâches dites "non parallèlisables" que vous citez dans les bases de données, vous vous trompez de "granularité" Lorsqu’on parle de parallèlisme, cela se situe au niveau d’operation bien plus elementaire et c’est justement dans ce decoupage que les methodes et formats de descriptions ainsi que les "compilateurs" ont toute leur puissance a reveler.


                    • tytouf 27 août 2008 15:45

                      La parallélisation n’engendre pas plus de changement de contexte, l’argument n’est pas valide. Quant à ce concept flou qu’est "l’asynchrone", encore faudrait-il l’expliquer. Enfin si c’est le "multiplexage d’état non temporel" c’est super, c’est justement ce qu’on recherche à faire par la parallélisation (qui je le rappelle est principalement de remplacer un travail T sur A puis sur B puis sur C puis ... par T sur A en même temps que T sur B en même temps que T sur C en même temps que ...)

                      Je pense FB, que vous confondez avec les problèmes de concurrence, distribution (voir votre discours sur les spinlocks et autres techniques de synchronisation). Car oui, les problèmes de concurrence génèrent des incohérences dans les caches qui sont coûteuses à réparer (invalidation du cache).

                      ... mais comme vous le dites, "la réalité est loin d’être aussi simple."


                    • dunlop 27 août 2008 16:04

                      Donc avec une librairie standard genre pthread, un seul core exécute tous les traitements du programme multithreadé, même si d’autres cores sont idle par ailleurs, c’est ca ?


                    • fb 27 août 2008 16:11

                      Le sujet est effectivement complexe, donc je précise ma pensée. En parlant de parallélisation massive je fais allusion au modèle dit des worker threads qui s’avère être une catastrophe, en cas de charge élevée les processeurs (multi-coeurs) passent leur temps à invalider leurs caches du fait des changements de contextes. Je ne critique pas le principe de la parallélisation d’algorithme avec point de rendez-vous c’est un autre (vaste) sujet.

                      En ce qui concerne le modèle « asynchrone », je reconnais que le mot est très mal choisi mais malheureusement c’est celui en usage. Pour prendre un exemple : celui d’un serveur web, il s’agit de faire un découpage événementiel en multiplexant sur les états des connexions ; dès qu’un paquet est reçu il est traité (même partiellement si toutes les données ne sont pas disponibles) et on repart dans la boucle événementielle. Il devient alors possible de maximiser l’utilisation des coeurs en créant un process par coeur plutôt qu’un process par connexion potentielle comme le fait le serveur web Apache.


                    • tytouf 27 août 2008 16:11

                      sauf si le système affecte les threads à un autre coeur ou bien que le développeur utilise l’API fournit par le système d’exploitation pour le faire.


                    • fb 27 août 2008 16:18

                      @dunlop,

                      Non. L’attribution d’un coeur à un thread est géré automatiquement par le noyau mais il est possible de suggérer l’utilisation d’un coeur particulier (sched_setaffinity()) . Néanmoins, les threads ne sont pas la panacée, les points de synchronisation peuvent coûter très cher, c’est pourquoi le développeur doit intervenir et faire un découpage intelligent pour répartir la charge, ce qui est loin d’être évident.


                    • dunlop 27 août 2008 16:23

                      Titouf

                      Ok, donc si le noyau ou l’API peut gèrer l’attribution du thread vers tel ou tel coeur, je ne vois pas en quoi la programmation multicoeur diffère de la programmation multiprocesseur, c’est transparent pour l’application.


                    • tytouf 27 août 2008 16:28

                      effectivement il y a toujours débat entre programmation multi-threadée et évènementielle, chaque méthode étant plus ou moins adaptée (facile à développer) pour telle ou telle tâche. néanmoins pour préciser un peu les choses :
                      1/ pour chaque méthode, il y a un changement de contexte :
                       - pour les threads c’est les registres processeurs dont celui contenant la pile
                       - pour l’évenementiel c’est l’évenement et sa continuation
                      2/ si les threads tournent dans le même espace d’adressage mémoire, il n’y a pas besoin d’invalider les caches. La différence de vitesse entre les deux méthodes est donc moins évidente.
                      3/ Apache gère plus ou moins toutes les configurations : mono-thread, multi-threadé, multi-processus.


                    • dunlop 27 août 2008 16:35

                      fb,

                      D’après le dernier papier que j’ai lu à ce sujet, les performances des deux modèles seraient équivalentes. Par contre, le modèle orienté thread serait plus intuitif, donc moins sujet aux bugs de programmation. Je vais essayer de retrouver le lien.


                    • tytouf 27 août 2008 16:36

                      @ dunlop

                      sauf quand le nombre de coeurs est supérieur au nombre de threads. Dans ce cas, il est souhaitable de pouvoir découper encore un peu plus son application. C’est là que les techniques de programmation parallèle ou distribuée sont nécessaires. Mais l’homme étant généralement faignant, c’est mieux que ce soit la machine qui s’occupe de ça.

                      Finalement, ces processeurs multi-coeurs servent pour des applications bien précises qui nécessitent beaucoup de puissances de calculs. Pour une utilisation traditionnelle, on devrait voir des processeurs multi-cores dont les coeurs peuvent être mis en veille. Ainsi l’utilisateur a de la puissance sous le capot sans pour autant consommer trop d’énergie.


                    • fb 27 août 2008 16:40

                      @tytouf

                      Pour le 1 non. Le processeur travaille en adresses logiques pas physiques, le changement de contexte implique le rechargement de tables (LDT, TSS) et de descripteurs de segments ce qui qui peut avoir un coût véritablement très élevé si ces données ne sont pas dans le cache L1, contrairement au modèle « asynchrone ».

                      2. Même remarque.

                      3. Apache en mono thread (ça fait deux ans que je n’utilise plus Apache) ? S’il y a un lien ça m’intéresse histoire de comparer avec Nginx pour rigoler.

Ajouter une réaction

Pour réagir, identifiez-vous avec votre login / mot de passe, en haut à droite de cette page

Si vous n'avez pas de login / mot de passe, vous devez vous inscrire ici.


FAIRE UN DON






Les thématiques de l'article


Palmarès