Discussion :

[bruce-willis]

Bonjour,

Je vois rarement des tutos sur le multithreading, surtout en Dotnet
On avait déjà développé un progiciel avec Dotnet WPF qui propose beaucoup de fonctions dont certaines gourmandes en temps mais ça marche plutôt bien sans avoir pensé à utiliser plusieurs threads
En jettant un oeil dans taskmgr, on voit que le logiciel utilise plus de 3 threads, je ne sais pas comment mais peut-être à cause de certains composants tiers

Développer en multithread est-il obligatoire pour un bon logiciel? Est-ce géré automatiquement par le compilateur?

[LGnord]

Salut bruce-willis,

Ta question est très pertinente et je me la pose souvent.

Selon moi, développer en multithread est obligatoire. En effet, la crise des multi-cores est là. Les logiciels vont devoir suivre. Ceux qui tarderont trop à le faire perdront beaucoup.

Par contre, la question des outils pour programmer les multi-cores reste entière. Même les developpeurs expirmentés ont des problèmes avec les threads. Je n'ose même pas parler des jeunes diplomés.

Tu parles de Dotnet mais à ma connaissance le problème existe aussi dans le monde Java.

Je suis aussi prenneur de tous bons plans.

[meziantou]

Je vois rarement des tutos sur le multithreading, surtout en Dotnet

En effet il n'y en a pas beaucoup.

Développer en multithread est-il obligatoire pour un bon logiciel?

Tout dépend du programme. Une petite calculette n'a pas besoin de multithread car les traitment sont tous très court. Cependant lorsque tu fais des traitements un tout petit peu trop long (2s ou plus) il vaut mieux utiliser les threads pour éviter de faire penser à l'utilisateur que l'appli plante.

Même les developpeurs expirmentés ont des problèmes avec les threads

La programmation multithread n'est pas aisée, elle entraine souvent beaucoup de problème inexistant un monothread.


Cependant je trouve que MS fait beaucoup d'effort pour faciliter la tache, surtout avec le framework 4 et la TPL (Task Parallel Library).
Il existe plusieurs outils pour valider le comportement du multithread : Chess, TypeMock racer, etc

http://site.typemock.com/typemock-racer
http://research.microsoft.com/en-us/projects/chess/
http://www.codeproject.com/KB/Parall...llelIntro.aspx

[xian21]

Avec le framework 4 il y a plink qui apparament gere tout seul le multi threading.

[bacelar]

Il faut toujours concevoir en pensant au parallélisme, multi-core ou pas, et cela depuis l'existence de noyaux préemptifs (Win95, ...).

Le langage, les Frameworks , les outils ne font que simplifier l'implémentation.

.NET offrent énormément d'outils pour le parallélisme. Cherchez bien.

[ClaudeBg]

Salut
-----

Ben moi j'ai un avis intermédiaire, à savoir que l'intérêt du multithreading dépend de l'application et même de quelle partie de l'application on parle.

L'utiliser systématiquement peut mener à un gaspillage inutile de ressources et même de performances, sans compter le coût en développement et debuggage, mais ne jamais l'utiliser peut également induire une perte de performances. Bref, ça doit être étudié au cas par cas et ça me semble assez "instinctif" : Si on a un process qui "vit sa vie" de façon autonome en communicant avec le reste de l'application qui continue de son côté, c'est clairement une bonne raison de l'utiliser.

Concernant les multicores, il est clair que d'après moi c'est une solution "bricolée" pour satisfaire la demande de processeurs plus rapides à laquelle la technique ne permet provisoirement pas de répondre, et qui amène un gros gaspillage puisque X cores à Y Mhz ne donnent pas X fois plus de performances qu'un core unique à Y * X Mhz, mais consomment par contre d'avantage. C'est principalement commercial : hors de question de dire qu'on n'avance plus, ce qui amènerait l'utilisateur à ne plus changer de PC.

Ca me semble quand même plus élégant d'avoir un moteur suffisant dans ma voiture que de me "coltiner" deux moteurs, un pour chaque roue avant, avec chacun leur pédale d'accélérateur (c'est à ça que ça me fait penser). On a beau ajouter le framework qui coordonne les deux accélérateurs, ça reste quand même plus lourd qu'un seul moteur suffisant pour rouler normalement. Sans compter que lorsque j'aurai 4 moteurs, un par roue, on aura beau m'en ajouter ils ne serviront plus à grand chose.

Sans compter que la Ram se voit adressée par plusieurs noyaux et qu'elle aussi est limitée, ainsi que toutes les autres ressources physiques. On fait quoi alors, on relie 2 PC ensemble sur le même écran pour avoir tout en double? Et ça s'arrête où?

Le plafonnage des cadences est dû à une limite technique dans la technologie actuelle, mais il est évident que la limite en MIPS sera vaincue dès qu'on décidera de changer cette technologie (processeurs optiques ou semi-biologiques, ou à nanotechnologie etc) voire inversément par des processeurs encore "plus CISC" qui pourront travailler sur du code machine plus proche du code source et donc plus rapides en nombre de lignes sources exécutées par seconde (ce qui intéresse le développeur en fait).

Le problème c'est que migrer de technologie c'est cher pour les entreprises et qu'en plus on arrive juste maintenant à commencer à maîtriser ces technologies. Donc, tant que les utilisateurs sont contents d'avoir une pseudo-vitesse supplémentaire par accroissement des noyaux l'industrie ne se casse pas le c*l et vend ce que l'utilisateur achète (sans trop se plaindre, il faut l'avouer, du reste quel est l'utilisateur "standard" qui y comprend réellement quelque chose?), en reportant de plus la lourdeur de l'astuce sur le programmeur.

Ca ne peut être que provisoire, parce que forcément déjà avec 4 noyaux on ne sait pas tous les utiliser dans 90% des applications (vous en avez, vous, des codes qui ont besoin de 4 cores?), alors lorsqu'on en sera à 512, j'imagine qu'on sera de toutes façons bloqués en performances depuis Belle-Lurette et Gay-Luron réunis.

Sans compter que plus on switche entre noyaux plus on perd en performance et donc à un moment le gain est négatif, sauf à avoir un partage dynamique des instructions câblé hardwarement mais de nouveau c'est un changement de technologie ou ça revient à faire du préload, ce qui est déjà fait et présente évidemment ses limites (impossibilité de prévoir d'avance les ruptures de séquences).

Bref, je dirais : Multithreading : intéressant pour les applications qui font tourner des "entités" autonomes dialoguant entre elles (messages, signaux, sémaphores etc), et mal nécessaire pour l'instant dans certaines applications à cause de l'apparition des multicores. A utiliser avec pertinence et si le gain obtenu est réellement positif (et utile).

Je parle PC évidemment, pas applications industrielles temps réel où le contexte est différent.

A+
Claude