next up previous
Next: Fazit und Alternativen Up: PVM auf MPPs Previous: Die Parallelisierung

Die Portierbarkeit dieses Ansatzes

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.



next up previous
Next: Fazit und Alternativen Up: PVM auf MPPs Previous: Die Parallelisierung



WWW-Administration
Thu Jul 13 19:06:34 MET DST 1995