Spread contre MPI contre zéromq ?

Question

Dans l'une des réponses à Diffusez comme UDP avec la fiabilité de TCP, un utilisateur mentionne le Propagé API de messagerie.J'en ai également rencontré un appelé ØMQ.J'ai aussi une certaine familiarité avec MPI.

Donc ma question principale est :pourquoi devrais-je choisir l'un plutôt que l'autre ?Plus précisément, pourquoi choisirais-je d'utiliser Spread ou ØMQ alors qu'il existe des implémentations matures de MPI ?

Answer 1

MPI a été conçu pour des clusters de calcul étroitement couplés avec des réseaux rapides et fiables.Spread et ØMQ sont conçus pour les grands systèmes distribués.Si vous concevez une application scientifique parallèle, optez pour MPI, mais si vous concevez un système distribué persistant qui doit être résilient aux pannes et à l'instabilité du réseau, utilisez l'un des autres.

MPI dispose de fonctionnalités très limitées en matière de tolérance aux pannes ;le comportement de gestion des erreurs par défaut dans la plupart des implémentations est un échec à l'échelle du système.De plus, la sémantique de MPI exige que tous les messages envoyés soient finalement consommés.Cela a beaucoup de sens pour les simulations sur un cluster, mais pas pour une application distribuée.

Answer 2

Je n'ai utilisé aucune de ces bibliothèques, mais je pourrai peut-être donner quelques indices.

1. MPI est un protocole de communication tandis que Spread et ØMQ sont une implémentation réelle.
2. MPI vient de la programmation « parallèle » tandis que Spread vient de la programmation « distribuée ».

Cela dépend donc vraiment si vous essayez de construire un système parallèle ou un système distribué.Ils sont liés les uns aux autres, mais les connotations/objectifs implicites sont différents.La programmation parallèle consiste à augmenter la puissance de calcul en utilisant plusieurs ordinateurs simultanément.La programmation distribuée concerne un groupe d'ordinateurs fiable (cohérent, tolérant aux pannes et hautement disponible).

Le concept de « fiabilité » est légèrement différent de celui de TCP.La fiabilité de TCP est "Donnez ce paquet au programme de fin quoi qu'il arrive". La fiabilité de la programmation distribuée est "même si certaines machines meurent, le système dans son ensemble continue de fonctionner de manière cohérente". Pour vraiment garantir que tous les participants ont reçu le message, il aurait besoin de quelque chose comme Engagement en 2 phases ou l'une des alternatives plus rapides.

Answer 3

Vous abordez ici des API très différentes, avec des notions différentes sur le type de services fournis et l'infrastructure pour chacun d'eux.Je ne connais pas assez MPI et Spread pour répondre à leur place, mais je peux aider un peu plus avec ZeroMQ.

ZeroMQ est une simple bibliothèque de communication par messagerie.Il ne fait rien d'autre que d'envoyer un message à différents homologues (y compris locaux) sur la base d'un ensemble restreint de modèles de messagerie courants (PUSH/PULL, REQUEST/REPLY, PUB/SUB, etc.).Il gère la connexion client, la récupération et la congestion de base strictement en fonction de ces modèles et vous devez faire le reste vous-même.

Bien qu'apparaissant très restreint, ce comportement simple est principalement ce dont vous auriez besoin pour la couche de communication de votre application.Il vous permet de passer très rapidement d'un simple prototype, tout en mémoire, à des applications distribuées plus complexes dans divers environnements, en utilisant de simples proxys et passerelles entre nœuds.Cependant, ne vous attendez pas à ce qu'il effectue le déploiement de nœuds, la découverte de réseau ou la surveillance de serveur ;Vous devrez le faire vous-même.

En bref, utilisez zeromq si vous avez une application que vous souhaitez faire évoluer du simple processus multithread vers un environnement distribué et variable, ou que vous souhaitez expérimenter et prototyper rapidement et qu'aucune solution ne semble correspondre à votre modèle.Attendez-vous cependant à devoir déployer des efforts sur le déploiement et la surveillance de votre réseau si vous souhaitez évoluer vers un très grand cluster.