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

Langages de programmation Discussion :

multithreading et multicore


Sujet :

Langages de programmation

  1. #41
    Expert confirmé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par etdmi3 Voir le message
    J'éspère que je serai cette fois-ci dans le bon emplacement et ce n'est pas du rapport cette fois ci
    si j'ai à choisir une approche ,laquelle est meilleure?
    un petit nombre de processeurs très puissants sur un système parallèle à mémoire partagée ou un grand nombre de processeurs simples sur un système parallèle à mémoire distribuée .
    je suppose que les hypothèses du pb sont fixes ou standards
    Est ce qu'on peut avoir des performances de calculs globales proches?
    je serais reconnaissante d'avoir une réponse détaillée et merci
    Citation Envoyé par etdmi3 Voir le message
    Dans ce cas ,on revient aux contraintes des logiciels et des applications développées par les programmeurs qui "must be aware about this problem"
    cad développer leur application en tenant compte de ces contraintes
    Aux deux questions, même réponse que ci-dessus :

    • Savoir ce que l'on veut faire
    • Quels sont les besoins ?
    • Par quoi est-on limité ?
    • Quelle serait la solution : calculer plus vite ou faire plusieurs choses en même temps ?


    Suivant les cas, on optera donc pour : un processeur plus puissant, une optimisation des algos et du code, plusieurs processeurs en parallèle.

    Les problèmes de mémoire distribuée ou partagée n'ont que peu de rapport.

    Ce qui interviendra par contre, dans le cas où la décision serait de faire du parallèlisme (ce qui, voir les remarques plus haut, n'est pas de loin la solution la plus évidente pour 98% des problèmes), sera une évaluation quantitative des gains attendus (coûts+vitesse) à plusieurs machines ou à une machine à plusieurs processeurs, en tenant compte encore une fois des besoins de synchronisation et de la quantité de code parallélisable/code total.

    Il n'y a donc aucune réponse "toute faite", et surtout pas une conclusion immédiate il faut paralléliser", "il faut plusieurs machines", "il faut un multi-core", "il faut du multi-thread"....

  2. #42
    Membre averti
    Inscrit en
    Janvier 2008
    Messages
    24
    Détails du profil
    Informations forums :
    Inscription : Janvier 2008
    Messages : 24
    Par défaut
    salut à tous,
    la tech du multicore est entrain d'évoluer
    mais que faire avec les applications qui ne sont pas conçues à ça
    est ce qu'on doit les paralléliser
    et si c'est le cas comment faire face à l'évolution à cette évolution pour garder les applications extensibles(cad si elles marchent aujourd'hui sur 8 core ,elles en seraient de même demain avec 32 core)?
    ce n'est pas du rapport*

    est ce qu'on aura besoin au futur de paralléliser nos applications?

  3. #43
    Rédacteur

    Avatar de millie
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    7 015
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 7 015
    Par défaut
    Citation Envoyé par etdmi3 Voir le message
    est ce qu'on aura besoin au futur de paralléliser nos applications?
    Qu'est ce que tu entends toi par paralléliser ?
    Est-ce que tu penses multithread ou compiler en réordonnançant les instructions pour en exécuter plusieurs en même temps ou répartir une application sur plusieurs serveurs ou autres ?

  4. #44
    Membre éprouvé
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Par défaut
    Salut,

    j'ai lu le thread avec intérêt, même si j'ai pas le niveau.
    Clairement.
    M'enfin, cela ne m'empêche pas de me dire que tout cela est une impasse à l'heure actuelle.
    Car si j'ai bien compris :
    <<
    D'un côté on propose plus d'unités de calculs, qui permettent d'exécuter plus de tâches indépendantes simultanément.
    Bon ça c'est bien pour les gens lambda, m'enfin sa ne fait pas tout.

    De l'autre, on ne sait pas encore manipuler ces différentes unités de calculs avec simplicité, ni même évaluer simplement le gain réel à paralléliser une application.
    Développer une application, ou la rendre multi threader à postériori, devient problématique à bien des points.
    Conception, débugage, évolution, décisionnel.
    Cette situation me parait compliquée pour les entreprises.
    (j'ai mis quelques affirmations, vous me corrigerais)>>

    Bref. A l'heure actuelle les solutions purement hardware semble ne pas être capable de proposer un système de parralélisation unique et fiable.
    La parréllélisation des calculs repose sur les indications du programme, et donc sur le développeur.

    Cependant le problème dans toute cette histoire, c'est la gestion des ressources et des résultats ?
    Alors ne pourrait il pas y'avoir un super contrôleur, hardware, qui supervise les unités de calculs et donc parrallélise les calculs de manière automatique ????
    Pendant que lui gère la synchronisation des ressources, ainsi que le dispatche et l'ordonnancement des calculs ?
    Enfin quelque chose dans l'idée, je suis pas spécialiste.

    Les chercheurs n'ont ils pas imaginés de solution plus simple à développer, unifiés ?
    Et si ils l'avaient fait, qu'elles sont elle ? Qu'attendent ils pour le déployer ?

    Merci,
    a plus

    PS : désolé si je pollue avec mon manque de connaissance sur le sujet ! Ce n'est pas le but.

  5. #45
    Membre très actif Avatar de ZeRevo
    Inscrit en
    Avril 2007
    Messages
    302
    Détails du profil
    Informations personnelles :
    Âge : 40

    Informations forums :
    Inscription : Avril 2007
    Messages : 302
    Par défaut
    D'une manière générale le développeur n'a pas à se soucier du parallélisme (sauf dans le cadre de recherche de performance : jeux vidéo, 3D) car c'est le système d'exploitation qui gére les processus, la mémoire, l'ordonnancement des tâches.

    Et encore de ce que j'ai lu récemment, dans les jeux vidéos on peut découper en couches/core par exemple on met un core pour l'affichage et un autre pour la gestion de l'IA.

  6. #46
    Membre Expert
    Avatar de SpiceGuid
    Homme Profil pro
    Inscrit en
    Juin 2007
    Messages
    1 704
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2007
    Messages : 1 704
    Par défaut
    C'est aussi mon opinion.

    Les fondeurs ont choisi une voie qui ne peut bénéficier qu'à une fraction des applications, pour les autres c'est l'impasse.

    Si les fondeurs continuent de baser leur développement économique sur l'idée qu'ils vendent de la puissance de calcul à un prix 'premium' alors le choc va être rude pour eux. Parce que maintenant que la puissance est plus qu'abondante c'est le prix qui va devoir s'ajuster.

  7. #47
    Membre averti
    Inscrit en
    Janvier 2008
    Messages
    24
    Détails du profil
    Informations forums :
    Inscription : Janvier 2008
    Messages : 24
    Par défaut
    bonsoir,
    Citation Envoyé par millie Voir le message
    Qu'est ce que tu entends toi par paralléliser ?
    Est-ce que tu penses multithread ou compiler en réordonnançant les instructions pour en exécuter plusieurs en même temps ou répartir une application sur plusieurs serveurs ou autres ?

    En effet,je voulais dire le faite de pouvoir distribuer les charges sur les cores d'une manière à augmenter les performances .
    ET pourquoi pas avoir recours à la compilation et l'ordonnencement des taches.

    la question est "le processeur multicore est là aujourd'hui pour augmenter vraiments les performances ou bien pour des raisons économiques"
    JE SERAIS RECONNAISSANTE D'AVOIR UNE RéPONSE DéTAILLEE OU DES RESSOURCES

  8. #48
    Membre chevronné

    Inscrit en
    Juillet 2008
    Messages
    232
    Détails du profil
    Informations forums :
    Inscription : Juillet 2008
    Messages : 232
    Par défaut
    Citation Envoyé par etdmi3 Voir le message
    la question est "le processeur multicore est là aujourd'hui pour augmenter vraiments les performances ou bien pour des raisons économiques"
    JE SERAIS RECONNAISSANTE D'AVOIR UNE RéPONSE DéTAILLEE OU DES RESSOURCES
    Le multicore permet d'augmenter l'efficacité des processeurs. Pour la même consommation de courant, un processeur multicore peut réaliser beaucoup plus d'opérations qu'un processeur à un seul coeur. En général les fondeurs ont tendance à réduire la consommation et maintenir la performance (ce qui est une bonne chose!)

    Le désavantage, bien sûr, c'est qu'il est possible de programmer le processeur de façon que toutes les opérations se font dans un seul coeur à la fois-- ce qui rend le processeur généralement moins performant qu'avant. Mais s'il est bien programmé le multicore a l'avantage.

    Au niveau performance le principal avantage est la rapidité de réaction, plus il y a de coeurs plus il y a de chance que l'un d'eux soit disponible pour l'opération demandée. Cela donne une impression de performance (en fait un ordinateur plus réactif).

    Je ne sais pas quelles seraient les raisons économiques, peut-être le coût de développer une solution de refroidissement fiable pour ces processeurs à un coeur survoltés? (tous ces watts-heure qui rentrent dans le processeur ça chauffe!!!)

  9. #49
    Membre Expert
    Avatar de SpiceGuid
    Homme Profil pro
    Inscrit en
    Juin 2007
    Messages
    1 704
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2007
    Messages : 1 704
    Par défaut
    le processeur multicore est là aujourd'hui pour augmenter vraiment les performances ou bien pour des raisons économiques
    Il y a d'abord une raison technologique:
    • la fréquence stagne
    • le nombre de transistors continue d'augmenter

    Le multi-coeurs est là parce que les fondeurs ne savent plus quoi faire de leur sur-production de transistors (à part nous les vendre bien entendu).

Discussions similaires

  1. Réponses: 2
    Dernier message: 02/01/2010, 18h59
  2. [WinAPI C++] MultiThreading et PostMessage
    Par Gruik dans le forum Windows
    Réponses: 7
    Dernier message: 29/03/2004, 15h58
  3. [WinAPI C++] MultiThreading?
    Par Gruik dans le forum Windows
    Réponses: 2
    Dernier message: 25/03/2004, 00h08
  4. [Win32]App multithread
    Par billyboy dans le forum Windows
    Réponses: 5
    Dernier message: 25/09/2003, 09h57
  5. Multithreading sous HP Ux 11
    Par pykoon dans le forum Autres éditeurs
    Réponses: 1
    Dernier message: 18/10/2002, 23h36

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