IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement Windows Discussion :

Peu de conseil sur le multithreading, de grandes applis marchent sans cela


Sujet :

Développement Windows

  1. #1
    bruce-willis
    Invité(e)
    Par défaut Peu de conseil sur le multithreading, de grandes applis marchent sans cela
    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?

  2. #2
    Membre habitué
    Profil pro
    Inscrit en
    Février 2007
    Messages
    190
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 190
    Points : 153
    Points
    153
    Par défaut
    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.

  3. #3
    Membre émérite Avatar de meziantou
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Avril 2010
    Messages
    1 223
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2010
    Messages : 1 223
    Points : 2 439
    Points
    2 439
    Par défaut
    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

  4. #4
    Membre averti
    Homme Profil pro
    Développeur
    Inscrit en
    Septembre 2007
    Messages
    497
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vaucluse (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 497
    Points : 330
    Points
    330
    Par défaut
    Avec le framework 4 il y a plink qui apparament gere tout seul le multi threading.

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 047
    Points : 12 074
    Points
    12 074
    Par défaut
    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.

  6. #6
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    612
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2008
    Messages : 612
    Points : 1 050
    Points
    1 050
    Par défaut
    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

  7. #7
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 047
    Points : 12 074
    Points
    12 074
    Par défaut
    Une simple application avec une IHM réactive nous oblige déjà à faire du multithread.
    Donc c'est multithread ou multithread.

  8. #8
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    612
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2008
    Messages : 612
    Points : 1 050
    Points
    1 050
    Par défaut
    mouais, amusant, mais on se doute bien que sur ce type d'OS, multitâche en supplément, il y a forcément différents processus qui tournent.

    Sinon, moi je n'ai jamais été partisan des "il faut", ou des "on doit". Je suis partisan des démonstrations et des explications convaincantes, et de l'utilisation de son esprit critique.

    Les évènements de l'IHM sont gérés par l'OS, l'utilisateur ne s'en préoccupe pas et pour lui son programme n'est pas forcément multithread parce qu'on a un environnement réactif, et ce d'autant plus si les évènements sont de toutes façons resynchronisés sur le thread principal de l'application.

    Ce dont on parlait c'est bien évidemment de la nécessité ou non de lancer un ou plusieurs thread(s) supplémentaire(s) à partir du thread principal de son application, sinon la question n'a aucun sens.

    Quand moi je parle "multithread", je parle de lancer des tâches séparées qui vont vivre leur vie autonome et qui vont devoir dialoguer ensemble via divers mécanismes. Je ne parle pas de lancer un progress-bar ou une requête SQL en parallélisme.

    Et on peut faire un programme même complexe parfaitement réactif et parfaitement fonctionnel sans faire du multithread, tout comme on peut avoir un intérêt à en faire dans des circonstances bien spécifiques. Mon avis est et reste que décider si on doit ou non lancer des threads séparés (de façon explicite ou implicite) dans son application est à étudier au cas par cas.

    Le "temps" d'exécution n'a rien à voir, sauf si on parle de lancer un progress-bar (mais bon, si la vision du multithread se limite à ça, on ne parle pas de la même chose, LOL). Si un évènement demande 2 secondes ou même 20 secondes de traitement et qu'on a besoin de la fin du traitement pour poursuivre, alors le multithread sert à se chatouiller pour se faire rire.

    Pareil pour les requêtes SQL dont on nous abreuve de démos sur l'intérêt de les lancer en parallèle. C'est bien beau, sauf que on nous explique qu'il faut lancer la requête deux fois pour voir une différence (lol), vu le JIT, et on "oublie" évidemment de rappeler que lors de la seconde requête les informations sont dans le cache du disque dur, LOL. On "oublie" aussi allégrement que lancer plusieurs requêtes simultanément pour obtenir des infos se trouvant sur le même disque dur ce n'est pas toujours la meilleur façon de travailler efficacement avec ce disque dur.

    Ajoutons que tous les programmes n'utilisent pas de BDD, que la majorité des requêtes qu'on lance nécessitent d'obtenir le résultat avant de poursuivre, que le temps d'attente est moins le temps processeur que le temps d'accès des HD, et on commence à devenir circonspect. Ajoutons aussi que switcher entre threads représente un coût non négligeable en terme de ressources et de performances risquant d'amener un gain négatif.

    On a toujours utilisé du multithread lorsque c'était nécessaire même sur des processeurs à un seul noyau. C'était souvent pour des raisons de nécessité d'asynchronisme plutôt que de performances.

    Maintenant, avec les multicores on a un cas d'utilisation supplémentaire, c'est le cas où on désire utiliser plusieurs cores pour répartir un travail nécessitant des calculs ou opérations réalisées par le processeur complexes. Là, on peut gagner en vitesse de traitement, mais franchement ça doit concerner une petite minorité des applications (logiciels mathématiques ou de dessin etc), et dans ce cas, si le truc était "bien foutu", c'est la librairie mathématique qui s'occuperait de répartir le boulot, pas le programmeur qui n'a pas à savoir si la réponse à son calcul est faite par un ou plusieurs noyaux.

    Moi, je vois deux raisons de lancer plusieurs threads explicitement dans une application :

    1) Parce qu'on a besoin d'asynchronisme. Par exemple j'ai un programme domotique qui a besoin de poursuivre son traitement alors qu'il attend des informations spécifiques à partir du bus domotique, et donc les communications physiques tournent dans leur propre thread. Autre exemple, j'ai un programme de musique écrit sur un 68030 qui utilise 3 threads pour permettre le traitement temps réel des informations MIDI indépendemment de l'IHM et de l'affichage.

    2) Parce qu'on a des opérations complexes à réaliser et qu'on veut bénéficier de la puissance de calcul ou de traitement de plusieurs processeurs.

    Sinon, c'est que c'est un effet de mode plutôt qu'un besoin réel, et donc "non, ce n'est pas multithread ou multithread", ça demande un minimum de réflexion et d'interrogations.

    Maintenant, on nous dit qu'il faut faire du multithread vu qu'on a des multicores, mais en fait mon impression est qu'il faut surtout trouver une raison qui justifie d'acheter des processeurs multicores qui ne sont réellement utiles que dans une minorité de cas.

    Pour la question initiale, normal qu'il y aie peu de tutoriaux : lancer un thread est facile comme bonjour, la vraie difficulté est de garder une vision claire de la synchronisation de tout ce petit monde, et des échanges d'informations entre threads. Et ça, c'est difficile à expliquer dans un tutorial, c'est du raisonnement : on peut expliquer les méthodes existantes mais expliquer comment concevoir une application mulithread fonctionnelle c'est beaucoup plus compliqué, c'est comme si on voulait un tutorial expliquant comment programmer.

    A+
    Claude

  9. #9
    Membre habitué
    Profil pro
    Inscrit en
    Février 2007
    Messages
    190
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 190
    Points : 153
    Points
    153
    Par défaut
    Merci Claude pour ton point vue.

    Sinon, moi je n'ai jamais été partisan des "il faut", ou des "on doit". Je suis partisan des démonstrations et des explications convaincantes, et de l'utilisation de son esprit critique.
    Je connais des boites qui ont achetées des serveurs à 16 coeurs. Dans la réalité, un seul (parfois deux) coeur est utilisé. Elles sont en difficulté car même les applications devellopées en interne ne sont pas parallèlles.

    Je pense vraiment que ce cas de figure est fréquent. Comme le dit Claude, elles ont peut-être achetées 16 moteurs là où un seul était suffisant. Mais avaient-elles le choix?

    Toujours est-il que le logiciel a du mal à suivre cette évolution et qu'il existe peu d'outils|de tutoriaux pour aider le developpeur.

  10. #10
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 047
    Points : 12 074
    Points
    12 074
    Par défaut
    Même avec un seul moteur, il faut l'optimiser.
    Le multi-threading existait bien avant les multi-core et les SMP.
    Des outils et des Framework qui aident au développement multi-threadé sont pléthoriques et beaucoup ont fait depuis longtemps leur preuve.

    Il faut sortir un peu de sa coquille, les gars.

    Il n'y pas pire aveugle qu'une personne qui ne veut pas voir.

  11. #11
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    612
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2008
    Messages : 612
    Points : 1 050
    Points
    1 050
    Par défaut
    Le multi-threading existait bien avant les multi-core et les SMP.
    Je pense que c'est ce que j'ai dit, j'ai commencé à faire du multithreading sur un simple 68000.

    Des outils et des Framework qui aident au développement multi-threadé sont pléthoriques et beaucoup ont fait depuis longtemps leur preuve.
    Ca aide, mais ça ne remplace pas le cerveau du programmeur ni la bonne et saine réflexion à partir d'un cahier des charges. Dit autrement, ce n'est pas parcequ'un outil est proposé qu'il faut chercher à l'utiliser à toutes fins. On l'utilise lorsqu'on ressent le besoin de l'utiliser. D'autant plus que, je l'ai rappelé, la difficulté du multithread n'est pas de lancer un thread ni de communiquer (les outils sont bien là), la difficulté c'est de bien mettre tout ça en musique et de bien anticiper tous les cas de figures possibles.

    Plus il y a d'asynchronisme, plus le risque de bugs "aléatoires" et difficilement reproductibles augmente. C'est déjà le cas lorsqu'on commence à utiliser les interruptions dans des petits micros, alors lorsqu'on ajoute le multithreading on ajoute encore une couche "d'incertitude" au niveau des tests systématiques visant à découvrir les bugs.

    Il faut sortir un peu de sa coquille, les gars.
    Je vois mal qui, dans cette discussion a l'air de rester dans sa coquille.
    Moi, j'ai juste dit "oui pour le multithreading à partir du moment où c'est justifié et amène un bénéfice supérieur aux inconvénients.

    Il n'y pas pire aveugle qu'une personne qui ne veut pas voir.
    Justement, raisonner plutôt que d'affirmer ne me semble pas être la méthode de quelqu'un qui ne veut pas voir. Et comme je te l'ai dit, je n'hésite pas à utiliser le multithreading lorsque j'ai intérêt à le faire, mais de là à l'utiliser systématiquement sans raison valable, il y a une marge que pour ma part je ne franchis pas.

    Merci Claude pour ton point vue.
    Pas de quoi, ce n'était que mon avis, sachant que je suis un programmeur un peu atypique puisque la plupart de mes programmes concernent du pilotage temps réel d'applications électroniques.

    Je connais des boites qui ont achetées des serveurs à 16 coeurs. Dans la réalité, un seul (parfois deux) coeur est utilisé. Elles sont en difficulté car même les applications devellopées en interne ne sont pas parallèlles.
    Oui, on retrouve beaucoup ce genre de gaspillage en entreprise, souvent dû au fait que ceux qui décident des achats ne sont pas ceux qui vont utiliser le matériel. Ajoutons, il faut être lucide, que ceux qui achètent ont parfois tendance à se faire corrompre par ceux qui vendent, et on comprend bien des choses. Et je passe sur le syndrome du petit chef qui sait tout.

    Toujours est-il que le logiciel a du mal à suivre cette évolution et qu'il existe peu d'outils|de tutoriaux pour aider le developpeur.
    Le problème en fait c'est qu'on a beau multiplier les noyaux, ce n'est pas pour ça qu'on va arriver à scinder une application donnée pour qu'elle lance autant de threads (utiles) que de noyaux. Quand on augmente la vitesse d'un processeur, la plupart des applications en profitent immédiatement, alors que si on augmente les noyaux ça implique qu'on puisse en faire usage, ce qui est loin d'être systématiquement le cas. Lorsqu'on fait croire au client lambda qu'un 4 cores va faire tourner ses programmes "plus vite", c'est limite arnaque commerciale.

    Pour ma part, je pense que pour bien maîtriser le multithreading c'est assez intéressant de regarder Unix et d'étudier les mécanismes de communication genre signaux, sémaphores et messages. Quand on a bien compris ça, on commence à bien comprendre comment gérer l'asynchronisme et on voit plus instinctivement où l'utiliser. Quand je fais du multithreading, je prends une feuille de papier et j'essaye de représenter les mécanismes et les communications, ça aide beaucoup.

    Ensuite, on peut profiter des mécanismes mis à notre disposition par le framework pour simplifier l'utilisation dans des cas où on n'a besoin que d'un multithread "simple".

    A+
    Claude

  12. #12
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 047
    Points : 12 074
    Points
    12 074
    Par défaut
    Je pense que c'est ce que j'ai dit, j'ai commencé à faire du multithreading sur un simple 68000
    Pareil

    Sous n'importe quel Windows, ouvrez votre gestionnaire des tâches, allez dans l'onglet processus, faites afficher le nombre de thread par processus et vous verrez que les applications monothread sont les exceptions et les multithreadées la règle.

    Des frameworks pour la couverture de tests dans les cas multithread comme les l'utilisation de mutex, sémaphore etc existent ; rendant le debugging des problèmes de concurrence une formalité. Il faut juste prendre la peine d'utiliser les bonnes méthodologies (Agiles) et les bons outils.

    Les seuls types d'applications qui ne nécessitent pas de multi-threading, sous Windows, c'est les applications console de traitement en batch ou les parties servers d’applications multi-tiers (et encore).

    Avec une conception propre, le multitreading est toujours plus simple que le mono-thread (sauf pour les outils de batch).

    Pas de quoi, ce n'était que mon avis, sachant que je suis un programmeur un peu atypique puisque la plupart de mes programmes concernent du pilotage temps réel d'applications électroniques.
    Si c'est sous Windows, vous avez l'habitude des niveaux d'IRQ, des DPC etc., vous savez donc qu'une maîtrise du concept de thread et d'espace mémoire d'un process est primordiale. Vous faite vos drivers Windows dans un seul IRP et en niveau High IRQL ? Moi, je ne l'espère pas.

    Et je passe sur le syndrome du petit chef qui sait tout.
    La dernière fois que l'on m'a dit ça, c'était chez PSA et je fais +800% (de +3h30 à moins de 25 minutes) en performance en ajoutant 20 lignes pour pouvoir utiliser le deuxième CPU d'un Bi-Pro Xéon (pas d'hyperThreading ou autre octo-core), sur une application ASP.NET 1.1 qui était déjà optimisé à mort(dixit internes PSA ).
    Et cela sans aucune complexité puisqu'il suffisait d'utiliser le threadingPool de .NET et les caractéristiques des données (leur indépendance par atelier de montage)

    Lorsqu'on fait croire au client lambda qu'un 4 cores va faire tourner ses programmes "plus vite", c'est limite arnaque commerciale.
    Fox, Mulder, ce n’est pas le bon forum. Nous, on essaye de tirer le maximum de la machine avec le minimum de temps de développement. Point Bar.

    Donc, comme conclusion, oui, le multi-threading se justifie dans quasiment tous les types développements non triviaux.

  13. #13
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    612
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2008
    Messages : 612
    Points : 1 050
    Points
    1 050
    Par défaut
    Sous n'importe quel Windows, ouvrez votre gestionnaire des tâches, allez dans l'onglet processus, faites afficher le nombre de thread par processus et vous verrez que les applications monothread sont les exceptions et les multithreadées la règle.
    1) C'est inexact et de plus non représentatif parce qu'en majorité ce sont des services qu'on voit, et les services ne sont pas des applications représentatives de ce dont on parle. Sinon, de nouveau, ça dépend de ce que fait le programme et donc de la pertinence de lancer des threads (certains en lancent juste pour l'auto-update voir l'envoi de rapports sur le net, d'autres parce qu'il y a un intérêt, d'autres n'en lancent pas).

    2) Moi je ne regarde pas ce que font les autres pour savoir ce que je dois faire, j'y réfléchis par moi-même

    Des frameworks pour la couverture de tests dans les cas multithread comme les l'utilisation de mutex, sémaphore etc existent ; rendant le debugging des problèmes de concurrence une formalité. Il faut juste prendre la peine d'utiliser les bonnes méthodologies (Agiles) et les bons outils
    Le jour où on inventera un outil pour prévoir et corriger les bugs avec certitude il n'y aura plus de services pack ni de révision des logiciels.
    Je trouve que se reposer sur un outil pour la sécurité d'un logiciel est faire preuve d'un grave raccourci.

    Prétendre que le debuggage d'un programme multithread est "une formalité" c'est prendre pour des imbéciles ceux qui sortent des programmes présentant des bugs. Moi je suis plus humble car j'ai l'impression qu'il est même pratiquement impossible de sortir un programme conséquent en affirmant qu'il est dépourvu de bugs. En tout cas, moi, quand je distribue un programme je demande aux utilisateurs de me rapporter les bugs. Je ne dis même pas "s'il y en a" car je pars de l'hypothèse qu'il y en aura forcément.

    Les seuls types d'applications qui ne nécessitent pas de multi-threading, sous Windows, c'est les applications console de traitement en batch ou les parties servers d’applications multi-tiers (et encore).
    Je te trouve bien affirmatif : tu n'expliques rien, tu ne démontres rien, tu affirmes, et de plus tu assimiles toutes les applications n'utilisant pas le multithreading à des applications "primitives" ou définies dans un contexte particulier.

    En outre, tu n'envisages même pas qu'on puisse faire du dotnet sur autre chose que sur Windows. Tu sais qu'il existe maintenant des microcontroleurs de type ARM avec un framework dotnet préinstallé?

    Je trouve que ta vision du monde informatique est beaucoup trop restrictive.

    Je viens de terminer un logiciel de facturation pour un ami indépendant et il n'utilise pas de multithreading : il ne fonctionnerait donc pas convenablement? Pourtant, je sors de mon cadre habituel et j'entre dans un domaine de "gestion". Lancer les requêtes en multithread ne m'apportait rien, la BDD est sur un disque local et même avec 3000 factures les résultats sont instantanés vu par l'utilisateur (et il fait entre 1 et 10 factures par mois).

    Avec une conception propre, le multitreading est toujours plus simple que le mono-thread (sauf pour les outils de batch).
    A mon avis on ne doit pas parler de la même chose.
    Je vois mal sur base de quel principe il serait plus simple de lancer plusieurs threads et de les synchroniser plutôt que de n'en utiliser qu'un seul.

    Que le multithread se révèle utile ou même nécessaire dans certains cas, je suis bien d'accord, mais affirmer qu'il est plus simple de faire du multithreading que du monothreading me semble "curieux". Le multithreading nécessite de prendre des précautions supplémentaires concernant le synchronisme et donc de fait il complique le travail de "un peu" à "beaucoup" selon la complexité de ce multithreading. Mais "plus simple", là je trouve ça amusant.

    Quant à ton "sauf pour" je trouve que tu catégorises beaucoup le monde de l'informatique, à t'entendre on pourrait classer toutes les applications et tous les programmeurs en deux ou trois catégories maximum.

    Si c'est sous Windows, vous avez l'habitude des niveaux d'IRQ, des DPC etc., vous savez donc qu'une maîtrise du concept de thread et d'espace mémoire d'un process est primordiale. Vous faite vos drivers Windows dans un seul IRP et en niveau High IRQL ? Moi, je ne l'espère pas.
    Je vois mal le rapport entre un driver et le concept de multithread concernant une application autonome. Je rappelle que je parle de la pertinence de lancer explicitement plusieurs threads dans une application, disons "monobloc" (pour faire simple). Je n'ai pas dit que derrière, dans l'OS, il n'y avait pas du multithread sous-jacent.

    Je vois mal également le rapport entre des mécanismes d'interruption et du multithreading. Une interruption c'est une simple rupture de séquence asynchrone déclenchée par un évènement interne ou externe. En bas niveau, principalement sur du matériel embarqué, pratiquement tous mes programmes monothread utilisent une série d'interruptions différentes. Ce n'est pas parce qu'on utilise un ou plusieurs niveaux d'interruption dans un programme "linéaire" qu'on fait du multithreading, ça n'a strictement rien à voir.

    La dernière fois que l'on m'a dit ça....
    Je vois mal en quoi cette phrase te concerne, je répondais à LGnord qui disait qu'apparemment on n'achetait pas toujours du matériel pertinent en fonction des besoins de l'entreprise. J'ai dit ça parce que moi j'avais un "petit chef" qui se mélait de tout et qui n'y connaissait rien, et qui donc achetait cher du matériel qui ne servait pas toujours à quelque chose.

    et je fais +800% (de +3h30 à moins de 25 minutes) en performance en ajoutant 20 lignes pour pouvoir utiliser le deuxième CPU d'un Bi-Pro Xéon (pas d'hyperThreading ou autre octo-core), sur une application ASP.NET 1.1 qui était déjà optimisé à mort(dixit internes PSA
    1) Personne n'a jamais dit que tu n'étais pas compétent, c'est un sujet qui n'a rien à voir et de plus moi je ne juge personne, sans compter que je ne te connais pas.

    2) Personne n'a jamais dit non plus que si on avait des raisons de lancer un thread pour raison de performances il ne fallait pas le faire, j'ai même dit que c'était une des raisons d'utilisation possible. J'ai seulement dit qu'entre utiliser si c'est pertinent et prétendre qu'il faut systématiquement faire du multithread il y avait la place pour réfléchir posément à la pertinence de l'opération. Tu as lancé un second thread, pourquoi n'en as-tu pas lancé 2 autres? Ou 3? Ou 10?

    3) Entre utiliser un second processeur et en utiliser 16 (puisque c'est de ça dont il était question) il y a de la marge qu'il n'est pas facile de combler.

    4) La recherche de performances en utilisant un noyau supplémentaire n'est qu'une des raisons qui peuvent amener à faire du multithread.

    5) Ce qui est intéressant et judicieux pour une application donnée ne l'est pas forcément pour une autre application.

    Et cela sans aucune complexité puisqu'il suffisait d'utiliser le threadingPool de .NET et les caractéristiques des données (leur indépendance par atelier de montage)
    C'est du multithread "de base", comme lorsqu'on profite du parallélisme sur framework 4 pour lancer des requêtes SQL. Il y a des applications où le multithread demande bien plus de réflexion et bien plus d'échanges d'informations et de coordinations entre process, et là, ça se complique si on n'est pas rigoureux. Je le répète : oui il y a des mécanismes d'aide au multithread, surtout dans certains contextes particuliers, mais ça ne veut ni dire qu'on doit tout le temps les utiliser ni que le multithread se limite à ça.

    Fox, Mulder, ce n’est pas le bon forum. Nous, on essaye de tirer le maximum de la machine avec le minimum de temps de développement. Point Bar.
    Je te trouve bien présomptueux quand même de t'assimiler à l'intégralité du forum via ce "nous". Pour info, je fais aussi partie, du moins il me semble, du "nous" en question et je n'ai pas la même vision que toi de la chose. En lisant ce forum je n'ai pas eu l'impression d'y découvrir une espèce d'élite détentrice de la vérité suprême, j'y ai au contraire vu des gens qui donnaient des renseignements pertinents et argumentés.

    Moi je n'essaye pas de tirer le maximum de la machine en un minimum de temps de développement, j'essaye de résoudre avec le maximum d'efficacité et de convivialité pour l'utilisateur un problème donné tout en permettant à un maximum d'utilisateurs de faire tourner le programme sur le maximum de machines possibles.

    Celui qui écrit un traitement de textes n'en a rien à cirer de tirer le maximum de puissance de la machine: que l'utilisateur voie son caractère à l'écran en 10µs ou en 50µs ça ne change rien pour lui. Ben c'est pareil avec mes applications : quand j'intercepte et que je traite des trames CAN ça ne me sert pas à grand-chose de les traiter plus vite qu'elles n'arrivent, par contre ça m'intéresse si mon programme tourne sur le maximum de machines : chacun son cahier des charges et donc chacun ses solutions et ses méthodes.

    Tout le monde ne travaille pas dans une boîte sur un serveur donné à exploiter des bases de données dans une application réservée à l'entreprise.
    Il faut quand même garder son esprit ouvert et ne pas faire de son propre cas une généralité universelle. Quant au "point-barre", moi j'essaye de dialoguer de façon conviviale, sans agresser personne, et sans prétendre détenir la vérité universelle. J'ai donné des arguments objectifs, ils ne te conviennent pas et c'est ton droit. De là à tenter de clôturer par un "point-barre", tu es tombé sur la mauvaise personne.

    Donc, comme conclusion, oui, le multi-threading se justifie dans quasiment tous les types développements non triviaux.
    Je note donc que mes applications ne lançant pas une multitude de threads sont des applications triviales. Ca ne me vexe pas le moins du monde, mais si mes applications sont triviales alors ça démontre au moins que tu as tort en affirmant qu'il faut impérativement du multithread. Ben oui, une série d'applications triviales s'en passent fort bien (même si, je le répète, ça peut être intéressant), et rien ne dit que LGnord ne réalise pas des applications que toi tu juges "triviales". Je note donc en passant qu'un programme comme Orcad Capture cis (la suite coûte 10.000 euros) est un programme "trivial", puisqu'il ne lance qu'un seul thread, LOL, et évidemment il y en a plein d'autres.

    Bref, c'est TA conclusion, pas la mienne. Et tu conclus de plus sans avoir rien démontré de ce que tu affirmes, sauf en parlant d'un cas particulier que tu as mis en oeuvre dans un contexte encore plus particulier

    C'est ton droit d'avoir cette conclusion, c'est mon droit de ne pas avoir la même, je trouve donc le "point-barre" déplacé parce qu'il sous-entend que tu détiens la vérité absolue.

    Ma vision des choses après t'avoir lu, c'est que la conclusion, s'il devait y en avoir une, est fortement tributaire de la nature du genre de programme qu'on fait (la preuve, on n'a pas la même vision), et donc on en revient à ma remarque initiale : le choix dépend du contexte et de ce qu'on a à faire.

    Pour ma part, je persiste et je signe " Le multithread doit être utilisé lorsqu'il présente un intérêt, et non parce que c'est obligatoire, à la mode, ou parce que tout le monde fait comme ça".

    Du reste, pour faire mon "Mulder", comme tu dis, à force de faire "comme tout le monde", on voit où on en est arrivé aujourd'hui, LOL.

    A+
    Claude

  14. #14
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 047
    Points : 12 074
    Points
    12 074
    Par défaut
    1) C'est inexact et de plus non représentatif parce qu'en majorité ce sont des services qu'on voit,
    La majorité des services sont hostés dans des svchost.exe et la majorité des exécutables sont des résidents et non des services.
    De plus, les services sont une part très importante des logiciels sous Windows.
    2) Moi je ne regarde pas ce que font les autres pour savoir ce que je dois faire, j'y réfléchis par moi-même
    Cf. le nom du fil de message, et oui, toutes les applications d'envergures sur lesquelles j'ai travaillé ont profitées des avantages du multi-threading.

    Le jour où on inventera un outil pour prévoir et corriger les bugs avec certitude il n'y aura plus de services pack ni de révision des logiciels.
    Je trouve que se reposer sur un outil pour la sécurité d'un logiciel est faire preuve d'un grave raccourci.
    Ne déformez pas mes propos, les tests automatiques sont ma réponse à vitre argument sur la difficulté à tester une application multi-threadée, pas à faire de la preuve logicielle.

    En outre, tu n'envisages même pas qu'on puisse faire du dotnet sur autre chose que sur Windows. Tu sais qu'il existe maintenant des microcontroleurs de type ARM avec un framework dotnet préinstallé?
    Et ces implémentations n'ont pas de threadPool ?
    ARM n'a t'il pas des instructions pour optimiser le changement de contexte d'exécution ?

    Il n'y a pas besoin d'avoir une machine de guerre pour bénéficier du multi-threading.

    Je viens de terminer un logiciel de facturation pour un ami indépendant et il n'utilise pas de multithreading : il ne fonctionnerait donc pas convenablement? Pourtant, je sors de mon cadre habituel et j'entre dans un domaine de "gestion". Lancer les requêtes en multithread ne m'apportait rien, la BDD est sur un disque local et même avec 3000 factures les résultats sont instantanés vu par l'utilisateur (et il fait entre 1 et 10 factures par mois).
    Ne pestera-t-il pas qu'en il sera bloqué lors d'une recherche d'une facture par critère de recherche, ou lors d'une ouverture de fichier sur un partage réseau. Quid de la montée en charge si votre ami passe du statut d'indépendant à celui de gérant de société.
    Tous ces désagréments pouvant être évités avec de très simples utilisations du multi-threading.
    Je n'ai pas dit que c'est impossible de faire un programme mono-threadé mais le multithread permet d'avoir des programmes bien plus conviviales pour un coût minime.

    Je vois mal sur base de quel principe il serait plus simple de lancer plusieurs threads et de les synchroniser plutôt que de n'en utiliser qu'un seul.
    Avez-vous essayé de faire des entrée-sortie non bloquantes ou du dialogue à travers des réseaux, sans multi-thrading. Si oui, vous savez pertinemment qu'il est nettement plus simple de le faire avec plusieurs threads. Les outils offerts aux développeurs permettent d'utiliser le multi-threading de manière très simple. Et là, cela n'a rien à voir avec les performances mais avec la maintenabilité.

    qu'on utilise un ou plusieurs niveaux d'interruption dans un programme "linéaire" qu'on fait du multithreading, ça n'a strictement rien à voir
    La difficulté principale du multithreading est la coordination entre les threads chose qui est aussi complexe que l'interuptabilité d'une routine et qui utilisent les mêmes concepts pour y paliers.

    Tu as lancé un second thread, pourquoi n'en as-tu pas lancé 2 autres? Ou 3? Ou 10?
    Je n'en n'ai pas lancé un mais autant que l'indépendance des données permettait de faire (un par groupe d'atelier). Via le threadingPool, je ne submerge pas le système avec threads et bénéficie de l'optimisation des ressources processeurs fournies par le Framework .NET. L’application est donc prête à passer sur un octo-core sans la moindre modification.

    5) Ce qui est intéressant et judicieux pour une application donnée ne l'est pas forcément pour une autre application.
    Cela n'empêche pas d'étudier la possibilité, la réactivité d'une application multi-thread est toujours meilleur qu'une monothread et le coup est très souvent minime? Si l'on prend la peine d'apprendre en multi-thread. Le coup de cet apprentissage sera rapidement amorti.

    C'est du multithread "de base", comme lorsqu'on profite du parallélisme sur framework 4 pour lancer des requêtes SQL. Il y a des applications où le multithread demande bien plus de réflexion et bien plus d'échanges d'informations et de coordinations entre process, et là, ça se complique si on n'est pas rigoureux. Je le répète : oui il y a des mécanismes d'aide au multithread, surtout dans certains contextes particuliers, mais ça ne veut ni dire qu'on doit tout le temps les utiliser ni que le multithread se limite à ça.
    Oui, c'est du multithread de base, et c'est là où je veux en venir, le multi-thread est facile s'il est maîtrisé. Il ne se limite pas à des cas simples mais il faut au moins commencer par le mettre dans les cas simples.

    Je te trouve bien présomptueux quand même de t'assimiler à l'intégralité du forum via ce "nous".
    Ce "nous", c'est les pauvres blaireaux qui s'échinent à faire du multi-threadé, juste parce qu'ils ont gobés les conneries d'un vendeur de multi-core.
    Vous faites toujours partie du "nous" ?

    Celui qui écrit un traitement de textes n'en a rien à cirer de tirer le maximum de puissance de la machine
    Oui, mais il déteste voir son éditeur prendre un temps fou pour afficher la liste des disques et des partages réseau lors de la sauvegarde du fichier.

    quand j'intercepte et que je traite des trames CAN ça ne me sert pas à grand-chose de les traiter plus vite qu'elles n'arrivent
    J'ai fait pareil mais j'avais un système expert de diagnostique de panne dans la boucle et je ne devais pas perdre une trame juste parce que ce système avait des vapeurs.
    Et devinez comment j'ai fais.

    le multi-threading se justifie dans quasiment tous les types développements non triviaux
    "Justifie", ce n’est pas la même chose qu'"obligatoire".

    Je maintient qu'il se justifie dans quasiment tous les types de développement, même dans un éditeur de texte, un logiciel de facturation, un décodeur de trame CAN pour diagnostique de panne etc...

    C'est pas obligatoire mais toutes ces applications auront des avantages à utiliser le multi-threading, et pas que pour les performance, multi-core ou pas.
    La réactivité d'une application est très souvent bien plus importante que sa performance brute.

    Les outils actuels permettent de faire du multi-threading sans grands efforts et le retour sur investissement est assuré.

  15. #15
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    612
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2008
    Messages : 612
    Points : 1 050
    Points
    1 050
    Par défaut
    La majorité des services sont hostés dans des svchost.exe et la majorité des exécutables sont des résidents et non des services.
    De plus, les services sont une part très importante des logiciels sous Windows.
    Ce n'est pas parce que les services sont importants dans Windows que la majorité des utilisateurs développent des services.

    Cf. le nom du fil de message, et oui, toutes les applications d'envergures sur lesquelles j'ai travaillé ont profitées des avantages du multi-threading.
    Ton problème, c'est ça : les applications sur lesquelles TU as travaillé. Mais TU ne représentes pas l'intégralité des programmeurs et donc TU ne représentes pas une quelconque référence. Je te l'ai dit explicitement, si les applications sur lesquelles TU travailles profitent toutes du multithreading, c'est loin d'être le cas des toutes les applications de tous les programmeurs.
    L'informatique, c'est vaste.

    Ne déformez pas mes propos, les tests automatiques sont ma réponse à vitre argument sur la difficulté à tester une application multi-threadée, pas à faire de la preuve logicielle.
    Je ne déforme strictement rien du tout, j'ai dit que le multithread ajoutait un risque de bug potentiel survenant de façon asynchrone et pas toujours évident à anticiper ni à débusquer. Tu as beau avoir les outils, quand ton utilisateur de dit "hier, le programme a planté", tes outils ne te sont pas d'une grande utilité si tu ne sais pas reproduire le bug de façon systématique.
    Et je te cite : "Le multitreading est toujours plus simple que le mono-thread" ou encore "rendant le debugging des problèmes de concurrence une formalité". Chacun appréciera.

    Et ces implémentations n'ont pas de threadPool ?
    ARM n'a t'il pas des instructions pour optimiser le changement de contexte d'exécution ?
    Tu connais le coût d'un changement de contexte sur un microcontroleur?
    Si, ça existe et ça se fait, mais de nouveau ça se fait SI c'est pertinent et nécessaire.

    Ne pestera-t-il pas qu'en il sera bloqué lors d'une recherche d'une facture par critère de recherche,
    Il ne restera jamais bloqué (sauf si bug, mais c'est un autre problème), ce n'est pas parce qu'on ne fait pas du multithreading qu'on a une application lourde et non fonctionnelle. S'il demande une recherche de facture c'est qu'il en a besoin pour poursuivre, je vois mal l'intérêt pour lui de lui permettre d'en encoder une autre dans l'attente de la réponse. Ceci d'autant plus qu'à son niveau la réponse est pratiquement instantanée et qu'il n'aurait du reste ni le temps d'abandonner ni de faire autre chose. Du reste, en raisonnant comme tu le fais, ça veut dire qu'il n'y aurait jamais dans Windows des applications qui transforment le curseur en sablier durant une opération.

    ou lors d'une ouverture de fichier sur un partage réseau
    On peut ouvrir un fichier par partage réseau sans bloquer l'utilisateur et sans faire du multithread. Du reste, si je lance Word (j'ai la version 2002) il ne lance qu'un seul thread et si j'ouvre un fichier réseau il n'en lance pas un autre (pour prendre ce simple exemple). Rendre systématiquement la main à l'utilisateur en lançant des threads pour chaque opération complique inutilement le programme car on se retrouve partout avec des méthodes réentrantes qu'il faut éventuellement bloquer avec des flags. On lance un thread lorsqu'il y a un intérêt à le faire, sinon on s'abstient.

    Tous ces désagréments pouvant être évités avec de très simples utilisations du multi-threading.
    Comme je te l'ai dit, ces désagréments tu les as imaginés, ils n'existent pas. Et de plus c'est loin d'être de "très simples" utilisations du multithreading car lui rendre la main avant la fin de l'opération nécessite de vérifier qu'il ne relance pas une autre opération incompatible (genre je recherche une facture dans le facturier ouvert et pendant la recherche, en imaginant, ce qui n'est pas le cas, qu'elle "dure", je ferme mon facturier et j'en ouvre un autre". Ton multithreading "très simple" oblige alors à verrouiller toutes les options incompatibles des boutons et menus ou à l'inverse à permettre un accès simultané à plusieurs facturiers différents. De simple, on se retrouve avec une usine à gaz, le tout pour un gain inexistant pour l'utilisateur qui n'y verra de toutes façons pas la différence.

    Je me méfie toujours lorsqu'on pense que le multithread c'est simple. Ca l'est effectivement au niveau des mécanismes et des facilités offertes, mais ce n'est pas toujours simple au niveau de la prise en compte de toutes les conséquences de ce choix. De nouveau, moi, je réfléchis en comparant avantages et inconvénients, et j'en lance si c'est pertinent.

    Je n'ai pas dit que c'est impossible de faire un programme mono-threadé mais le multithread permet d'avoir des programmes bien plus conviviales pour un coût minime.
    Je vois mal ce que le multithread apporte à la convivialité dans l'absolu. De nouveau tu extrapoles tes propres applications à l'ensemble des applications existantes. Il y a des tas de programmes commerciaux monothread qui sont parfaitement conviviaux et auxquels le multithread n'apporterait rien. Il y a plein de programmes commerciaux qui lancent un thread supplémentaire ou deux, mais que lorsque tu regardes attentivement, c'est uniquement pour les fonctions d'auto-update par le net ou d'envoi de rapports, et qui donc ne concernent en rien la convivialité ni le coeur du programme en lui-même. Si la "convivialité" ça consiste à rendre le menu "imprimer la facture" actif avant d'avoir terminé la recherche de cette facture, c'est clair que dans l'absolu ça semble convivial, mais dans les faits moi j'appelle ça "un bug". La convivialité ça ne consiste pas à rendre la main à l'utilisateur à tout prix et le plus rapidement possible, la convivialité c'est de lui offrir un environnement de travail agréable, réactif, et clair. Et pour ça, le multithread peut être utile dans certains cas mais en aucun cas nécessaire.

    Avez-vous essayé de faire des entrée-sortie non bloquantes ou du dialogue à travers des réseaux, sans multi-thrading.
    Je te l'ai dit : je travaille pour l'instant sur un programme de domotique qui utilise des communications physiques, dont des communications réseau. Et je te l'ai dit, par intérêt d'asynchronisme les communications tournent dans un thread séparé (mais il ne s'agit pas que d'ouvrir un "bête" fichier sur le réseau, il s'agit de communications continues et de leur traitement "temps réel".

    Je te le répète : je ne suis pas CONTRE le multithread, et je l'utilise personnellement. Je dis simplement qu'on ne peut pas dire d'un programme qu'on va devoir écrire qu'il sera multithread avant même de savoir de quel genre de programme on parle.

    Inutile donc de tenter de me donner tort en cherchant des exemples où le multithreading est nécessaire, car j'en suis déjà absolument convaincu, et je l'ai dit.

    Par contre, trouver pour moi un seul exemple où il n'est pas nécessaire suffit à démontrer que lorsque tu affirmes qu'il faut toujours l'utiliser tu donnes dans l'exagération et dans l'extrapolation de tes propres applications.

    Les outils offerts aux développeurs permettent d'utiliser le multi-threading de manière très simple.
    Les outils permettent de mettre en oeuvre le multithreading de façon plus simple mais ils ne réfléchissent pas (encore) à la place du programmeur. Ce qui peut sembler simple a parfois des conséquences inattendues : on parlait récemment avec un programmeur qui, pour rendre la main à l'utilisateur a ajouté un "DoEvents". Fort bien, sauf qu'en faisant ça il doit modifier tout le programme pour prendre en compte le cas où l'utilisateur va effectuer une opération non prévue ou cliquer deux fois sur le même bouton, etc. L'outil (l'instruction) est simple, les conséquences beaucoup moins.

    La difficulté principale du multithreading est la coordination entre les threads chose qui est aussi complexe que l'interuptabilité d'une routine et qui utilisent les mêmes concepts pour y paliers.
    C'est bien ce que j'ai dit et que tu infirmes en disant que le multithread est simple et bien géré par les outils. Encore que la nuance est qu'avec les interruptions tu sais que pendant que tu l'exécutes et tant que tu n'as pas terminé son traitement le programme principal est stoppé, ce qui n'est pas le cas avec les threads (sauf blocage volontaire, mais si on bloque tout ça devient du multithread monothread si j'ose m'exprimer ainsi). Pareil au niveau communications. Donc, il y a des similitudes entre le multithread et les interruptions, notamment par le fait que ce sont des processus asynchrones, mais ce n'est quand même pas pareil.

    Je n'en n'ai pas lancé un mais autant que l'indépendance des données permettait de faire (un par groupe d'atelier). Via le threadingPool, je ne submerge pas le système avec threads et bénéficie de l'optimisation des ressources processeurs fournies par le Framework .NET. L’application est donc prête à passer sur un octo-core sans la moindre modification.
    De nouveau, c'est un cas particulier non généralisable. Je te l'ai dit, tout le monde ne fait pas ce genre d'applications et toutes les applications ne se prêtent pas à ce genre de chose. Je pense réellement que tu imagines que tous les programmeurs font le même travail que toi, et c'est loin d'être le cas.
    Sinon, pour ne pas submerger, ben chaque fois que tu lances un thread tu consommes des ressources. Si le résultat est profitable dans l'immédiat, tant mieux, mais si le but est prévoir l'achat du multicore alors ça revient en fait à pratiquement obliger l'utilisateur à y passer.
    Moi, je développe des applications pour "Monsieur tout le monde" et je me vois mal imposer un multicores pour faire tourner un programme qui s'en passe parfaitement.

    Cela n'empêche pas d'étudier la possibilité,
    Heuu, depuis le début je dis bien que j'utilise le multithreading si ça m'est utile. Si je l'utilise c'est donc que j'ai envisagé la possibilité de l'utiliser, non?
    Je dis : on réfléchit et si c'est utile on l'utilise, et toi tu dis "on doit toujours l'utiliser". Si on doit toujours l'utiliser il est inutile d'en étudier la possibilité puisque tu l'utilises de toutes façons.

    La réactivité d'une application multi-thread est toujours meilleur qu'une monothread
    Tu passes d'une évidence (étudier la possibilité de l'utilisation) à une "conclusion" qui n'a aucun rapport. Non, la réactivité d'une application multithread "en général" n'est pas toujours meilleure, je vois mal ce qui permettrait de démontrer ça. La réactivité dépend d'un tas de paramètres, le choix ou non du multithread n'est qu'un choix parmi d'autre et qui n'est pertinent que dans certains contextes. Je vois mal qui pourrait dire en faisant tourner des programmes "courants" s'ils sont multithreads ou monothreads simplement en regardant "leur réactivité". Mes programmes sont toujours réactifs mais pas toujours multithread, tout dépend du programme.

    Si l'on prend la peine d'apprendre en multi-thread. Le coup de cet apprentissage sera rapidement amorti.
    Personne, et surtout pas moi, n'a jamais dit qu'il fallait faire l'impasse sur le multithreading. J'ai dit qu'il fallait l'utiliser en toute connaissance de cause et lorsque c'était justifié, et pour faire ça il faut évidemment avoir étudié le sujet.

    Ton raisonnement est plutôt : "Etudiez le multithreading et ensuite appliquez-le partout parce que c'est toujours mieux, toujours plus simple, et le debuggage est une évidence". Désolé de ne pas être d'accord avec des affirmations un peu trop "affirmatives" et "généralistes".

    Oui, c'est du multithread de base, et c'est là où je veux en venir, le multi-thread est facile s'il est maîtrisé.
    Ce n'est pas parce que lancer un progress-bar dans un thread séparé est simple que réaliser un programme complexe utilisant des threads communiquant de façon continue entre eux est également simple.

    Certaines formes de multithreading sont simples à utiliser, d'autres non. Et l'intérêt du multithreading ne se résume pas à permettre à un utilisateur de cliquer sur un bouton <Annuler>, ça c'est anecdotique pour moi, ni à lancer une requête SQL en parallélisme (tout le monde ne travaille pas sur des BDD).

    Il ne se limite pas à des cas simples mais il faut au moins commencer par le mettre dans les cas simples.
    Il faut commencer à le mettre dans des cas où il est intéressant de le mettre, ni plus ni moins. Si ce cas est simple tant mieux, s'il est complexe il faut se donner la peine de l'étudier. Partir du principe qu'il faut commencer à apprendre le multithreading simple puis à l'appliquer partout systématiquement pour ensuite l'utiliser dans des cas complexes, c'est faisable à l'école dans des exercices étudiés pour ça, mais rarement dans la vie réelle.

    Ce "nous", c'est les pauvres blaireaux qui s'échinent à faire du multi-threadé, juste parce qu'ils ont gobés les conneries d'un vendeur de multi-core.
    Tiens, tu reconnaissais précédemment que le multithread n'était pas réservé aux multicores, LOL. Je te l'ai dit, si le but est de faire tourner tous les noyaux d'un processeur alors il faut encore que l'application s'y prête et soit "scindable", tout en étant que le gain final reste positif (ce n'est pas certain avant de l'avoir évalué ou testé). En outre tu ne peux jamais savoir la charge actuelle d'un processeur d'un PC : si ton utilisateur a lancé un autre programme, tu tentes peut-être de faire du multithread vers des noyaux déjà chargés et donc rien ne dit que c'est toujours avantageux.

    Et désolé que tu prennes mal le fait que les multicores soient une idée permettant de continuer à vendre une technologie qui n'évolue plus, mais c'est la triste réalité. Je te l'ai dit, je trouve anormal de reporter sur le programmeur le pis-aller que constitue l'augmentation des noyaux plutôt que l'augmentation des vitesses d'exécution. Pour moi, un multicore devrait être réservé à des machines qui ont une série de tâches à effectuer en parallèle et ce de façon prévisible. Fournir du multicore à Monsieur tout-le-monde et dire aux programmeurs "démmerdez-vous avec les cores pour faire tourner vos programmes" ça me semble un peu "osé", d'autant que de toutes façons ce n'est qu'un sursaut vu que lorsqu'on en sera à 8 cores je me demande bien quel programme sur PC va bien pouvoir se scinder en 8 parties "productives". Et je passe l'évolution si ça continue : ça te dit de lancer 256 threads pour un traitement de texte? On a tout compliqué pour ne pas se retrouver bloqué aujourd'hui alors que de toutes façons on va se retrouver bloqué demain si on ne se décide pas à lancer une nouvelle technologie.

    Sinon, je te l'ai dit, même si je ne programme pas le même genre d'applications que toi je reste un programmeur quand même et la plupart des mes applications ne se prêtent pas à un "partage multicore" niveau performances et donc j'évalue l'intérêt du multithreading au cas par cas.

    Et puisque je suis un exemple d'un utilisateur qui n'a pas intérêt systématique au multithreading (tout en l'utilisant si nécessaire) alors ton affirmation concernant le fait qu'il "FAUT" utiliser systématiquement le multithreading est soit fausse, soit signifie que je n'ai rien compris à mes propres programmes.

    Vous faites toujours partie du "nous"
    Tu as dit "ce n'est pas le bon forum, nous..." Donc, "nous" se rapporte au forum, mais bon c'est vrai qu'on peut toujours dire ensuite qu'on parlait d'autre chose.

    Si ce "nous" fais référence aux utilisateurs de multicores, ben oui j'en fais partie. Mon PC a été détruit par la foudre et j'ai bien du en racheter un autre, et les bicores sont devenus le standard (pour ne pas dire les quad-cores). Ca ne veut pas dire que je vais obligatoirement scinder mes applications pour qu'elles tournent sur multicore si ça ne m'apporte pas un gain et que ça pénalise les gens qui n'ont pas un multicores.

    Oui, mais il déteste voir son éditeur prendre un temps fou pour afficher la liste des disques et des partages réseau lors de la sauvegarde du fichier.
    LOL.
    Connais-tu réellement bien le milieu hardware?
    Moi j'ai 4 disques dans mon PC et 6 sur un serveur Nas en réseau (entre autres). Lorsque je dois afficher la liste des disques, tu sais ce que j'attends? Ben que les disques sortent de veille et démarrent. Ce n'est pas parce que je vais lancer un second thread que j'aurai mon résultat plus vite.

    Tu crois vraiment que si l'utilisateur attend "un temps fou" pour avoir sa liste des disques que le fait de lancer un second thread va accélérer les choses?
    Tu sais ce que ça veut dire "se mettre à l'échelle de temps du processeur"?

    Ton multithread il va amener quoi? Ah oui, j'aurai un beau programme réactif qui va me permettre de lancer le combo de sauvegarde et pendant qu'il attend que les disques démarrent il va me permettre de continuer à taper quelques lignes. LOL, tu parles sérieusement, là? Tu connais des utilisateurs qui, lorsqu'ils décident de sauver leur fichier ont besoin qu'on leur rende la main le temps que les disques s'affichent?????

    Bon, je crois qu'on commence à parler de n'importe quoi cette fois-ci, quand moi je parle de multithreading je parle d'avantages "sérieux" pas d'exemples qui ne représentent aucune réalité. Sans compter que le combo de sauvegarde, ben il s'ouvre en mode modal. Pour finir, on va dire que le modal doit se lancer dans un thread séparé pour rendre la main à l'utilisateur et donc transformer le modal en non-modal.

    J'ai fait pareil mais j'avais un système expert de diagnostique de panne dans la boucle et je ne devais pas perdre une trame juste parce que ce système avait des vapeurs. Et devinez comment j'ai fais
    Tu as fait comme moi, tu as utilisé un second thread (si si, relis, je l'ai dit explicitement). J'ai lancé le second thread pour raison d'asynchronisme (pour ne pas perdre de trame tout en attendant la bonne), PAS pour des raisons de performances dues au muticore (c'est pourquoi j'ai dit que ça ne me servait à rien de traiter les trames plus vite qu'elles n'arrivaient).

    "Justifie", ce n’est pas la même chose qu'"obligatoire".
    Non, ça veut dire que si c'est justifié et qu'on ne l'utilise pas c'est qu'on est dans l'erreur. Ce n'est donc pas obligatoire de fait, c'est obligatoire si on sait programmer, c'est exactement ce que ça veut dire.

    Je maintient qu'il se justifie dans quasiment tous les types de développement
    Il se justifie... lorsque c'est justifié, LOL.
    On ne peut pas justifier quelque chose avant même d'avoir écrit le cahier des charges de ce qu'on doit réaliser, et à plus forte raison avant même de savoir ce qu'on doit réaliser.

    même dans un traitement de texte
    Va expliquer ça à Microsoft, LOL

    même dans un éditeur de texte
    C'est curieux, j'utilise plusieurs éditeurs et pas un seul n'est multithread. Je n'ai pas remarqué qu'ils n'étaient pas réactifs mais bon je ne dois pas taper assez vite.

    un logiciel de facturation
    Mon ami ne se plaint pas, et ceux qui ont téléchargé ce logiciel (ben oui, j'écris de l'open-source) ne semblent pas se plaindre non plus. Maintenant, on peut toujours mieux faire, c'est clair, mais le multithread là-dedans, désolé mais je vois mal où l'utiliser.

    un décodeur de trame CAN pour diagnostique de panne
    Je te parlais d'un programme relativement plus complexe qu'un simple décodeur de trames can. Quoi qu'il en soit je te l'ai dit, dans ce programme j'utilise un second thread pour les communications, parce que ça se justifie via l'asynchronisme. Pour des raisons de performances pas besoin en ce qui concerne le traitement, par contre peut-être concernant les accès SQLite à la base de cartographie des cartes (je verrai à ce moment-là en prenant bien tout en compte, et non en disant "j'ai forcément un avantage au multithread").

    C'est pas obligatoire mais toutes ces applications auront des avantages à utiliser le multi-threading, et pas que pour les performance, multi-core ou pas.
    C'est une affirmation qui ne repose sur strictement rien du tout.
    J'ai une vieille version de Word, elle ne lance qu'un thread (même sur sauvegarde réseau). Dis-moi quel peut bien être mon avantage en tant qu'utilisateur que Microsoft modifie ce soft pour lancer un second thread? Je taperai plus vite? Mes éditeurs remplissent parfaitement leur fonction, aussi bien éditeurs de textes qu'éditeurs hexadécimaux, et aucun n'est multithread. Leurs concepteurs sont donc tous des idiots?

    La réactivité d'une application est très souvent bien plus importante que sa performance brute.
    J'attends toujours que tu me démontres le lien de cause à effet entre réactivité et multithread. Pour reprendre mon vieux word, il me semble réactif et pourtant monothread. Pareil avec la majorité des mes autres programmes. Tiens, mon éditeur de schémas (Orcad capture : 10.000 euros la suite pro) est monothread et me semble pourtant parfaitement réactif bien que très complexe.

    Les outils actuels permettent de faire du multi-threading sans grands efforts
    Les outils actuels permettent de lancer des threads de façon simple et "automatique" dans certaines situations. Ils proposent des outils pratiques pour utiliser les threads, mais ils ne réfléchissent pas à la stratégie à la place du programmeur.

    sans grands efforts et le retour sur investissement est assuré.
    C'est clair que s'il n'y a pas d'effort le retour sur investissement est assuré, LOL.

    Plus sérieusement, pour moi :

    - Soit c'est avantageux pour le programmeur et ça fait baisser le coût de développement. Rien ne le démontre de façon systématique, ça dépend du contexte
    - Soit c'est avantageux pour l'utilisateur et ça rend son application plus conviviale : aucun lien de cause à effet n'est établit entre multithread et convivialité/réactivité, et donc, de nouveau, c'est au cas par cas
    - Soit c'est impératif pour des raisons d'asynchronisme ou de performances, et donc ça s'est fait après étude permettant de se rendre compte que c'était nécessaire.

    Pour moi, il y a toujours une liaison : réflexion -> détermination de la stratégie -> utilisation du multithreading si avantage(s)

    et non :

    "Les outils permettent de faire du multithreading de façon simple" -> "J'utilise donc le multithreading de façon systématique".

    Chacun sa façon de raisonner, il faut de tout pour faire un monde.
    Admet simplement que ton raisonnement t'est propre et n'est pas une vérité universelle

    A+
    Claude

  16. #16
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 047
    Points : 12 074
    Points
    12 074
    Par défaut
    Ce n'est pas parce que les services sont importants dans Windows que la majorité des utilisateurs développent des services.
    Pas les utilisateurs, mais les développeurs.
    Et toute suite logiciel un temps soit peu sérieuse utilise un service, un résident ou une extension Shell.

    L'informatique, c'est vaste.
    Mon affirmation, c'est qu'un programme monothread profitera de nouvelles fonctionnalités/réactivité ou de simplification du code par l'utilisation du multi-threading. Je donne des exemples et je suis prêt à montrer que sur n'importe quel type d'application il y a des avantages même sur un simple éditeur de texte. Le but du développement n'est pas de faire un programme parfait mais qui correspond aux besoins du client avec un coût réduit, une maintenance optimale et un domaine d'utilisation évolutif.

    j'ai dit que le multithread ajoutait un risque de bug potentiel survenant de façon asynchrone et pas toujours évident à anticiper ni à débusquer
    Ces outils sont là pour vérifier que les cas de figures ajoutés par l'asynchronisme ont bien été ajoutés à la campagne de tests. C'est pour réduire ces fameux risques additionnels, pas pour vérifier le programme.

    Tu as beau avoir les outils, quand ton utilisateur de dit "hier, le programme a planté", tes outils ne te sont pas d'une grande utilité si tu ne sais pas reproduire le bug de façon systématique.
    Cela arrive sur des applications mono-threadé que sur des applications multi-threadé et l'utilisation de dump automatique (via DrWatson ou autre) et les logs sont là pour ça, mono-threadé ou pas.

    Et je te cite : "Le multitreading est toujours plus simple que le mono-thread" ou encore "rendant le debugging des problèmes de concurrence une formalité".
    Chacun appréciera.
    Je peux faire une démonstration sur un exemple que vous me fournirez. A vous de voir.

    Si, ça existe et ça se fait, mais de nouveau ça se fait SI c'est pertinent et nécessaire.
    Le switch de contexte n'est pas à la charge du programmeur applicatif mais du système et je fais confiance aux implémenteurs du système. Suis-je trop naïf ?

    S'il demande une recherche de facture c'est qu'il en a besoin pour poursuivre
    J’espère qu'il ne fait jamais de faute de frappe, car, sinon, il doit attendre la fin d'une action car il ne peut pas l'annuler. Mais avec un simple bouton "annuler" et un working thread, le tour est joué. Coup de développement ?

    Ceci d'autant plus qu'à son niveau la réponse est pratiquement instantanée
    Même si les données sont sur un partage réseau et que celui-ci est surchargé ou déconnecté. La solution ne prend que quelques lignes pourtant. Si la conception de l'application est correcte bien sûr.

    Du reste, en raisonnant comme tu le fais, ça veut dire qu'il n'y aurait jamais dans Windows des applications qui transforment le curseur en sablier durant une opération.
    Gagné, une application doit être réactive.

    On lance un thread lorsqu'il y a un intérêt à le faire, sinon on s'abstient.
    Tout à fait. Il faut juste prendre la peine de voir s'il y a un avantage.

    Du reste, si je lance Word (j'ai la version 2002) il ne lance qu'un seul thread et si j'ouvre un fichier réseau il n'en lance pas un autre (pour prendre ce simple exemple
    Dans ce cas, c'est la routine "système" qui devrait être multi-threadé, pour ne pas attendre la réponse du partage le plus lent pour commencer l'affichage les disques et ainsi pouvoir les sélectionnés sans attendre. L'utilisateur pourra donc faire sont travail bien plus agréablement.
    Temps de dev ?

    De nouveau, moi, je réfléchis en comparant avantages et inconvénients, et j'en lance si c'est pertinent.
    Il faut donc les évalués.
    Il y a quasiment toujours une fonctionnalité dans un programme qui gagnera à être multi-threadé. Mais on ne fait jamais un programme parfait.

    nécessite de vérifier qu'il ne relance pas une autre opération incompatible (genre je recherche une facture dans le facturier ouvert et pendant la recherche, en imaginant, ce qui n'est pas le cas, qu'elle "dure", je ferme mon facturier et j'en ouvre un autre". Ton multithreading "très simple" oblige alors à verrouiller toutes les options incompatibles des boutons et menus ou à l'inverse à permettre un accès simultané à plusieurs facturiers différents. De simple, on se retrouve avec une usine à gaz, le tout pour un gain inexistant pour l'utilisateur qui n'y verra de toutes façons pas la différence.
    Design Pattern Command, et l'usine à gaz n'existera pas. Il faut un minimum de conception.

    d'ouvrir un "bête" fichier sur le réseau
    Justement, pouvoir annuler la lecture d'un simple fichier volumineux sur le réseau, il faut un bouton annuler réactif. Là encore le multithreading facilite grandement là chose.

    Par contre, trouver pour moi un seul exemple où il n'est pas nécessaire suffit à démontrer que lorsque tu affirmes qu'il faut toujours l'utiliser tu donnes dans l'exagération et dans l'extrapolation de tes propres applications.
    Même les applications les plus simples gagnent à utiliser le multithreading, cf. l'éditeur de texte et la lecture de fichier sur le réseau.
    Un contre-exemple s'il vous plait, car l'éditeur de texte ou l'outil de facturation n'en sont pas.

    consiste à rendre le menu "imprimer la facture" actif avant d'avoir terminé la recherche de cette facture, c'est clair que dans l'absolu ça semble convivial, mais dans les faits moi j'appelle ça "un bug".
    Un bug le faite de pouvoir demandé une impression sans attendre que la précédente soit achevé ou le fait de pouvoir l'annuler ?

    La convivialité ça ne consiste pas à rendre la main à l'utilisateur à tout prix et le plus rapidement possible, la convivialité c'est de lui offrir un environnement de travail agréable, réactif, et clair?
    Comment être réactif si le seul thread est en train de mouliner pour lire un gros fichier sur le réseau (et en plus c'est pas le bon fichier ). On ne peut même pas annuler l'action.

    on parlait récemment avec un programmeur qui, pour rendre la main à l'utilisateur a ajouté un "DoEvents". Fort bien, sauf qu'en faisant ça il doit modifier tout le programme pour prendre en compte le cas où l'utilisateur va effectuer une opération non prévue ou cliquer deux fois sur le même bouton, etc. L'outil (l'instruction) est simple, les conséquences beaucoup moins.
    C'est un exemple parfait de l'utilisation du multi-threading qui simplifie le codage. Avec un simple thread de travail, il n'a pas besoin de faire des DoEvents, l'IHM se mettra à jour simplement (activation et désactivation des commandes comprise) et le traitement des doubles commandes ou anormales est réglé très simplement avec le Design Pattern Command.

    Donc, il y a des similitudes entre le multithread et les interruptions, notamment par le fait que ce sont des processus asynchrones, mais ce n'est quand même pas pareil.
    C'est bien la teneur de mes propos.

    Sinon, pour ne pas submerger, ben chaque fois que tu lances un thread tu consommes des ressources. Si le résultat est profitable dans l'immédiat, tant mieux, mais si le but est prévoir l'achat du multicore alors ça revient en fait à pratiquement obliger l'utilisateur à y passer.
    Moi, je développe des applications pour "Monsieur tout le monde" et je me vois mal imposer un multicores pour faire tourner un programme qui s'en passe parfaitement.
    J'utilise le threadPool de .NET, je ne crée aucun thread. C'est le Framework qui les créent si nécessaire. L'application gagnera en performance même sur un monoprocesseur non hyperthreadé, juste avec l'optimisation des entrées-sorties et de la meilleure localité des données. Oui, "Monsieur tout le monde" tire avantage du multithreading.

    Non, la réactivité d'une application multithread "en général" n'est pas toujours meilleure, je vois mal ce qui permettrait de démontrer ça.
    Et l'intérêt du multithreading ne se résume pas à permettre à un utilisateur de cliquer sur un bouton <Annuler>, ça c'est anecdotique pour moi
    C'est peut-être anecdotique mais cela explique pourquoi une application multithreadé est plus réactive. On peut annuler une action en cours.

    Ce "nous", c'est les pauvres blaireaux qui s'échinent à faire du multi-threadé, juste parce qu'ils ont gobés les conneries d'un vendeur de multi-core.

    Tiens, tu reconnaissais précédemment que le multithread n'était pas réservé aux multicores, LOL.
    Faire des sarcasme sur des sarcasmes, et on a peur de faire du code réentrant.

    Je te l'ai dit, si le but est de faire tourner tous les noyaux d'un processeur alors il faut encore que l'application s'y prête et soit "scindable"
    Non, c'est juste pour avoir un bouton "annuler" qui marche.

    En outre tu ne peux jamais savoir la charge actuelle d'un processeur d'un PC : si ton utilisateur a lancé un autre programme, tu tentes peut-être de faire du multithread vers des noyaux déjà chargés et donc rien ne dit que c'est toujours avantageux.
    Ne prenez pas la place des développeurs du système. Ils connaissent bien mieux leur métier que nous.

    Et désolé que tu prennes mal le fait que les multicores soient une idée permettant de continuer à vendre une technologie qui n'évolue plus, mais c'est la triste réalité. Je te l'ai dit, je trouve anormal de reporter sur le programmeur le pis-aller que constitue l'augmentation des noyaux plutôt que l'augmentation des vitesses d'exécution. Pour moi, un multicore devrait être réservé à des machines qui ont une série de tâches à effectuer en parallèle et ce de façon prévisible. Fournir du multicore à Monsieur tout-le-monde et dire aux programmeurs "démmerdez-vous avec les cores pour faire tourner vos programmes" ça me semble un peu "osé", d'autant que de toutes façons ce n'est qu'un sursaut vu que lorsqu'on en sera à 8 cores je me demande bien quel programme sur PC va bien pouvoir se scinder en 8 parties "productives". Et je passe l'évolution si ça continue : ça te dit de lancer 256 threads pour un traitement de texte? On a tout compliqué pour ne pas se retrouver bloqué aujourd'hui alors que de toutes façons on va se retrouver bloqué demain si on ne se décide pas à lancer une nouvelle technologie.
    Les ingénieurs d'Intel, c'est vraiment des blaireaux, comme moi.
    Ces blaireaux ont remarqués que ces imbéciles de developpeurs utilisaient plusieurs threads. Même qu'y en avaient qui en faisaient sur des 68000. Ils sont cons ses développeurs.
    Et pour les enfoncées dans leurs conneries, ils ont fait exprès de faire des multi-core.

    Trêve de sarcasme sur le complot judéo-massonico-capitaliste. Le multi-core s'agit d'une adaptation du hardware aux demandes logicielles. Et maintenant, le logiciel tente dans tirer le maximum, c'est ça la blairitude.

    la plupart des mes applications ne se prêtent pas à un "partage multicore" niveau performances et donc j'évalue l'intérêt du multithreading au cas par cas.
    Et la réactivité du bouton annuler n'a rien avoir avec le multi-core mais bien des choses avec le multi-threading.

    alors ton affirmation concernant le fait qu'il "FAUT" utiliser systématiquement le multithreading est soit fausse, soit signifie que je n'ai rien compris à mes propres programmes
    Ce n'est pas "Il FAUT" mais il est toujours avantageux d'utiliser le multi-threading.

    Tu as dit "ce n'est pas le bon forum, nous..." Donc, "nous" se rapporte au forum, mais bon c'est vrai qu'on peut toujours dire ensuite qu'on parlait d'autre chose.
    Vous êtes un peu jésuite, non ? Ma phrase c'est :
    Fox, Mulder, ce n’est pas le bon forum. Nous, on essaye de tirer le maximum de la machine avec le minimum de temps de développement. Point Bar.
    Donc le "nous" s'oppose à Fox et Mulder (qui savent, OK c'est Mulder et Scully) et nous, c'est les blaireaux qui sommes les pantins d'Intel.
    Le "Point Bar", c'est pour montrer que l'on est vraiment très cons, vue qu'on a des œillères de l'homme à la cigarette.

    Si ce "nous" fais référence aux utilisateurs de multicores, ben oui j'en fais partie. Mon PC a été détruit par la foudre et j'ai bien du en racheter un autre, et les bicores sont devenus le standard (pour ne pas dire les quad-cores). Ca ne veut pas dire que je vais obligatoirement scinder mes applications pour qu'elles tournent sur multicore si ça ne m'apporte pas un gain et que ça pénalise les gens qui n'ont pas un multicores.
    Et bien moi, je suis encore plus blaireau que vous, car je fais des applications multi-threadées sur mon "vieux" Atlhon64 mono-core pas hyperthreadé dit à 5 ans. (Oui VS2010 tourne sans gros problèmes sur mon Win2003 avec 1Go de RAM). Et même sur cette antiquité, le bouton annuler est plus réactif sur une application multi-thread que mono-thread.

    Je suis vraiment très très con, vu que je m'auto-pénalise.

    Connais-tu réellement bien le milieu hardware?
    Moi j'ai 4 disques dans mon PC et 6 sur un serveur Nas en réseau (entre autres). Lorsque je dois afficher la liste des disques, tu sais ce que j'attends? Ben que les disques sortent de veille et démarrent. Ce n'est pas parce que je vais lancer un second thread que j'aurai mon résultat plus vite.
    Imagez que vous avez sacrifié l'héritage de mémé pour avoir un disk SDD en disque système et que vous voulez lire un fichier dessus. Ca vous fait quoi d'attendre que le disque externe 5400tr récupéré sur une antiquité vous empêche de sélectionner le disque système, juste pour que la boîte de dialogue nous affiche son icone ?
    Moi, ça me gave. Pourquoi l'attendre pour sélectionner C: ?
    Ca n'affiche pas les disques plus vite, cela permet d'ouvrir le fichier plus vite.

    LOL, tu parles sérieusement, là? Tu connais des utilisateurs qui, lorsqu'ils décident de sauver leur fichier ont besoin qu'on leur rende la main le temps que les disques s'affichent?????
    L'utilisateur sait, généralement, où il va sauver le fichier, donc attendre l'affichage des icônes dans ce cas, c'est gênant.

    Sans compter que le combo de sauvegarde, ben il s'ouvre en mode modal. Pour finir, on va dire que le modal doit se lancer dans un thread séparé pour rendre la main à l'utilisateur et donc transformer le modal en non-modal.
    Non, juste s'arranger pour qu'elle puisse réagir aux actions de l'utilisateur avant la fin du scan des disques.

    PAS pour des raisons de performances dues au muticore (c'est pourquoi j'ai dit que ça ne me servait à rien de traiter les trames plus vite qu'elles n'arrivaient).
    Moi, non plus, c'était sous WinCE sur monoprocesseur mais le système expert n'a pas de temps de réponse déterministe. Donc pour ne pas perdre de trame, quoi de plus simple qu'un thread ?

    Non, ça veut dire que si c'est justifié et qu'on ne l'utilise pas c'est qu'on est dans l'erreur. Ce n'est donc pas obligatoire de fait, c'est obligatoire si on sait programmer, c'est exactement ce que ça veut dire.
    Non, c'est juste non optimal, et faire un programme non optimal est une fatalité.

    Va expliquer ça à Microsoft, LOL
    Le correcteur orthographique à la frappe, il utilise le thread d'affichage ?

    C'est curieux, j'utilise plusieurs éditeurs et pas un seul n'est multithread. Je n'ai pas remarqué qu'ils n'étaient pas réactifs mais bon je ne dois pas taper assez vite.
    Forcement, avec votre machine de guerre, mais moi, sur mon antiquité, des blocages à la frappe sur les éditeurs avec coloration, j'en ai.

    LOL, tu parles sérieusement, là? Tu connais des utilisateurs qui, lorsqu'ils décident de sauver leur fichier ont besoin qu'on leur rende la main le temps que les disques s'affichent?????
    S'il est mono-threadé et qu'il est correctement conçu. Donnez-moi un accès aux sources et j'améliorerais la réactivité de l'application. Même sur mon antiquité. Une URL SVP.

    Pour des raisons de performances pas besoin en ce qui concerne le traitement, par contre peut-être concernant les accès SQLite à la base de cartographie des cartes (je verrai à ce moment-là en prenant bien tout en compte, et non en disant "j'ai forcément un avantage au multithread").
    Il est plus simple d'avoir une architecture multi-threadable dés le départ que de la rendre multi-threadable. Les Design Pattern sont là pour que le coût au démarrage soit très léger.

    C'est une affirmation qui ne repose sur strictement rien du tout.
    Si, le bouton "Annuler" qui marche.

    J'ai une vieille version de Word, elle ne lance qu'un thread (même sur sauvegarde réseau). Dis-moi quel peut bien être mon avantage en tant qu'utilisateur que Microsoft modifie ce soft pour lancer un second thread? Je taperai plus vite? Mes éditeurs remplissent parfaitement leur fonction, aussi bien éditeurs de textes qu'éditeurs hexadécimaux, et aucun n'est multithread. Leurs concepteurs sont donc tous des idiots?
    Cf. le correcteur orthographique. Ils ne sont pas des idiots, ils s'en servent.

    LOL, tu parles sérieusement, là? Tu connais des utilisateurs qui, lorsqu'ils décident de sauver leur fichier ont besoin qu'on leur rende la main le temps que les disques s'affichent?????
    Ils n'ont pas de bouton d'annulation ?

    Les outils actuels permettent de lancer des threads de façon simple et "automatique" dans certaines situations. Ils proposent des outils pratiques pour utiliser les threads, mais ils ne réfléchissent pas à la stratégie à la place du programmeur.
    Il faut justement y réfléchir en amont en s'appuyant sur les Design Pattern.

    Citation:
    Les outils actuels permettent de faire du multi-threading sans grands efforts
    sans grands efforts et le retour sur investissement est assuré.

    C'est clair que s'il n'y a pas d'effort le retour sur investissement est assuré, LOL.
    Un mot vous a échappé.

    Chacun sa façon de raisonner, il faut de tout pour faire un monde.
    Admet simplement que ton raisonnement t'est propre et n'est pas une vérité universelle
    On va faire ça sur pièce.
    Votre outils de facturation est mono-thread, open-source, et ne tirera aucun avantage du multithreading.
    Donnez-moi une URL pour charger les sources et je vous montrerais que c'est faux (si la conception est soigneuse grâce aux Design Pattern).

  17. #17
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    612
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2008
    Messages : 612
    Points : 1 050
    Points
    1 050
    Par défaut
    Et toute suite logiciel un temps soit peu sérieuse utilise un service, un résident ou une extension Shell.
    Plus on discute et plus je trouve que tu as une vision complètement réductrice du monde de l'informatique. A mon avis tu devrais faire un sondage sur les gens qui fréquentent ce forum pour savoir si tous partagent ton point de vue sur ce qu'est "un logiciel un temps soi peu sérieux".

    Mais bon, peut-être que je ne programme pas des logiciels sérieux, c'est possible.

    Mon affirmation, c'est qu'un programme monothread profitera de nouvelles fonctionnalités/réactivité ou de simplification du code par l'utilisation du multi-threading.
    Comme tu dis, c'est une affirmation, pas une démonstration.

    Je donne des exemples
    Ben non, j'ai beau relire, à part ton exemple dédié à une BDD sur un serveur dans ta boîte, je n'ai rien vu, désolé.

    et je suis prêt à montrer que sur n'importe quel type d'application il y a des avantages même sur un simple éditeur de texte
    Alors fais-le. Prends un open-source fonctionnant correctement et ayant une bonne réactivité, ajoute des threads et reviens démontrer que c'est mieux.

    Le but du développement n'est pas de faire un programme parfait mais qui correspond aux besoins du client avec un coût réduit, une maintenance optimale et un domaine d'utilisation évolutif.
    Je suis bien d'accord. Auquel cas quand un programme fonctionne parfaitement, est écrit correctement (et donc est maintenable), explique en quoi ajouter du multithread simplifie la maintenance et améliore le produit.

    Ces outils sont là pour vérifier que les cas de figures ajoutés par l'asynchronisme ont bien été ajoutés à la campagne de tests. C'est pour réduire ces fameux risques additionnels, pas pour vérifier le programme.
    Si on réduit les risques additionnels alors on est bien d'accord qu'on ne les élimine pas et donc c'est dire qu'ajouter des threads augmente le nombre de bugs potentiels qui auront échappé aux tests. De toutes façons, sur ce point ce n'est même pas discutable : plus on ajoute d'asynchronisme et plus on complique la possibilité d'effectuer des tests exhaustifs, par définition même du mot "asynchrone".

    Cela arrive sur des applications mono-threadé que sur des applications multi-threadé et l'utilisation de dump automatique (via DrWatson ou autre) et les logs sont là pour ça, mono-threadé ou pas.
    Evidemment que ça arrive sur les monothread, simplement le risque est plus grand avec l'augmentation du nombre de threads simultanément en service.
    Et si le log s'amuse à mémoriser tous les appels de fonctions pour voir où ça a planté, alors je crains que l'application ne devienne franchement "lourde".

    Je peux faire une démonstration sur un exemple que vous me fournirez. A vous de voir.
    Pas de problème. Prends un éditeur hexadécimal en open-source et ajoute-y des threads pour voir où ça simplifie le programme et où ça amène un plus à l'utilisateur.

    Le switch de contexte n'est pas à la charge du programmeur applicatif mais du système et je fais confiance aux implémenteurs du système. Suis-je trop naïf ?
    Ce n'est pas parce que c'est à charge du système que ça n'a pas un coût en ressources et en performances. Si tu penses que oui, alors tu es effectivement un peu naïf. Quand on calcule le gain d'un thread supplémentaire lorsqu'on vise les performances, alors évidemment il faut tenir compte de ce coût, surtout sur les plus petits systèmes, et d'autant plus qu'on multiplie le nombre de switches nécessaires. A un certain point il est indiscutable que le gain va devenir négatif car les temps perdus dans les switches dépasseront le temps consacré à l'applicatif. Tout qui fait du bas niveau connait cette réalité.

    J’espère qu'il ne fait jamais de faute de frappe, car, sinon, il doit attendre la fin d'une action car il ne peut pas l'annuler. Mais avec un simple bouton "annuler" et un working thread, le tour est joué. Coup de développement ?
    Si l'action dure moins de 3 secondes il n'y a aucun intérêt à annuler, l'utilisateur n'en a pas le temps -> coût de développement, même si infime = temps perdu si l'utilité est nulle.

    Si l'action est longue, alors il y a intérêt à permettre l'annulation, mais, et je te l'ai déjà dit plusieurs fois, si c'est ça ta vision du "multithread" (lancer un progress-bar avec un bouton annuler) alors c'est clair qu'on ne parle pas de la même chose. Lancer ce genre de truc je ne considère pas ça comme relevant de l'étude du multithreading et ça ne vaut même pas la peine de pondre un tutorial (au maximum un "bête" exemple de quelques lignes). Le coût de développement est "rikiki" mais le but visé est aussi "rikiki" (moi, un bouton d'annulation, je n'en parle même pas en terme de développement, c'est sous-entendu si c'est nécessaire). Ca ne pose pas non plus les problèmes inhérents au synchronisme parce que pendant que la requête se déroule, à part attendre un clic sur <Annuler> on ne fait pas grand chose d'autre.

    Lancer un thread qui ne va fonctionner que le temps d'une action pour permettre l'annulation, c'est basique de chez basique, et l'avantage se limite à la présence du bouton <annuler>. Je crains qu'on ne parle pas de la même chose, car quand je parle multithread je parle de threads lancés qui fonctionnent en // avec l'application principale et échangent des informations avec d'autres threads. Brefs, des threads qui nécessitent un développement à part entière et une étude, et donc des tutoriaux comme ceux objet de la question initiale. Donc, un thread qui est un "programme" et pas une simple requête lancée en asynchronisme.

    Enfin, c'est encore une fois un cas relatif aux BDD, et toutes les applications ne sont pas des applications nécessitant une BDD.

    Même si les données sont sur un partage réseau et que celui-ci est surchargé ou déconnecté. La solution ne prend que quelques lignes pourtant. Si la conception de l'application est correcte bien sûr.
    La solution n'amène aucun gain d'accès, le seul avantage est le bouton <Annuler> que je ne considère pas ça (je l'ai dit depuis le début) comme une application multithread digne de ce nom nécessitant tutorial et code conséquent. Pour l'application, l'utilisateur a donné comme cahier des charges que la BDD (encore) se trouvait sur disque local, car il doit la déménager sur site avec son portable et sans accès internet. Je te l'ai dit : cahier des charges -> solution. De plus, si son fichier se trouvait en accès distant non accessible il ne saurait de toutes façons pas travailler.

    Sinon, c'est clair qu'ajouter un bouton <Annuler> ne coûte rien (si c'est utile), mais si en ajoutant ça tu estimes que ton programme devient un programme "multithread", alors on n'a pas la même vision de ce qu'est un programme multithread, et du coup, effectivement, on peut affirmer qu'on fait des applications multithread sans arrêt, LOL. Quand je dis qu'un de mes programmes est multithread, ça veut dire que conceptuellement, dans le fonctionnement même du programme, il y a des tâches qui doivent tourner et communiquer, et non un programme monothread qui lance des requêtes en // pour proposer temporairement un bouton <Annuler> ou un progress-bar.

    Gagné, une application doit être réactive.
    Application réactive ne veut pas dire que l'utilisateur ne doit jamais attendre le résultat d'une action qu'il a déclenchée. Quand je fais une cartographie de mon système domotique, ça peut prendre plusieurs minutes, et l'utilisateur doit attendre la fin du résultat pour pouvoir utiliser le programme, il n'a pas le choix. Evidemment il peut annuler, mais s'il annule ça ne lui avance à rien puisqu'il ne peut rien faire sans cette cartographie. L'application est réactive mais ça ne veut pas dire que l'utilisateur ne doit jamais attendre. Quand je fais un backup de mes données, ça prend plusieurs dizaines de minutes qui m'imposent d'attendre (ou d'annuler, ou de faire autre chose avec un autre programme), et pourtant l'application est réactive. Quand je sauve un document word sur un disque arrêté, il faut bien que j'attende que le disque redémarre et pourtant Word est réactif.

    Tout à fait. Il faut juste prendre la peine de voir s'il y a un avantage.
    AHHHHHHHHHHHHHHHHHHHHHHHHH, quand même..........
    En disant ça, tu dis la seule chose que j'affirme depuis le début et que tu nies : oui au multithreading SI et seulement si ça procure un avantage.

    Et s'il faut "prendre la peine de voir s'il y a un avantage", c'est qu'il peut ne pas y en avoir (dixit Lapalisse), et que donc l'utilisation du multithreading dépend de l'application et du contexte et donc n'est pas automatique et obligatoire (ou légitime comme tu dis).

    Dans ce cas, c'est la routine "système" qui devrait être multi-threadé, pour ne pas attendre la réponse du partage le plus lent pour commencer l'affichage les disques et ainsi pouvoir les sélectionnés sans attendre. L'utilisateur pourra donc faire sont travail bien plus agréablement.
    Temps de dev ?
    Mais de quoi tu parles? De refaire les combo de Windows pour y ajouter des threads? Le tout pour avoir une hiérarchie des disques présentant des "trous" qui seront "bouchés" lorsque le disque aura démarré? Si je sauve sur le dernier disque utilisé c'est ce disque que je dois attendre, aucun autre, et si je veux la hiérarchie pour sauver ailleurs je préfère la voir en intégralité plutôt que partielle sans me rendre compte qu'un disque n'a pas encore répondu.

    A force de vouloir faire du multithreading partout tu vas finir par réécrire tout l'OS. Pourquoi pas, mais moi j'ai d'autres chats à fouetter que d'y consacrer mon temps pour un problème qui ne me préoccupe pas.

    Mais de toutes façons, je voulais juste montrer que même des programmes connus réalisés par une société qui a créé Windows ET dotnet que toutes leurs applications ne sont pas multithread.

    Il faut donc les évalués.
    Où ai-je dis le contraire? Si je décide d'en faire ou de ne pas en faire c'est qu'au moins je me suis posé la question.

    Il y a quasiment toujours une fonctionnalité dans un programme qui gagnera à être multi-threadé.
    C'est une nouvelle règle?
    Il peut y en avoir et il peut ne pas y en avoir.

    Sinon, c'est clair que si ta vision du multithread est de lancer une requête en background pour proposer <Annuler>, alors on peut trouver des cas d'utilisation si on cherche bien, dans certains programmes. Mais bon, pour moi ça n'en fera pas un programme multithread et ça ne nécessite pas de tutorial.

    Design Pattern Command, et l'usine à gaz n'existera pas. Il faut un minimum de conception
    Ca n'élimine pas le fait de devoir autoriser ou interdire explicitement tout ce que l'utilisateur n'a pas le droit de faire lorsqu'on s'amuse à lui rendre la main avec une opération critique pendante.

    Justement, pouvoir annuler la lecture d'un simple fichier volumineux sur le réseau, il faut un bouton annuler réactif. Là encore le multithreading facilite grandement là chose.
    Je te l'ai dit : si c'est ça que tu appelles un programme multithread, alors je suis d'accord avec toi.

    Mais si c'est ça un programme multithread alors c'est inutile d'en faire un fromage le temps de développement est nul, d'apprentissage également, et le bénéfice du multithread se résume à proposer un bouton <Annuler>.

    Bref, je suis d'accord.

    Simplement, lorsque moi je réalise un programme "multithread" il ne s'agit pas du tout de ce genre d'opération basique prise en charge de plus par des méthodes du framework, il s'agit de réaliser un programme dont la structure même et les bases de fonctionnement reposent sur la communications entre différents threads dialoguant ensemble.

    Ajouter des boutons <Annuler> un peu partout lance certes des threads "éphémères" mais ne relève pas de la technique de programmation en multithread, du moins pas de mon avis.

    Même les applications les plus simples gagnent à utiliser le multithreading, cf. l'éditeur de texte et la lecture de fichier sur le réseau.
    Un contre-exemple s'il vous plait, car l'éditeur de texte ou l'outil de facturation n'en sont pas.
    Je te l'ai dit : si ta vision du multithreading se résume à ajouter un bouton <Annuler>, alors on ne parle pas de la même chose, surtout qu'il y a d'autres façons simples d'ajouter un bouton annuler lors des lectures de fichiers ou autres.

    Un bug le faite de pouvoir demandé une impression sans attendre que la précédente soit achevé ou le fait de pouvoir l'annuler ?
    Un bug de demander l'impression d'une facture dont on a lancé la recherche et qu'on n'a pas encore trouvée. Pour imprimer une facture sans attendre que l'impression précédente ne soit achevée il est inutile de lancer des threads dans l'application. Pour annuler l'impression non plus.

    Comment être réactif si le seul thread est en train de mouliner pour lire un gros fichier sur le réseau
    Si j'ai besoin du fichier je vois mal en quoi l'application pourrait être plus réactive : en me proposant d'éditer mon fichier avant qu'il ne soit lu?
    J'utilise des tas d'éditeurs et plusieurs environnements de développement et ça ne m'a jamais dérangé d'attendre le chargement de mon fichier avant de travailler. Même avec VS, quand je charge une solution il ne me propose pas de commencer à taper du code pendant qu'il charge les autres projets, il me dit "attends, je prépare la solution" et une fois chargée il me l'ouvre.

    Et, heuu, toujours avec VS, quand je charge une solution (sur disque réseau), j'ai beau regarder je ne vois pas le bouton <Annuler>. Ils sont bêtes chez Microsoft quand même....

    (et en plus c'est pas le bon fichier ). On ne peut même pas annuler l'action.
    Ca, j'ai bien compris : multithread = bouton <Annuler>.
    Au départ je pensais qu'on parlait de quelque chose d'un rien plus... complexe, LOL.

    J'utilise le threadPool de .NET, je ne crée aucun thread. C'est le Framework qui les créent si nécessaire
    Evidemment, du coup, ça ne consomme plus aucune ressource, LOL.

    L'application gagnera en performance même sur un monoprocesseur non hyperthreadé, juste avec l'optimisation des entrées-sorties et de la meilleure localité des données.
    Heuu, quel rapport? On ne sait pas optimiser les IO sans lancer des threads?

    C'est peut-être anecdotique mais cela explique pourquoi une application multithreadé est plus réactive. On peut annuler une action en cours
    Application multithread = bouton annuler = plus réactive.

    J'ai bien compris ton équation, mais ma vision du multithread se situe à un autre niveau, on ne parle décidément pas de la même chose. Sans compter qu'on peut annuler plein de choses sans multithread et de façon simple, et sans compter que annulation ne rime pas avec réactivité, ce sont deux concepts complètement différents. L'annulation c'est une opportunité qu'on offre à l'utilisateur dans certains cas d'opérations lourdes, ce n'est pas une augmentation de réactivité.

    Non, c'est juste pour avoir un bouton "annuler" qui marche
    Encore?
    Tu devrais écrire un tutorial sur les bienfaits du multithread pour le bouton <Annuler>. A force d'annuler on ne va plus faire grand chose, LOL.

    Ne prenez pas la place des développeurs du système. Ils connaissent bien mieux leur métier que nous.
    Le rôle du système n'est pas de vérifier à ta place qu'à force d'augmenter le nombre de threads opérationnels il ne finisse pas perdre plus de temps en switches que sur les applications. Si tu penses que c'est impossible je t'engage à étudier attentivement les mécanismes mis en place.

    Les ingénieurs d'Intel, c'est vraiment des blaireaux, comme moi.
    Pas du tout, c'est simplement qu'une société commerciale a pour but de vendre leur produit. Tu penses qu'ils oeuvrent pour le plaisir des informaticiens? LOL

    Ces blaireaux ont remarqués que ces imbéciles de developpeurs utilisaient plusieurs threads. Même qu'y en avaient qui en faisaient sur des 68000. Ils sont cons ses développeurs. Et pour les enfoncées dans leurs conneries, ils ont fait exprès de faire des multi-core.
    Dingue non? Tiens, c'est à se demander pourquoi ils ont attendu que la vitesse actuelle des processeurs n'évolue plus pour cause de blocage technologique pour commencer à vendre des multicores au grand public? J'ai beau regarder en arrière, tant qu'on n'a pas été bloqué sur l'évolution des vitesses je n'ai pas vu de multicore. Damned, c'est une coïncidence, ils n'avaient pas vu que depuis les années 80 les programmeurs utilisaient lorsque c'était nécessaire le multithread, et il n'avaient pas vu qu'il existait des OS multitâches depuis les années 80.

    Donc, tu penses qu'on a sorti les multicores parce qu'on a "remarqué" que les utilisateurs faisaient du multithreading.
    Tu penses réellement ce que tu écris? LOL

    Trêve de sarcasme sur le complot judéo-massonico-capitaliste.
    Le multi-core s'agit d'une adaptation du hardware aux demandes logicielles. Et maintenant, le logiciel tente dans tirer le maximum, c'est ça la blairitude
    LOL. Le multicore est une adaptation aux demandes logicielles? Tu dis ça sans rigoler?????

    Il n'y a aucun complot là-dedans, juste une sordide histoire commerciale : la vitesse des processeurs n'augmente plus (je te passe les raisons techniques sur la technologie des microprocesseurs) et puisque l'utilisateur veut toujours "plus de puissance" et que pour vendre il faut fournir ce que l'acheteur demande, on a trouvé comme "astuce" de multiplier le nombre de noyaux. Ce n'est même pas discutable, c'est un fait.

    Et, à cause de cette augmentation du nombre de noyaux on est obligé de trouver des méthodes de programmation "à l'arrache" permettant de répartir tant bien que mal (plutôt mal que bien) la charge des programmes sur les différents cores, puisque c'est la seule façon d'encore tenter d'augmenter la vitesse d'exécution des programmes. Du coup, Microsoft a intégré dans son framework 4 des "solutions toutes faites" destinées à soulager un peu le programmeur de ce travail supplémentaire dont il se serait bien passé.

    C'est ça, la réalité, c'est une réalité commerciale.

    Et la réactivité du bouton annuler
    Parlant d'annuler, si on annulait le terme "annuler" de ton message, ne resterait plus grand chose.

    Ce n'est pas "Il FAUT" mais il est toujours avantageux d'utiliser le multi-threading.
    La nuance est subtile, LOL.
    Toujours avantageux, sans préciser pourquoi ni comment ni où ni quand, ça
    ressemble furieusement à du dogmatisme.

    Vous êtes un peu jésuite, non
    Si tu veux tomber dans l'humour caustique, à ta guise.

    Donc le "nous" s'oppose à Fox et Mulder (qui savent, OK c'est Mulder et Scully) et nous, c'est les blaireaux qui sommes les pantins d'Intel.
    Intéressant comme prose littéraire. Pas étonnant que j'aie des difficultés à te comprendre.

    Le "Point Bar", c'est pour montrer que l'on est vraiment très cons, vue qu'on a des œillères de l'homme à la cigarette
    Je ne partage pas tes références médiatiques, et "point-barre" (désolé pour le "bar" mais je ne bois pas) signifie qu'on met un terme à la conversation.

    Mais bon, si tu utilises des termes pour dire autre chose, faut partager ton dictionnaire avec celui avec qui tu dialogues.

    Et bien moi, je suis encore plus blaireau que vous, car je fais des applications multi-threadées sur mon "vieux" Atlhon64 mono-core pas hyperthreadé dit à 5 ans. (Oui VS2010 tourne sans gros problèmes sur mon Win2003 avec 1Go de RAM). Et même sur cette antiquité, le bouton annuler est plus réactif sur une application multi-thread que mono-thread
    C'est le syndrome de l'annulation.
    Pour le reste, tu mélanges tout, performances et asynchronisme dans une sorte d'hymne à la gloire du dieu "Annuler" à tel point qu'on n'y comprend plus rien.

    Imagez que vous avez sacrifié l'héritage de mémé pour avoir un disk SDD en disque système et que vous voulez lire un fichier dessus. Ca vous fait quoi d'attendre que le disque externe 5400tr récupéré sur une antiquité vous empêche de sélectionner le disque système, juste pour que la boîte de dialogue nous affiche son icone ?Moi, ça me gave. Pourquoi l'attendre pour sélectionner C: ? Ca n'affiche pas les disques plus vite, cela permet d'ouvrir le fichier plus vite.
    Le requester s'ouvrira (si l'application est bien faite) sur le dernier disque utilisé, sans devoir attendre et sans multithread. Sinon, si on veut l'arborescence avec les requesters de windows, il faudra attendre le démarrage du disque. Sont débiles quand même chez Microsoft, tu devrais aller leur expliquer l'intérêt du multithreading dans leurs boîtes de dialogue.

    L'utilisateur sait, généralement, où il va sauver le fichier, donc attendre l'affichage des icônes dans ce cas, c'est gênant.
    Sauver se fait avec <Ctrl><S> ou autre équivalent. "Enregistre sous", si c'est bien pensé, ouvre le bon disque. Reste le cas où on change de disque, et non, dans ce cas, ça me dérange moins d'attendre le démarrage des disques que d'avoir une hiérarchie incomplète qui va se rafraîchir juste au moment où je voudrais cliquer ce qui fait que je vais cliquer à côté.

    Tu penses bien que ça a été pensé comme ça parce que c'était plus judicieux comme ça, les développeurs de chez Microsoft sont quand même capables de faire du dynamique.

    Non, juste s'arranger pour qu'elle puisse réagir aux actions de l'utilisateur avant la fin du scan des disques.
    Les requesters sont proposés par le système et fonctionnent très bien ainsi. En outre tous les programmes utilisent ceux-là et l'utilisateur y est habitué. Moi, je ne crée des contrôles perso que si j'ai un plus ajouté évident (des trackbars dont le look n'est "pas top", des textboxes traitant les valeurs numériques ou hexadécimales, des datetimepicker avec une couleur montrant qu'ils ont le focus, et autres choses du genre). Refaire un combo de sélection de fichier pour qu'il permette de sélectionner un disque particulier avant que les autres ne soient actifs ça ne me semble pas intéressant parce que ça induit des inconvénients dont j'ai parlé et en outre le temps que passe un utilisateur à sauver ses documents est ridicule par rapport au temps qu'il travaille dedans en général. Je n'en suis pas au point de chercher à gagner 5 secondes sur l'ouverture d'un fichier, d'autant plus que je ne gagne que si le disque est arrêté et qu'il n'est arrêté que s'il y a longtemps que je n'y ai pas accédé.

    Forcement, avec votre machine de guerre, mais moi, sur mon antiquité, des blocages à la frappe sur les éditeurs avec coloration, j'en ai.
    Ma machine de guerre? LOLOLOL.
    Les programmes actuels sont faits pour les machines actuelles, ou pas trop anciennes. De nouveau c'est un impératif commercial mais tu vas encore dire je donne dans le complot judéo-maçonnique.

    Moi, non plus, c'était sous WinCE sur monoprocesseur mais le système expert n'a pas de temps de réponse déterministe. Donc pour ne pas perdre de trame, quoi de plus simple qu'un thread
    Pas besoin de déterminisme pour intercepter des trames can avec un PC. D'une part il y a l'interface qui se charge de bufferiser et d'autre part les trames arrivent par un port du PC et ne peuvent pas en principe se perdre.
    Moi, j'ai utilisé un thread pour les communications pour la bonne raison que je dois attendre certaines trames spécifiques tout en continuant à en recevoir d'autres, et qu'il est difficile dans une méthode de dire "j'attends la réponse à ma trame" tout en permettant aux autres fenêtres de recevoir les autres trames, si on n'utilise pas le multithread. S'il ne s'était pas s'agit de ça, le programme lisait parfaitement les trames Can SAns aucun besoin de multithread. Un thread supplémentaire ne va en aucun cas garantir d'avantage qu'il n'y aura pas de trame perdue, c'est même pire car c'est du temps CPU consommé qu'il reste en moins pour le programme.

    S'il est mono-threadé et qu'il est correctement conçu. Donnez-moi un accès aux sources et j'améliorerais la réactivité de l'application. Même sur mon antiquité. Une URL SVP
    Tu as besoin que je te donne une URL pour trouver un programme monothread qui utilise les disques?
    Ben, tu en as des milliers, si ça t'amuse tu peux tous les "améliorer" en ajoutant ton bouton <Annuler> sur chaque requête d'ouverture de fichier.
    Tiens, commence donc pas VS2010, je n'ai pas vu le bouton d'annulation.

    Il est plus simple d'avoir une architecture multi-threadable dés le départ que de la rendre multi-threadable.
    Je pense ne pas m'être lancé dans le projet sans y réfléchir un minimum.
    Mais le projet est open-source, rien ne t'empêche de venir sur le forum et de proposer tes services, on a besoin de programmeurs.

    Cf. le correcteur orthographique. Ils ne sont pas des idiots, ils s'en servent.
    C'est parce que ça a été conçu comme une application autonome optionnelle (s'installe de façon séparée). Pendant que le correcteur corrige l'utilisateur ne fait de toutes façons rien d'autre que participer à la correction. Dans un même thread le résultat était similaire. Pour tout le reste du programme, on travaille avec word de façon réactive et sans multithread.

    Si, le bouton "Annuler" qui marche
    Il a des jambes alors?
    si tu utilisais un raccourci pour "annuler" tu aurais économisé par mal de mots dans ton message.

    Un mot vous a échappé
    C'est l'humour qui t'a échappé.

    On va faire ça sur pièce.
    Votre outils de facturation est mono-thread, open-source, et ne tirera aucun avantage du multithreading.
    Donnez-moi une URL pour charger les sources et je vous montrerais que c'est faux (si la conception est soigneuse grâce aux Design Pattern).
    On va faire mieux que ça : tu écris ton propre logiciel de facturation, grâce aux magiques "design Pattern" puis on compare les résultats pour savoir si ta version est plus "réactive" et plus performante que la mienne.

    Parce que c'est toujours possible d'améliorer quelque chose, ça c'est clair, et que si je reprends mon propre programme c'est sûr que je vais pouvoir l'améliorer (mais le temps étant ce qu'il est, et non extensible, je dois faire des choix).

    Sur ce, je te laisse le dernier mot pour clôturer, moi j'ai dit ce que j'avais à dire et je l'ai déjà assez répété :

    Si Multithread = bouton <Annuler> alors effectivement on peut à certains endroits ajouter un bouton annuler sur une requête lancée en background, ça ne coûte rien même si ça n'amène pas grand-chose d'intéressant non plus. Mais en parlant de multithreading ce n'est pas à ce genre d'anecdote à laquelle je pensais.

    Si Multithread = conception du programme prévu pour effectuer le travail de fond sur base de plusieurs threads, alors ça demande de bien cerner les besoins et de faire la part des choses

    De toutes façons, c'est toujours à évaluer au cas par cas.

    A toi la fin, je ne répondrai pas.

    A+
    Claude

  18. #18
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 047
    Points : 12 074
    Points
    12 074
    Par défaut
    Ton URL, SVP, que j'y ajoute un bouton annuler.

  19. #19
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 347
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 347
    Points : 20 347
    Points
    20 347
    Par défaut
    Hello
    Citation Envoyé par bacelar Voir le message
    Je donne des exemples et je suis prêt à montrer que sur n'importe quel type d'application il y a des avantages même sur un simple éditeur de texte.
    Faire un programme avec du multithreading pour un éditeur de texte ?
    Le seul intérêt sera de ne pas geler l'interface utilisateur si tu charges un gros fichier ce qui va bloquer le programme le temps que le fichier soit chargé.
    Sinon aucun intérêt.


    Le but du développement n'est pas de faire un programme parfait mais qui correspond aux besoins du client avec un coût réduit, une maintenance optimale et un domaine d'utilisation évolutif.
    Faire un programme en architecture multithread contrairement à ce que l'on pourrait penser n'améliore pas forcément toujours les performances..



    On va faire ça sur pièce.
    Votre outils de facturation est mono-thread, open-source, et ne tirera aucun avantage du multithreading.
    Donnez-moi une URL pour charger les sources et je vous montrerais que c'est faux (si la conception est soigneuse grâce aux Design Pattern).
    faire un progrmme de facturation avec du multithreading ne présente aucun intérêt au contraire il risque de solliciter des temps CPU inutilement !
    Parce que pour faire de la facturation ce n'est bêtement et simplement que de la saisie !
    Si tu saisie une facture tu envoies le détail de ta facture vers le SGBD attaché ( Ms SQL Server,Access....) qui fait sa propre moulinette.
    Mais je ne vois vraiment pas l'intérêt de faire un logiciel de facturation avec du multithreading.
    Un logiciel de facturation c'est ni plus ni moins des écrans de saisie avec des "data grids lists"

  20. #20
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 047
    Points : 12 074
    Points
    12 074
    Par défaut
    Faire un programme avec du multithreading pour un éditeur de texte ?
    Et le correcteur orthographique "au fil de l'eau", coloration syntaxique, le calcul de la densité de texte pour la mise en page ?

    Le seul intérêt sera de ne pas geler l'interface utilisateur si tu charges un gros fichier ce qui va bloquer le programme le temps que le fichier soit chargé.
    Sinon aucun intérêt.
    C'est déjà ça. Mais il y en a bien d’autres.

    Faire un programme en architecture multithread contrairement à ce que l'on pourrait penser n'améliore pas forcément toujours les performances..
    Toutes à fait d'accord, moi, c'est la réactivité pas les performances.

    Parce que pour faire de la facturation ce n'est bêtement et simplement que de la saisie !
    Si tu saisie une facture tu envoies le détail de ta facture vers le SGBD attaché ( Ms SQL Server,Access....) qui fait sa propre moulinette.
    Mais je ne vois vraiment pas l'intérêt de faire un logiciel de facturation avec du multithreading.
    Un logiciel de facturation c'est ni plus ni moins des écrans de saisie avec des "data grids lists"
    Pas d'aide à la saisie dans vos dataGrid ?
    Comment faire le remplissage de la liste des suggestions de valeurs en mono-thread ?

Discussions similaires

  1. Conseils sur l'organisation de mon appli
    Par Turvy dans le forum Android
    Réponses: 5
    Dernier message: 02/12/2013, 13h33
  2. cherche conseil sur livre pour jbuilder
    Par med1 dans le forum JBuilder
    Réponses: 3
    Dernier message: 09/06/2004, 14h33
  3. [débutant] conseils sur contraintes et alter table
    Par maysa dans le forum MS SQL Server
    Réponses: 10
    Dernier message: 26/05/2004, 10h03
  4. Un peu de lumière sur l'arborescence des fichiers de Linux
    Par Noki dans le forum Administration système
    Réponses: 6
    Dernier message: 07/04/2004, 17h16
  5. Recherche Livre / Conseils sur la conception de Base
    Par Yeuma dans le forum Décisions SGBD
    Réponses: 7
    Dernier message: 02/01/2004, 15h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo