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

Programmation parallèle, calcul scientifique et de haute performance (HPC) Discussion :

Multicoeurs et parallélisme


Sujet :

Programmation parallèle, calcul scientifique et de haute performance (HPC)

  1. #41
    Membre habitué
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    280
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 280
    Points : 149
    Points
    149
    Par défaut
    Citation Envoyé par mewtow Voir le message
    Si par mécanisme d'assignation tu veux dire : comment préciser (attention, j'ai dit préciser et pas choisir) le processeur qui va recevoir l'interruption, c'est expliqué dans la section 10.6.1 du system programming developper's guide d'Intel.
    Je crois que j'ai compris ce point. Ce que j'ai eu du mal à comprendre c'est le mécanisme pour spécifier l'adresse de la première instruction à exécuter. Mais bon c'est le même problème qu'avec un monoprocesseur, avec la complication des accès concurent aux structures de données de l'OS. La question que je me pose est si il est possible que deux processus s'exécutent au même moment en mode noyau.

    Bon, en fait c'est plus compliqué et deux autres registres entrent en jeu, afin de faire la différence entre les cores/processeurs physiques et les cores logiques : cela permet de ne pas exécuter un thread/programme sur le même core physique alors qu'on a des cores physiques inutilisés. Mais l'idée est là.
    Peux-tu me donner le chapitre dans le doc qui traite de ces deux registres. Le CPU_ID donne le numéro physique non ? le registre IA32_APIC_BASE MSR
    ? le registre APIC ID ?

    Bref, il suffit de savoir quoi mettre dans ces registres pour sélectionner un processeur. Reste à savoir quel processeur choisir, et là, c'est à l'OS de faire le travail, comme dit plus haut.
    Oui je comprends mieux certaines notions sur les OS multiprocesseur ou multicoeur maintenant.

    Merci !
    "Bien qu'on ait du coeur à l'ouvrage,
    L'Art est long et le Temps est court." - CB

  2. #42
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par PyNub Voir le message
    Peux-tu me donner le chapitre dans le doc qui traite de ces deux registres. Le CPU_ID donne le numéro physique non ? le registre IA32_APIC_BASE MSR
    ? le registre APIC ID ?
    Section 10.6.2 Determining Inter Processor Interrupt Destination. Il s'agit des registres LDR et DFR.

    Regarde aussi le paragraphe 10.6.1 Interrupt Command Register, tu verras que certains champs permettent de préciser si la destination est un processeur physique ou logique et u auras peut-être quelques informations supplémentaires sur tout çà.

    Au passage, je ne suis pas sûr que les identifiants permettant d'identifier les local APIC de chaque core soient identiques au CPUID ( à vrai dire, je suis persuadé du contraire). Il me semble même qu'il y a deux types d'identifiants : un par local APIC (et donc par core logique), et un par core physique.

    Comme cela, l'OS peut décider de préférentiellement choisir un core physique pour des raisons de performances. En clair, l'algorithme de l'OS est plus compliqué que simplement réveiller le premier core visible inutilisé.
    Dernière modification par Invité ; 08/01/2012 à 16h06.

  3. #43
    Membre habitué
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    280
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 280
    Points : 149
    Points
    149
    Par défaut
    @sauviron

    Mais ta question (plusieurs fois mentionnée) m'avait semblait être l'assignation..
    J'ai essayé plusieurs fois de réorienter la discussion :

    Quoi qu'il en soit la notion de threads et de processus ne peut s'appliquer qu'au système d'exploitation. Pour le processeur tout est question d'adresse, d'instruction et de mot mémoire. Et c'est justement c'est de ce point de vue que je veux comprendre ce qu'il se passe.
    Oui, mais au final tout termine par du code machine...
    Non... Tu me parle de programmation alors que j'essaie de comprendre le fonctionnement interne d'un multicoeur....
    Je crois que ce qui fait que tu réponds à côté depuis le début et que tu vois uniquement le problème du point de vue des language de haut niveau... Le problèmes c'est que ces languages utilisent la couche d'abstraction matérielle proposé par l'OS.
    Je n'ai jamais dit le contraire, juste que pour le processeur il n'y a pas de threads. Le processeur lit et décode l'instruction incrémente le compteur ordinal et passe à l'instruction suivante pointée par le nouveau contenu du CO. Il existe des instructions pour changer le contenu du compteur ordinal : les branchements (Jmp,jne etc...), les appels de procédures (Call, Ret...), les interruptions (par instruction avec INT directement par le matériel). Un threads, un processus ce n'est jamais que cela à ma connaissances.
    Envoyé par souviron34
    je soupçonne que l'algo est relativement simple : pour N coeurs, si coeur no i non utilisé, alors on l'utilise, sinon, si tous les coeurs sont utilisés, on prend le moins chargé, et on fait agir un scheduler dessus.
    Pas si simple que ça justement, (voir mon post précédent) mais ce n'est pas le sujet.

    Comme l'avait mentionné Mat.M, effectivement cela doit avoir à faire avec "l'affinité" sous Intel
    Ce n'est pas Mat.M qui a parlé d'affinité mais Mewtow, du reste l'affinité, dans la définition que j'en ai, est une notion propre à l'ordonnanceur, partant, à l'OS.
    "Bien qu'on ait du coeur à l'ouvrage,
    L'Art est long et le Temps est court." - CB

  4. #44
    Membre habitué
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    280
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 280
    Points : 149
    Points
    149
    Par défaut
    Citation Envoyé par mewtow Voir le message
    Section 10.6.2 Determining Inter Processor Interrupt Destination. Il s'agit des registres LDR et DFR.

    Regarde aussi le paragraphe 10.6.1 Interrupt Command Register, tu verras que certains champs permettent de préciser si la destination est un processeur physique ou logique et tu auras peut-être quelques informations supplémentaires sur tout çà.
    Merci encore une fois...

    Au passage, je ne suis pas sûr que les identifiants permettant d'identifier les local APIC de chaque core soient identiques au CPUID ( à vrai dire, je suis persuadé du contraire). Il me semble même qu'il y a deux types d'identifiants : un par local APIC (et donc par core logique), et un par core physique.
    Je ne comprends pas (encore) la différence entre core physique et core logique. Du moment que le core logique est unique... enfin je vais approfondir ça

    Comme cela, l'OS peut décider de préférentiellement choisir un core physique pour des raisons de performances. En clair, l'algorithme de l'OS est plus compliqué que simplement réveiller le premier core visible inutilisé.
    Comment fait l'OS pour déterminer la charge d'un processeur et son activité ?

    Autre chose, est ce que l'OS attribue des processus différents à chaque processeur, celui-ci exécutant son propre ordonnanceur sur sa propre table des processus ? Ou bien existe-t-il un ordonnanceur unique qui peut être exécuter par n'importe quel processeur/core? Mais bon là on dérive sur les OS c'est intéressant de savoir ceci-cit...
    "Bien qu'on ait du coeur à l'ouvrage,
    L'Art est long et le Temps est court." - CB

  5. #45
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par PyNub Voir le message
    Je ne comprends pas (encore) la différence entre core physique et core logique. Du moment que le core logique est unique... enfin je vais approfondir ça
    En fait, il y a une différence uniquement lorsqu'un core physique implémente des technologies de Simultaneous Multithreading (peut être aussi que ça diffère sur les CPU utilisant du fine grained MT ou du coarse grained MT et qui gèrent le changement de tache dans leur hardware) : Intel a décidé d’appeler hyperthreading ce genre de technologie dans un but marketing, mais le vrai terme est SMT (j'utilise des abréviations) - du moins, les chercheurs du MIT qui ont inventés ça dans les années 80-90 lui ont donné ce nom.

    Dans ce cas, on a un core physique étant vu comme deux core logiques se partageant une même ALU (ou un ensemble d'ALU) sur laquelle on issue des instructions venant de deux programmes différents : tu peux voir cela comme une sorte d'Out Of Order amélioré de façon à ne pas s'appliquer que sur les instructions d'un seul programme. Cela nécessite de nombreuses modifications architecturales sur le core physique, cela va sans dire.

    Bref, core physique = un core version silicium, et un core logique : abstraction ne correspondant à presque rien du point de vue matériel, mais permettant au processeur de mieux utiliser les CPU SMT.

    Citation Envoyé par PyNub Voir le message
    Comment fait l'OS pour déterminer la charge d'un processeur et son activité.
    Je ne sais pas si l'OS peut le savoir, surtout pour sa charge. A mon avis, soit cela est indiqué par des registres du processeur qui précisent si le processeur est en mode veille (stoppé par HALT), soit le matériel ne peut pas fournir l’information. Dans ce dernier cas, a mon avis, l'OS se souviens des programmes qu'il a lancés sur les différents cores/CPU et sait donc lesquels sont libres ainsi que le nombre de processus présents sur chaque processeur.

    Citation Envoyé par PyNub Voir le message
    Autre chose, est ce que l'OS attribue des processus différents à chaque processeur, celui-ci exécutant son propre ordonnanceur sur sa propre tables des processus ? Ou bien existe-t-il un ordonnanceur unique qui peut être exécuter par n'importe quel processeur/core?
    Aucune idée, mais je dirais que les deux sont possibles sans vraiment d'arguments pour étayer mon intuition...

    Il n’empêche que c'est une très bonne question. :>
    Dernière modification par Invité ; 08/01/2012 à 17h03.

  6. #46
    Membre habitué
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    280
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 280
    Points : 149
    Points
    149
    Par défaut
    Citation Envoyé par mewtow Voir le message
    Bref, core physique = un core version silicium, et un core logique : abstraction ne correspondant à presque rien du point de vue matériel, mais permettant au processeur de mieux utiliser les CPU SMT.
    Ah ok. je vois

    Je ne sais pas si l'OS peut le savoir, surtout pour sa charge. A mon avis, soit cela est indiqué par des registres du processeur qui précisent si le processeur est en mode veille (stoppé par HALT), soit le matériel ne peut pas fournir l’information. Dans ce dernier cas, a mon avis, l'OS se souviens des programmes qu'il a lancés sur les différents cores/CPU et sait donc lesquels sont libres ainsi que le nombre de processus présents sur chaque processeur.


    Aucune idée, mais je dirais que les deux sont possibles sans vraiment d'arguments pour étayer mon intuition...

    Il n’empêche que c'est une très bonne question. :>
    Je viens de relire mon livre sur les OS. En fait je viens de réaliser qu'à la fin d'un programme celui-ci rend la main à l'OS par un appel système, par exemple exit sous linux, de plus au cours de l'exécution le programme rend la main à l'OS par un appel système pour des E/S ou autres, ce qui donne la possibilité à l'OS d'ordonnancer d'autres processus ou réordonnancer le même processus.

    Reste à savoir si l'OS est exécuté sur un seul processeur, cette solution pose cependant le problème de créer un goulet d'étranglement sur le processeur exécutant l'OS et ne convient qu'à des systèmes de moins de 10 processeurs, de plus il implique de réécrire les appels systèmes afin que ceux-ci déclenchent un appel système sur un autre processeur, ce que permet l'APIC.
    Ou bien si l'exécution de l'OS peut se faire indiféremment sur chaque processeur. Cette solution nécessite cependant de vérouiller des parties du système d'exploitation afin que deux processeurs n'exécutent pas au même moment la même section de l'OS. Se pose alors le problème des deadlocks...

    Enfin, reste le problème de la préemtion. Les processeurs doivent être interrompu régulièrement pour empêcher qu'un processus ne s'accapare le temps UC. Mais cette interruption ne doit pas intervenir au même moment sur tous les processeurs. Comme chaque processeur a son propre timer APIC ce n'est pas vraiment un problème...
    "Bien qu'on ait du coeur à l'ouvrage,
    L'Art est long et le Temps est court." - CB

  7. #47
    Expert éminent sénior

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

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par PyNub Voir le message
    Je viens de relire mon livre sur les OS. En fait je viens de réaliser qu'à la fin d'un programme celui-ci rend la main à l'OS par un appel système, par exemple exit sous linux, de plus au cours de l'exécution le programme rend la main à l'OS par un appel système pour des E/S ou autres, ce qui donne la possibilité à l'OS d'ordonnancer d'autres processus ou réordonnancer le même processus.
    Ce qui est une des raisons, ce me semble, pour laquelle les vrais "langages objets" sont plus lents (éventuellement) : lors des "new" ou des appels à des méthodes particulières, il peut y avoir "passage temporaire de main" à l'OS, qui peut très bien décider de faire basculer un autre processus...

    Ce qui peut être très sensible dans des programmes d'affichage en particulier..

    (et c'est encore plus vrai avec les langages non compilés).
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  8. #48
    Membre habitué
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    280
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 280
    Points : 149
    Points
    149
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    Ce qui est une des raisons, ce me semble, pour laquelle les vrais "langages objets" sont plus lents (éventuellement) : lors des "new" ou des appels à des méthodes particulières, il peut y avoir "passage temporaire de main" à l'OS, qui peut très bien décider de faire basculer un autre processus...
    Oui c'est le problème des appels systèmes. Mais le problème est le même avec le C les fonctions alloc, malloc, etc... sont aussi des appels systèmes. Si l'allocation n'implique pas l'allocation d'une nouvelle page cela doit être assez rapide. Enfin en tout cas sur Linux car cet OS n'utilise pas la segmentation pour séparer les programmes utilisateurs mais seulement les possibilités offerte par la pagination. Après je ne sais pas si C++ est un vrai langage à objet. Mais il est vrai que les facilité offertes par les objets ont (peut-être...) leur contrepartie (Je suis un peu trop novice pour le dire...) par des appels système plus fréquent.

    L'assembleur est souvent choisit pour programmer de la façon la plus optimale. ça dépend aussi de la qualité du compilateur
    "Bien qu'on ait du coeur à l'ouvrage,
    L'Art est long et le Temps est court." - CB

  9. #49
    Membre habitué
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    280
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 280
    Points : 149
    Points
    149
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    Ce qui est une des raisons, ce me semble, pour laquelle les vrais "langages objets" sont plus lents (éventuellement) : lors des "new" ou des appels à des méthodes particulières, il peut y avoir "passage temporaire de main" à l'OS, qui peut très bien décider de faire basculer un autre processus...
    Oui je ne sais pas vraiment. Ceci-dit le C fais un appel système quand il alloue de la mémoire avec alloc...
    "Bien qu'on ait du coeur à l'ouvrage,
    L'Art est long et le Temps est court." - CB

+ Répondre à la discussion
Cette discussion est résolue.
Page 3 sur 3 PremièrePremière 123

Discussions similaires

  1. utiliser mpi pour créer le paraléllisme avec le builder c++
    Par randa84 dans le forum Développement
    Réponses: 1
    Dernier message: 21/02/2007, 14h41
  2. [MPI] Comment créer du parallélisme ?
    Par randa84 dans le forum Programmation parallèle, calcul scientifique et de haute performance (HPC)
    Réponses: 3
    Dernier message: 18/02/2007, 19h33
  3. [ASE]Parallélisme
    Par plochert dans le forum Sybase
    Réponses: 3
    Dernier message: 20/03/2006, 15h25
  4. Thread(Parallélisme) en php
    Par rhdjml dans le forum Langage
    Réponses: 2
    Dernier message: 06/03/2006, 12h01

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