MPI ou Sockets?
https://stackoverflow.com/questions/153616
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je travaille sur un cluster faiblement couplé pour certains traitements de données. Le code de réseau et le code de traitement sont en place, mais nous évaluons différentes méthodologies dans notre approche. Actuellement, comme il se doit, nous sommes liés par des problèmes de performances et nous essayons de réduire ce goulot d’étranglement. Évidemment, des commutateurs plus rapides comme Infiniband seraient géniaux, mais nous ne pouvons pas nous permettre le luxe de simplement jeter ce que nous avons et d’obtenir du nouveau matériel.
Ma question est la suivante. Toutes les applications HPC traditionnelles et sérieuses réalisées sur des clusters sont généralement implémentées avec la transmission de messages plutôt que directement sur des sockets. Quels sont les avantages en termes de performances? Devrions-nous voir une accélération si nous passions de sockets?
La solution
MPI pourrait utiliser des sockets. Mais il existe également une implémentation MPI à utiliser avec un SAN (réseau de système) qui utilise une mémoire partagée distribuée directe. Cela bien sûr si vous avez le matériel pour cela. MPI vous permet donc d’utiliser ces ressources à l’avenir. Dans ce cas, vous pouvez obtenir des améliorations considérables en termes de performances (mon expérience des clusters à l’époque universitaire permet d’obtenir des gains de quelques ordres de grandeur). Par conséquent, si vous écrivez du code pouvant être transféré vers des clusters haut de gamme, utiliser MPI est une très bonne idée.
Même en éliminant les problèmes de performances, l'utilisation de MPI peut vous faire gagner beaucoup de temps, que vous pouvez utiliser pour améliorer les performances d'autres composants de votre système ou simplement pour préserver votre intégrité.
Autres conseils
Je recommanderais d’utiliser MPI au lieu de vous lancer vous-même, à moins que vous ne soyez très bon dans ce genre de chose. Ayant écrit quelques applications informatiques distribuées en utilisant mes propres protocoles, je me retrouve toujours à reproduire (et à reproduire mal) les fonctionnalités présentes dans MPI.
En ce qui concerne les performances, je ne m'attendrais pas à ce que MPI vous fournisse des accélérations réseau tangibles - il utilise des sockets comme vous. MPI vous fournira toutefois beaucoup des fonctionnalités dont vous auriez besoin pour gérer de nombreux nœuds, c’est-à-dire la synchronisation entre les nœuds.
Les performances ne sont pas la seule considération dans ce cas, même sur les clusters hautes performances. MPI propose une API standard et est "portable". Il est relativement simple de basculer une application entre les différentes versions de MPI.
La plupart des implémentations MPI utilisent des sockets pour la communication basée sur TCP. Les chances sont bonnes qu'une implémentation MPI donnée soit mieux optimisée et fournisse un passage de message plus rapide qu'une application développée localement utilisant des sockets directement.
En outre, si vous avez la possibilité d’exécuter votre code sur un cluster doté d’InfiniBand, le calque MPI résumera ces modifications. Ce n'est pas un avantage trivial: il est très difficile de coder une application pour qu'elle utilise directement la mise en œuvre d'OFED (ou d'un autre verbe IB).
La plupart des applications MPI incluent de petites applications de test qui peuvent être utilisées pour vérifier que la configuration réseau est correcte, indépendamment de votre application. C'est un avantage majeur lorsque vient le temps de déboguer votre application. La norme MPI inclut le "pMPI". interfaces, pour profiler les appels MPI. Cette interface vous permet également d’ajouter facilement des sommes de contrôle ou une autre vérification de données à toutes les routines de transmission de messages.
MPI présente l’avantage de pouvoir effectuer des communications collectives. Faire des émissions / réductions en O (log p) / * p est votre nombre de processeurs * / au lieu de O (p) est un gros avantage.
Je devrai être d’accord avec OldMan et Freespace. À moins que vous ne connaissiez une mesure spécifique et une amélioration de certains indicateurs utiles (performances, maintenabilité, etc.) par rapport à MPI, pourquoi réinventer la roue. MPI représente une grande quantité de connaissances partagées concernant le problème que vous essayez de résoudre.
Vous devez résoudre un très grand nombre de problèmes, qui vont au-delà du simple envoi de données. L'établissement et la maintenance de la connexion deviendront tous votre responsabilité. Si MPI est l’abstraction exacte (cela ressemble à ce que vous avez besoin), utilisez-la.
À tout le moins, utiliser MPI et le refactoriser ultérieurement avec votre propre système est une bonne approche, qui coute l'installation et la dépendance de MPI.
J'aime particulièrement l'argument d'OldMan selon lequel MPI vous en donne beaucoup plus que la simple communication par socket. Vous obtenez une multitude d'implémentations informatiques parallèles et distribuées avec une abstraction transparente.
La transmission de message est un paradigme et non une technologie. Dans l'installation la plus générale, MPI utilisera des sockets pour communiquer. Vous pouvez voir une accélération en passant à MPI, mais uniquement dans la mesure où vous n'avez pas optimisé votre communication par socket.
Comment votre application est-elle liée? Est-il lié au transfert des blocs de données vers les nœuds de travail ou est-il lié à la communication lors du calcul?
Si la réponse est "à cause de la communication" le problème est alors que vous écrivez une application à couplage étroit et essayez de l'exécuter sur un cluster conçu pour des tâches à couplage lâche. Le seul moyen de gagner en performance sera d'obtenir un meilleur matériel (commutateurs plus rapides, infiniband, etc.) ... vous pourriez peut-être emprunter du temps sur le HPC de quelqu'un d'autre?
Si la réponse est "bloc de données" les transferts envisagent ensuite d’attribuer aux travailleurs plusieurs blocs de données (afin qu’ils restent occupés plus longtemps) & amp; compresser les blocs de données avant le transfert. C'est une stratégie qui peut aider dans une application faiblement couplée.
Je n’ai pas utilisé MPI, mais j’ai utilisé pas mal de sockets. Il y a quelques points à considérer sur les sockets haute performance. Faites-vous beaucoup de petits paquets ou de gros paquets? Si vous faites beaucoup de petits paquets, pensez à désactiver l’algorithme Nagle pour une réponse plus rapide:
setsockopt (m_socket, IPPROTO_TCP, TCP_NODELAY, ...);
De plus, l’utilisation de signaux peut être beaucoup plus lente lorsque vous essayez de faire passer un grand volume de données. Il y a longtemps, j'ai créé un programme de test dans lequel le lecteur attendait un signal et lisait un paquet. Il atteindrait environ 100 paquets / s. Ensuite, j'ai juste bloqué les lectures et obtenu 10 000 lectures / s.
Le but est d’examiner toutes ces options et de les tester. Différentes conditions rendent différentes techniques plus rapides / plus lentes. Il est important de ne pas simplement obtenir des avis, mais de les mettre à l'épreuve. Steve Maguire en parle dans "Writing Solid Code". Il utilise de nombreux exemples contre-intuitifs et les teste pour déterminer ce qui rend le code meilleur / plus rapide.
MPI utilise des sockets en dessous, donc la seule différence devrait être l’API avec laquelle votre code s’interface. Vous pouvez affiner le protocole si vous utilisez des sockets directement, mais c'est à peu près tout. Que faites-vous exactement avec les données?
MPI Utilise des sockets, et si vous savez ce que vous faites, vous pouvez probablement obtenir plus de bande passante, car vous n’avez pas besoin d’envoyer autant de métadonnées.
Mais vous devez savoir ce que vous faites et il est probable que le risque d'erreur soit plus grand. Essentiellement, vous remplaceriez votre MPI par votre propre protocole de messagerie.
