Version imprimable
Salut,
Pourriez-vous me faire un topo sur les possibilités d'exploiter les possibilités d'une seule machine actuelle (potentitellement plusieurs coeurs et/ou plusieurs processeurs) en programmation ? Voici mes principales questions :
Peut-on créer 2 threads d'un même processus sur des cores différents et leur faire partager/accéder le même espace mémoire ?
Peut-on simplement faire communiquer deux processus qui s'exécutent sur le même processeur ? sur des processeurs différents ?
Merci
Possibilités infinies, mais c'est plus simple avec des bibliothèques dédiés. :aie:Citation:
Pourriez-vous me faire un topo sur les possibilités d'exploiter les possibilités d'une seule machine actuelle (potentiellement plusieurs coeurs et/ou plusieurs processeurs) en programmation ?
Le plus compliqué, c'est de faire l'inverse.Citation:
Peut-on créer 2 threads d'un même processus sur des cores différents et leur faire partager/accéder le même espace mémoire ?
S'ils sont dans un même processus, il partage le même espace mémoire.
Ils sont peut-être 2 piles d'exécution différentes mais elles sont toutes les 2 dans le même espace mémoire (d'adressage pour être plus précis).
C'est assez compliqué de cantonner un thread à un CPU ou à un core, ils ont tendance à changer librement d'hôte d'exécution entre chaque "quantum" d'exécution.
Les IPC (canaux de communication interprocessus) sont tous transparents aux processeurs. C'est plutôt le fait qu'il soit sur des OS différents ou lancer par des utilisateurs différents qui poserait problème.Citation:
Peut-on simplement faire communiquer deux processus qui s'exécutent sur le même processeur ? sur des processeurs différents ?
La limite est ton imagination, ou peu s'en faut... Comme l'a précisé bacelar, tu peux le faire "à la barbare" en gérant tout manuellement, ou te reposer sur des librairies dédiées : tout dépend en fait du niveau de contrôle et de performances désiré.Citation:
Envoyé par tnarol
Parmi les principales API de programmation parallèle, tu as :
- L'API bas niveau native du système (Win32 ou pthread en général).
- Une API bas niveau, mais "portable" car existant sur plusieurs plate-formes via un portage / wrapper (Win32, pthread, ACE, POCO, ...).
- Une API haut niveau, native mais non portable (ex : MFC sous Win32).
- Des librairies dédiées à un langage et/ou compilateur, comme OpenMP (requiert le support du compilateur). La portabilité est, au mieux, variable.
- Des librairies système, dédiées en général à une architecture donnée (TBB par exemple, sur processeurs Intel).
- Et plein d'autres associées à des librairies qui n'ont à priori rien à voir avec le parallélisme (ex : ICE, qui contient un module de création de threads).
Dans tous les cas, régler finement les affinités (= la répartition des threads / processus sur les cœurs et CPU) ou la granularité d'exécution requiert une librairie "native", c'est à dire capable d'utiliser toutes les fonctions de ton système d'exploitation... Par exemple, Windows possède la notion de fibre (thread séquencé par l'utilisateur), que ne possèdent pas les systèmes Unix... Réciproquement, Windows différencie strictement des entités logicielles que les systèmes Unix considèrent globalement comme étant toutes des "fichiers".
Aucun problème avec ça, cela s'appelle l'affinité processeur, et c'est bien sûr réglable à volonté. Ceci empêche les threads de "sauter" de cœur en cœur lors des deschedulings, ce qui est le comportement par défaut si tu ne t'occupes pas de l'affinité : les threads migrent en fonction de la charge de chaque cœur.Citation:
Envoyé par tnarol
Pour information, c'est justement la principale différence entre un thread et un processus : TOUS les threads d'un même processus partagent, par défaut, l'intégralité de leur mémoire à l'exception notable (et normale) du TLS (Thread Local Storage) et de leur pile d'appel. Notamment, tout pointeur valide dans un thread l'est aussi dans tous les autres threads du processus, et c'est également le cas en général pour tous les handles ouverts (fichiers, sockets, objets système, etc.).
De l'autre côté, deux processus d'un système sont, par défaut, totalement isolés l'un de l'autre et ne partagent absolument RIEN entre eux : il faut établir une communication explicite (pipes, sockets, mémoire partagée, objets de synchronisation système) pour que l'un des processus puisse "voir" l'autre. De plus, un pointeur valide dans un processus est normalement invalide dans un autre processus, même si c'est un pointeur sur une zone partagée. En effet, les deux processus ne "voient" pas forcément la zone partagée à la même adresse !!
Après, en fonction du système d'exploitation ET de l'architecture matérielle, deux CPU distincts (pas des cœurs, hein, des processeurs physiquement séparés) peuvent ne pas avoir de mémoire en commun. Mais dans ce cas, ils se programment en fait comme si tu avais deux ordinateurs "séparés", donc la problématique ne se pose pas réellement : aucun des deux processeur ne "voit" l'autre de toutes façons. Si tu es sur une machine de type PC, avec un OS Windows / Linux, ce cas de figure n'existe pas et tu peux même faire migrer un processus d'un CPU à l'autre si besoin.
Sous réserve d'une architecture non-isolée telle que je l'ai décrite au paragraphe précédent, communiquer entre deux processus est strictement la même chose quel que soit le cas de figure : sur le même cœur, sur deux cœurs différents, ou sur deux CPU différents.Citation:
Envoyé par tnarol
Pour ceci, on utilise en général les pipes (ou tubes) qui agissent un peu comme des sockets simplifiées, la mémoire partagée (une zone de données accessible aux deux processus), et des objets de synchronisation créés dans le contexte du système (mutex nommés, sémaphores, etc.). Toutefois, ceci n'est possible QUE si les processus tournent sur le même système, c'est à dire que le CPU faisant tourner l'un "voit" le CPU faisant tourner l'autre au niveau du système d'exploitation.
Si les CPU sont isolés et/ou que tu as affaire à deux machines distinctes, il te faudra passer par une communication réseau (sockets) ou sur bus dédié (VME par exemple) pour les faire communiquer entre eux.
Dans tous les cas, dans le cadre d'une communication inter-processus, tu ne "vois" que ce que tu as choisi explicitement de montrer, et tout le reste est par défaut totalement invisible par les autres processus.