Tout à fait d'accord sur le fait que la programmation parallèle est un sous-ensemble (important !) de la programmation concurrente. Après, comme d'autres l'ont fait remarquer, il existe plusieurs sortes de parallélisme. En calcul scientifique, on utilise souvent le parallélisme de données – c'est l'exemple qu'avait donné quelqu'un ici à propos des chats qui mangeraient dans la même gamelle. Un autre type de parallélisme est celui des tâches : c'est ce qu'on fait, par exemple, lorsqu'on repasse une chemise tout en écoutant la télé/radio, et possiblement en parlant avec quelqu'un. Enfin, il y a le parallélisme de pipeline, qui « chaîne » différentes tâches pour qu'elles traitent un bout de donnée successivement. Évidemment, on va fournir un autre bout de donnée à la première tâche dès qu'elle aura passé son bout de donnée traité à la suivante, etc. On peut imaginer une chaîne de montage façon « Les temps modernes », par exemple. Évidemment, on peut mélanger les trois (sinon ce ne serait pas drôle !).
Lors d'une conférence il y a longtemps, le keynote speaker avait proposé une illustration de la différence entre programmation parallèle et programmation concurrente en pratique :
En voyant une nouvelle machine de type supercalculateur, data center, etc., le programmeur parallèle s'extasie et s'écrire : « Ouahou, quelle puissance potentielle ! On va pouvoir faire des choses formidables avec ça ! »
En voyant la même machine, le programmeur concurrent prend une expression horrifiée, et se lamente : « Regardez toutes les possibilités de panne dans cette machine ! »
Un bon exemple de la différence de point de vue est dans l'utilisation d'une bibliothèque de communication et calcul très utilisée en calcul intensif/haute-performance : MPI. Les utilisateurs de MPI le font généralement sur une machine avec réseau d'interconnexion dédié (pas de TCP, trop lourd; pas d'Ethernet, trop lent – au moins niveau latences). Ils se posent des questions compliquées liées à la topologie sur le réseau, combien de sauts il faudra peut-être faire en regardant les machines utilisées, etc.1 Au contraire, les programmeurs de la bibliothèque MPI locale doivent tenir compte de toutes les possibilités de panne temporaire ou permanente (les appels MPI de base sont bloquants, et attendent des acquittements de bonne réception/terminaison d'envoi de données; même la version asynchrone de ces appels fait de même, peu ou prou). Ils doivent composer avec les possibilités de congestion sur le réseau, et pour les versions les plus sophistiquées, prennent en compte tout un tas de possibilités de pannes transitoires ou temporaires.2
Le programmeur parallèle d'une grappe de calcul essaie de trouver des algorithmes et des implémentations qui iront vite pour une application donnée, en considérant que tout ira bien, c'est-à-dire, en faisant abstraction quasi-complètement de la couche réseau (et en-dessous). Le programmeur concurrent va devoir considérer que les latences d'envoi/réception peuvent varier, et même imaginer quel genre de panne peut survenir, et s'il veut y remédier.
Du moins, ceux qui en sont à l'optimisation de leur programme le font; les autres (la majorité) exploitent une machine à 1% max de la capacité crête... ↩
Il existe des versions (de recherche) qui font même de la tolérance aux pannes (je n'ai pas entendu parler de version de production dans ce cas). La plupart des versions utilisées se contentent de planter si jamais un timeout s'est écoulé cependant... ↩
# Parallélisme vs. Concurrence : même machine, différent point de vue !
Posté par lasher . En réponse au journal Exécution concurrente vs parallèle. Évalué à 3.
Tout à fait d'accord sur le fait que la programmation parallèle est un sous-ensemble (important !) de la programmation concurrente. Après, comme d'autres l'ont fait remarquer, il existe plusieurs sortes de parallélisme. En calcul scientifique, on utilise souvent le parallélisme de données – c'est l'exemple qu'avait donné quelqu'un ici à propos des chats qui mangeraient dans la même gamelle. Un autre type de parallélisme est celui des tâches : c'est ce qu'on fait, par exemple, lorsqu'on repasse une chemise tout en écoutant la télé/radio, et possiblement en parlant avec quelqu'un. Enfin, il y a le parallélisme de pipeline, qui « chaîne » différentes tâches pour qu'elles traitent un bout de donnée successivement. Évidemment, on va fournir un autre bout de donnée à la première tâche dès qu'elle aura passé son bout de donnée traité à la suivante, etc. On peut imaginer une chaîne de montage façon « Les temps modernes », par exemple. Évidemment, on peut mélanger les trois (sinon ce ne serait pas drôle !).
Lors d'une conférence il y a longtemps, le keynote speaker avait proposé une illustration de la différence entre programmation parallèle et programmation concurrente en pratique :
En voyant une nouvelle machine de type supercalculateur, data center, etc., le programmeur parallèle s'extasie et s'écrire : « Ouahou, quelle puissance potentielle ! On va pouvoir faire des choses formidables avec ça ! »
En voyant la même machine, le programmeur concurrent prend une expression horrifiée, et se lamente : « Regardez toutes les possibilités de panne dans cette machine ! »
Un bon exemple de la différence de point de vue est dans l'utilisation d'une bibliothèque de communication et calcul très utilisée en calcul intensif/haute-performance : MPI. Les utilisateurs de MPI le font généralement sur une machine avec réseau d'interconnexion dédié (pas de TCP, trop lourd; pas d'Ethernet, trop lent – au moins niveau latences). Ils se posent des questions compliquées liées à la topologie sur le réseau, combien de sauts il faudra peut-être faire en regardant les machines utilisées, etc.1 Au contraire, les programmeurs de la bibliothèque MPI locale doivent tenir compte de toutes les possibilités de panne temporaire ou permanente (les appels MPI de base sont bloquants, et attendent des acquittements de bonne réception/terminaison d'envoi de données; même la version asynchrone de ces appels fait de même, peu ou prou). Ils doivent composer avec les possibilités de congestion sur le réseau, et pour les versions les plus sophistiquées, prennent en compte tout un tas de possibilités de pannes transitoires ou temporaires.2
Le programmeur parallèle d'une grappe de calcul essaie de trouver des algorithmes et des implémentations qui iront vite pour une application donnée, en considérant que tout ira bien, c'est-à-dire, en faisant abstraction quasi-complètement de la couche réseau (et en-dessous). Le programmeur concurrent va devoir considérer que les latences d'envoi/réception peuvent varier, et même imaginer quel genre de panne peut survenir, et s'il veut y remédier.
Du moins, ceux qui en sont à l'optimisation de leur programme le font; les autres (la majorité) exploitent une machine à 1% max de la capacité crête... ↩
Il existe des versions (de recherche) qui font même de la tolérance aux pannes (je n'ai pas entendu parler de version de production dans ce cas). La plupart des versions utilisées se contentent de planter si jamais un timeout s'est écoulé cependant... ↩