Besteht die virtuelle Maschine aus einem heterogenen Netz von
Workstations, so verfügen die einzelnen Hosts zum einen über
unterschiedliche Rechenleistungen, zum anderen sind sie
je nach der Zahl der übrigen Prozesse und Benutzer unterschiedlich
stark ausgelastet.
Dieses wird bei der oben beschriebenen Parallelisierung berücksichtigt,
da die einzelnen Tasks kleine Teilprobleme erhalten und nach deren
Abarbeitung selbständig beim Master neue Arbeit erfragen.
Tasks auf weniger starken oder mehr ausgelasteten Hosts stellen somit
weniger Anfragen, da sie für die Suche in ihren Teilbäumen eine
längere Zeit benötigen als diejenigen Tasks, welche auf
leistungsfähigeren Rechnern laufen.
In einem Workstation-Cluster kommunizieren alle Maschinen über einen
gemeinsamen Bus,
d.h., die Kommunikation zwischen allen Knoten ist gleich teuer, wobei die
Kommunikationsbandbreite jedoch konstant und unabhängig von der Zahl
der Maschinen ist.
Aus diesem Grund ist ein Master-Slave Ansatz bei der Parallelisierung
durchaus legitim.
In einem
MPP
sind die Prozessoren zwar alle gleich stark und stehen einem einzelnen
Benutzer im Normalfall exklusiv zur Verfügung, jedoch ist die Zahl der
Prozessoren hier viel höher.
Auf Parallelrechnern ist die Kommunikation wesentlich schneller, und die
Bandbreite steigt in der Regel mit der Größe des Systems.
Da hier aber die Prozessoren in einer bestimmten Topologie untereinander
verbunden sind, ist die Kommunikationsgeschwindigkeit abhängig von dem
Abstand der kommunizierenden Prozessoren.
Steht für die Kommunikation kein spezielles Routing-Netzwerk zur
Verfügung, so werden
die Nachrichten durch die Prozessoren hindurchgereicht, so daß jede
Kommunikation die
Rechenleistung der daran beteiligten Prozessoren hemmt.
Für den oben beschriebenen Master-Slave Ansatz bedeutet dies, daß zum
einen die Kosten für jede Kommunikation zwischen einer Slave-Task und
dem Master unterschiedlich teuer sind, zum anderen verdichtet sich das
Nachrichtenaufkommen in der Nähe desjenigen Prozessors, der die
Master-Task hält ( Bottleneck).
Auf einem massiv-parallelen System sollte ein Lastverteilungsverfahren
gewählt werden,
welches die Last nur zwischen direkt benachbarten Prozessoren austauscht,
um den Kommunikationsoverhead möglichst gering zu halten.
PVM
stellt hier jedoch keine weiteren Routinen zur Programmierung von
MPPs
zur Verfügung,
etwa zur Bestimmung der Position der Tasks im parallelen System oder zur
Ermittlung der
TIDs
von Tasks auf benachbarten Prozessoren, um für die Kommunikation kurze
Wege nutzen zu können.
Die Architektur der auf dem Markt erhältlichen MPPs variiert stark, und jeder Hersteller bietet für sein System Programmierumgebungen an, welche direkt auf die Hardware zugeschnitten sind und somit die höchstmögliche Leistung erreichen. Eine PVM -Implementation für einen Parallelrechner setzt oft auf diese Hardware-spezifischen Programmierumgebungen auf und muß einen gemeinsamen Bus simulieren, was die Kommunikationsleistung auf dem MPP im Vergleich zur systemeigenen Programmierumgebung deutlich herabsetzt. Auch kann man, wenn man portabel programmieren will, viele systemspezifische Eigenschaften nicht ausnutzen. Dieses ist aber wichtig, wenn ein paralleles Programm skalierbar sein soll, d.h., wenn es auch große Systeme effizient nutzen soll.