Diskussion:Message Passing Interface
Meiner Meinung nach ist MPI kein Protokoll. Ein Protokoll ist eine exakte Vereinbarung, welche auch die Kommunikation zwischen verschiedenen MPI Bibliotheken erlauben müsste. Dies geht aber gerade nicht. Vielmehr ist es die Spezifikation einer Bibliothek, siehe ersten Link.
- Zustimmung. MPI definiert die Programmierschnittstelle, nicht das Netzwerkprotokoll. --Matthäus Wander 14:59, 26. Jul. 2023 (CEST)
synchron / asynchron
[Quelltext bearbeiten]In Absatz 1.1 steht, die Funktionen MPI_Send und MPI_Recv seien "blockierend und asynchron", als Erläuterung heisst es weiter: "MPI_Send blockiert, bis die Nachricht vollständig übermittelt wurde" Dann wäre MPI_Send doch aber synchron? (siehe Synchrone Kommunikation) --grondhal
Dieser Teil im Artikel war nicht ganz korrekt: Laut Standard muss nur sichergestellt sein, dass nach der Rückkehr von MPI_Send der entsprechende Sendepuffer wiederverwendet werden kann. Die Nachricht kann also auch bspw. irgendwo zwischengespeichert werden. (Artikel korrigiert)
Kommunikation im Cluster
[Quelltext bearbeiten]Ich halte es für unglücklich ausgerechnet TCP als Beispiel für Kommunikation innerhalb eines Clusters zu wählen; insbesondere im Zusammenhang mit MPI. TCP ist ein datenstromorientiertes Übertragungsprotokoll. Aufgrund der fehlenden Nachrichtentrennung ist es äusserst aufwändig nachrichtenbasierte Kommunikation über TCP zu realisieren. Auch setzen die meisten MPI-Implementierungen nicht auf einem Protokoll der Transportschicht sondern eher auf der Sicherungssschicht auf. Als Besipiel würden sich hier also eher Ethernet oder andere, Cluster-spezifische Protokolle wie Myrinet oder Infiniband anbieten. Ich möchte mich dringend dafür aussprechen das zu ändern!
Implementierungen
[Quelltext bearbeiten]Bevor meine Anederungen wieder als Unsinn tituliert werden: IMO macht es absolut keinen Sinn, einen Implementierungsteil Fotran oder Java zu haben und da nichts reinzuschreiben. Entweder es gibt Implementierungen fuer diese Sprachen oder nicht. Fotran wird von Open MPI,MPICH und MVAPICH unterstuetzt also sollte das erwaehnt werden (Vielelicht auch durch die kombinierte Kategorie C/C++/Fortran). Auch wenn das wie weiter oben "obligatorisch" ist bezweifle ich irgendwie, dass die Pythonimplementierungen das koennen.... (nicht signierter Beitrag von 132.187.40.88 (Diskussion | Beiträge) 16:46, 9. Jul 2009 (CEST))
Defekte Weblinks
[Quelltext bearbeiten]| Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt. |
|---|
|
- http://www.mpi-forum.org/docs/mpi-20-html/mpi2-report.html
- Vielleicht ist eine archivierte Version geeignet: archive.org
- Wechsel zwischen http und https erforderlich
- http://www-unix.mcs.anl.gov/mpi/
- Vielleicht ist eine archivierte Version geeignet: archive.org * webcitation.org
- Artikel mit gleicher URL: Rechnerverbund (aktuell)
- http://phase.hpcc.jp/mirrors/mpi/mpich/index.html
- Vielleicht ist eine archivierte Version geeignet: archive.org
- Netzwerk-Fehler (7) andere Artikel, gleiche Domain
- http://www-unix.mcs.anl.gov/mpi/mpich2/
- Vielleicht ist eine archivierte Version geeignet: archive.org
– GiftBot (Diskussion) 18:47, 3. Dez. 2015 (CET)
Implementierungen sollten Protokoll nennen
[Quelltext bearbeiten]Er legt dabei eine Sammlung von Operationen und ihre Semantik, also eine Programmierschnittstelle fest, aber kein konkretes Protokoll und keine Implementierung.
Laut Einleitung definiert der MPI Standard lediglich die API und die Semantik, aber kein Protokoll und keine Implementierung. Daher reicht es nicht aus Implementierungen verschiedener Sprachen zu nennen, ohne das zugrunde liegende Protokoll (Auf Transportebene: UDP, TCP, pgm ... auf Anwendungsebene: ?!?!?!) zu nennen.
Ohne das Protokoll zu nennen ist eine Implementierung ziemlich nutzlos, wenn man mit verschiedenen Sprachen arbeitet. Da die Wahrscheinlichkeit, dass verschiedene Protokolle zum Einsatz kommen, nicht allzu gering sein dürfte. --95.91.242.234 11:26, 18. Jun. 2022 (CEST)