Discussion :

[kimz]

J'ai l'impression que dans le débat de la performance est concentré puissance des processeurs vs. puissance des machines, en faisant presque abstraction du rôle de la RAM, Hdd (heureusement que les E/S sont quand même discutées).

Loi de moore, avenir du parallélisme dans les futures architectures, je veux bien, mais aujourd'hui le développement de la RAM, pour ne prendre qu'un exemple, marche-t-il "en parallèle" avec la puissance des µProc ?

[gangsoleil]

Bonjour,

La loi de Moore porte uniquement sur le nombre de transistors dans un processeur, en indiquant que celui-ci double tous les 18 à 24 mois.

Cependant, les autres composants sont également touchés par cette loi, et suivent également des croissances du même type. C'est notamment le cas de la capacité mémoire.

[kimz]

Bonjour,

J'ai l'impression que [del]dans[/del] le débat de la performance est concentré puissance des processeurs vs. puissance des machines

Je me suis peut être mal fait comprendre (y a un *dans* de trop sur le début de ma phrase), je ne parle pas de la loi de moore en elle-même, son énoncé est clair, je parle de la tendance des gens à penser que la performance d'un PC ou d'un serveur est uniquement relative à la puissance du ou des microprocesseurs qu'il intègre

[gangsoleil]

Bonjour,

Tu as parfaitement raison : on se concentre trop sur le processeur, et pas assez sur le reste.
Aujourd'hui, trouver une machine équilibrée à un prix raisonnable (c'est-à-dire pas un PC de gamer) chez un constructeur est quasiment impossible : il y a toujours au moins un composant trop faible par rapport aux autres, qui déséquilibre la machine. Et ce composant n'est jamais le processeur.

Par contre, sur les serveurs, ce n'est pas vrai : ils sont globalement équilibrés, entre autre parce qu'ils intègrent moins de composants (pas de carte graphique 3D par exemple).

[davrous]

Etant donné que l'on va vers des archi type cloud (on va dire que le gros du travail est fait sur les serveurs, type web), le multi threading n'est pas obsolète ? Étant donné qu'on va être dans un cas ou des serveurs lancent en même en parallèle des applications linéaires, du coup au niveau performance ça revient au même.

Je m'étais renseigné pour savoir si sur une appli asp.net il était utile de faire du multithreading mais au final les réponses étaient plutôt négatives : le serveur s'en charge.

Après j'ai peut-être loupé quelques choses.

Hello,

C'est une remarque que j'entends souvent étant en charge de la relation technique avec les développeurs chez Microsoft sur les technologies Web & Cloud. Pourtant, même un développeur Web a intérêt à s'intéresser au développement parallèle pour toutes les bonnes raisons déjà citées dans ce thread. En effet, un développeur Web aura 2 choix dans une architecture Cloud pour gérer des pics de charge/améliorer les performances de son appli :

1 - augmenter le nombre de serveurs dédiés à son application en laissant la plateforme (ex: Windows Azure) lui attribuer davantage de ressources
2 - revoir son code et voir comment mieux tirer parti du hardware en analysant les sections parallélisables

L'avantage du point 2 est qu'il devrait lui couter moins cher en consommation/hosting s'il se débrouille bien. Ensuite, plus tard, une fois l'ensemble optimisé, il pourra envisager l'option 1 pour laquelle le cloud a été conçu. Sinon, il peut toujours opter pour la solution de facilité, mais elle va lui couter plus cher et son employeur ne va peut-être pas apprécier.

Les développeurs Web pensent souvent que le // n'est pas fait pour eux car ils assistent à des démos de calculs de Raytracing ou autres calculs complexes qui ont l'avantage d'être facilement parallélisable et très visuels pour faire comprendre aux gens l'avantage de ce mode de programmation. Effet pervers: on se sent moins concerné. Alors que l'on pourrait imaginer paralléliser des traitements sur la couche d'accès aux données, du traitement d'image côté serveur, des recherches en mémoire/base, etc. Mais bon, c'est sûr que ça en jette moins qu'un lancer de rayon avec des réflexions dans tous les sens! ;-)

Pour revenir sur l'ensemble du thread, je suis d'accord sur le fait que cela fait longtemps que les concepts // existent. Mais jusqu'à présent, ils étaient confinés à des usages et une population très réduite et spécifique. Le défi est de rendre accessibles ces concepts à la masse. Il aura donc un gros boulot d'éducation/formation mais également le besoin d'outillage et de nouveaux frameworks. Par exemple, chez nous, .NET 4.0/VS 2010 a eu un gros focus sur la simplification du développement //. Bien sûr, comme vous l'avais dit, il ne suffira pas de mettre ".EnableParallel = true;" pour bénéficier magiquement de tous les coeurs. Mais sur certaines parties, comme LINQ et son pendant P/LINQ, rendre // un parcours de fichier XML ou une collection en mémoire devient super simple. Il y a donc certainement une partie de la réponse du côté des frameworks. Il me semble d'ailleurs qu'il y a quelque chose dans le pipe pour la prochaine version de Java aussi. Nous avons également constaté (d'expérience!) que le debbuging d'applications fortement multi-threadées ou multi-tâches était un vrai cauchemar. Le simple fait de s'attacher à l'application changeant son état et empêchant de reproduire le bug pour le corriger... De ce côté-là, VS 2010 a également revu le debugger et il y a des projets de recherches innovant chez nous. Il s'appelle Chess : http://research.microsoft.com/en-us/projects/chess/ et vous pouvez trouver un bout d'explications en FR ici : http://blogs.msdn.com/ericmitt/archi...-et-chess.aspx

Pour terminer, vous avez oublié d'évoquer il me semble que la programmation parallèle va plus loin que la meilleure utilisation des CPUs multi-coeurs x86. Il va falloir également mieux utiliser en // les énormes capacités de traitement que nous offrent les GPUs et autres puces spécialisées. DirectX 11 apporte une première réponse de ce côté-là. Mais on pourrait imaginer un framework de haut niveau capable de distribuer les tâches sur les différentes puces en fonction de leur spécialisation.

Donc la loi de Moore est bien morte, mais on savait depuis longtemps que cela arriverait.

Bref, la programmation parallèle s'avère particulièrement passionnante et va tous nous faire bosser dans les années qui viennent avec le Cloud computing également. Profitez de votre prise de conscience avant-gardiste. Cette compétence va vite devenir critique sur le marché !

Bye,

David
PS : un membre de mon équipe anime un blog sur ce sujet : http://blogs.msdn.com/devpara/

[kimz]

(...)
Par contre, sur les serveurs, ce n'est pas vrai : ils sont globalement équilibrés, entre autre parce qu'ils intègrent moins de composants (pas de carte graphique 3D par exemple).

Je suis d'accord, de toute façon dans la majeure partie du temps les constructeurs offrent des serveurs entry sans composants spécifiques à l'intérieur, à charge du client de dimensionner selon ses besoins les RAM, RAID, HDD ...
Reste que pour le grand public, il faudrait plus de vulgarisation en rapport avec le calibrage, un système est un tout, par définition