Pourquoi MPI est-il considéré comme plus difficile que la mémoire partagée et Erlang comme plus facile, quand ils passent tous les deux un message?

Question

Il y a beaucoup d'intérêt ces jours-ci en Erlang comme un langage pour l'écriture de programmes parallèles sur des. J'ai entendu des gens soutiennent que Erlang du passage de message modèle est plus facile à programmer que la dominante de la mémoire partagée des modèles tels que les threads.

À l'inverse, dans le calcul de haute performance de la communauté dominante parallèle du modèle de programmation a été MPI, qui met également en œuvre un passage de message modèle. Mais dans le HPC mondial, ce passage de message modèle est généralement considéré comme très difficile à programmer, et ceux qui prétendent que la mémoire partagée des modèles comme OpenMP ou UPC sont plus faciles à programmer dans.

Quelqu'un sait pourquoi il y a une telle différence dans la perception de passage de message contre la mémoire partagée dans le IL et HPC mondes? Est-ce dû à une différence dans la façon dont Erlang et MPI mettre en œuvre la transmission de message qui fait Erlang-style de passage de message beaucoup plus facile que MPI? Ou est-il une autre raison?

Answer 1

Je suis d'accord avec toutes les réponses précédentes, mais je pense que d'un point essentiel qui n'est pas tout à fait clair, c'est que l'une des raisons qui MPI peut être considéré comme dur et Erlang facile est le match de modèle pour le domaine.

Erlang est basé sur un concept de mémoire locale de message asynchrone en passant, et à l'état partagé résolu par l'utilisation d'une base de données mondiale que tous les threads peuvent obtenir. Il est conçu pour les applications qui ne se déplacent pas beaucoup de données, et qui n'est pas censé exploser un 100k différents nœuds qui ont besoin de coordination.

MPI est basé sur de la mémoire locale et de passage de messages, et est conçu pour des problèmes où déplacer les données est un élément clé du domaine. Le calcul de haute performance qui est très bien sur la prise de l'ensemble de données d'un problème, et de le diviser entre une multitude de ressources de calcul. Et c'est assez dur de travailler dans un passage de message système car les données doivent être explicitement distribué à l'équilibre à l'esprit. Essentiellement, MPI peut être considéré comme un mérite de faire l'admission que la mémoire partagée n'est pas à l'échelle. Et il est axé sur la haute performance de calcul répartis sur 100k processeurs ou plus.

Erlang n'est pas d'essayer d'atteindre les plus hautes performances possibles, au lieu de se décomposer naturellement parallèle problème dans son fils naturel. Il a été conçu avec un type totalement différent de la programmation de tâches à l'esprit par rapport à MPI.

Donc, Erlang, le mieux est de comparer les pthreads et d'autres plutôt local hétérogène thread solutions, plutôt que de MPI qui est vraiment destiné à un très différents (et dans une certaine mesure, intrinsèquement plus difficile) ensemble de problèmes.

Answer 2

Le parallélisme en Erlang est encore assez difficile à mettre en œuvre. Par cela je veux dire que vous avez encore à comprendre comment diviser votre problème, mais il y a quelques petites choses qui facilitent cette difficulté par rapport à certaines MPI bibliothèque en C ou C++.

Tout d'abord, depuis Erlang du passage de message est un de première classe pour le langage, le sucre syntaxique la rend plus facile.

Aussi, Erlang bibliothèques sont tous construits autour d'Erlang du passage de messages. Cette structure de soutien contribue à vous donner un coup de pouce en parallèle processling terre. Jetez un oeil à des composants du bureau du procureur comme gen_server, gen_fsm, gen_event. Ceux-ci sont très faciles à utiliser des structures qui peuvent aider votre programme deviennent parallèles.

Je pense que c'est plus la robustesse de la bibliothèque standard qui différencie erlang est la transmission de messages à partir d'autres implémentations MPI, pas vraiment une caractéristique spécifique de la langue elle-même.

Answer 3

Habituellement, la simultanéité dans le HPC, c'est travailler sur de grandes quantités de données. Ce type de parallélisme est appelé le parallélisme de données et est en effet plus facile à mettre en œuvre à l'aide d'une mémoire partagée approche comme OpenMP, parce que le système d'exploitation prend soin des choses comme la planification et le placement des tâches, ce qui aurait pour mettre en œuvre soi-même si l'aide d'une transmission de message de paradigme.

En revanche, Erlang a été conçu pour faire face avec le parallélisme des tâches rencontrées dans les systèmes téléphoniques, où des morceaux de code doivent être exécutées simultanément avec seulement une quantité limitée de la communication et des exigences fortes pour la tolérance aux pannes et la récupération.

Ce modèle est similaire à ce que la plupart des gens utilisent les PThreads pour. Il s'adapte à des applications comme les serveurs web, où chaque requête peut être gérée par un thread différent, tandis que les applications HPC faire à peu près la même chose sur d'énormes quantités de données qui doivent être échangées entre les travailleurs.

Answer 4

Je pense qu'il a quelque chose à voir avec l'état d'esprit lorsque vous êtes à la programmation avec MPI et quand vous êtes à la programmation avec Erlang. Par exemple, MPI n'est pas intégré dans la langue alors que Erlang a un support intégré pour la transmission de message. Une autre raison possible est la déconnexion entre le fait de simplement envoyer/recevoir des messages et le partitionnement des solutions en simultané unités d'exécution.

Avec Erlang, vous êtes obligé de penser en programmation fonctionnelle image où effectivement des données zips par appel à la fonction appel de fonction -- et la réception est active à une loi qui ressemble à un construire dans la langue. Cela vous donne un lien plus étroit entre le calcul que vous êtes en train d'effectuer et de la loi de l'envoi/réception de messages.

Avec MPI sur l'autre main, vous êtes obligé de penser seulement à propos de la transmission de message, mais pas vraiment la décomposition de travail. Ce cadre de pensée nécessite un peu d'un changement de contexte entre l'écriture de la solution et de l'infrastructure de messagerie dans votre code.

La discussion peut continuer, mais l'opinion commune est que si la construction pour la transmission de message est en fait intégré dans le langage de programmation et le paradigme que vous utilisez, généralement c'est un meilleur moyen d'expression de la solution par rapport à quelque chose d'autre qui est "ajouté" ou existe comme un add-on à une langue (dans la forme d'une bibliothèque ou d'extension).

Answer 5

Quelqu'un sait pourquoi il y a une telle différence dans la perception de passage de message contre la mémoire partagée dans le IL et HPC mondes? Est-ce dû à une différence dans la façon dont Erlang et MPI mettre en œuvre la transmission de message qui fait Erlang-style de passage de message beaucoup plus facile que MPI? Ou est-il une autre raison?

La raison en est simplement le parallélisme vs la concurrence. Erlang est élevée pour la programmation simultanée. Le HPC est tout au sujet de la programmation parallèle. Ceux-ci sont liés mais différents objectifs.

La programmation simultanée est grandement compliquée par fortement non-déterministe de contrôle de débit et de latence est souvent un objectif important. Erlang est l'utilisation de immuable structures de données simplifie grandement la programmation simultanée.

La programmation parallèle est beaucoup plus simple de flux de contrôle et l'objectif est tout au sujet maximale du débit total et pas de temps de latence. Efficace de l'utilisation du cache est beaucoup plus important ici, ce qui la rend à la fois Erlang et immuable des structures de données largement inadaptés. La mutation de la mémoire partagée est à la fois souple et nettement mieux dans ce contexte. En effet, la cohérence de cache est de fournir à accélération matérielle de message en passant pour vous.

Enfin, en plus de ces différences techniques, il y a aussi une question politique. L'Erlang les gars essaient de monter le multicœur hype en prétendant qu'Erlang est pertinent pour le multicœur quand il ne l'est pas. En particulier, ils sont vantant grande évolutivité de sorte qu'il est essentiel de tenir compte de la performance absolue ainsi. Erlang échelles sans effort de la mauvaise performance absolue sur une base à une mauvaise performance absolue sur n'importe quel nombre de cœurs. Comme vous pouvez l'imaginer, qui n'impressionnent pas la CPS (communauté, mais elle est suffisante pour beaucoup de lourdement code simultané).