Zwei Gründe können gegen die Verwendung von Octave auf der hydra sprechen: Das Umstellen des Matlab-Programms auf Octave ist zu aufwendig (aller versprochenen Kompatibilität zum Trotz) oder man möchte einen eigenen parallelen Algorithmus implementieren, der über die implizite Veclib-Parallelität hinausgeht. Nun bietet Matlab zwar die Möglichkeit, mit dem cmex-Compiler eigene C-Programme zu übersetzen und dynamisch in Matlab einzubinden, aber das Ergebnis ist immer ein HP-UX-Programm. Damit kann es auf der hydra zwar ausgeführt werden, bleibt aber skalar.
An dieser Stelle hilft nun folgender Gedanke weiter: Wenn das direkte Ausführen eines parallelen Teils aus Matlab heraus unmöglich ist, dann muß man eben ein zweites Programm (``Slave'') haben, das die parallele Rechnung übernimmt und mit Matlab Daten austauschen kann. Zur Kommunikation kommen nur Mechanismen in Frage, die unter HP-UX möglich sind, z.B. die HP-UX-Shared-memory-Routinen. [1] Damit ergibt sich folgende Struktur:
Matlab: ... normale matlab-Befehle ... result = mymat(input) ... Interface (mymat.c): Input von Matlab holen Shared-Memory-Segment besorgen Daten in dieses Segment kopieren Slave aufrufen (mit system) Ergebnis aus Shared Memory in Matlab-Bereich kopieren aufräumen Slave (slave.c): Shared Memory Segment einbinden parallele Berechnung ausführen, dabei Daten und Ergebnis direkt im Shared Memory halten aufräumen
Das Programmieren von Routinen, die in Matlab eingebunden werden, und die Shared-Memory-Bearbeitung sind vielleicht auf den ersten Blick verwirrend, sehen aber im Prinzip immer gleich aus. Das im Anhang (Abschn. 2.5 bzw. direkt im WWW) beigefügte einfache Beispiel kann daher als Ausgangspunkt für eigene Versuche dienen. Das Interface-Programm mymat.c wird auf einer HP-UX-Maschine mit
cmex mymat.cübersetzt. Innerhalb von Matlab kann man es nun wie jeden anderen Matlab-Befehl verwenden, etwa
a = rand(100,100); b = mymat(a); plot(diag(b));
Das Object-File mymat.mexhp7 wird dann automatisch an matlab gebunden.
Die Performance von solchen Matlab/Shared-Memory-Programmen entspricht für den Anteil der Slave-Berechnung i.W. der des Slave-Programms selbst, wobei noch ein gewisser Overhead für das Anlegen des Shared-Memory-Segments und das Kopieren der Daten berücksichtigt werden muß. Da die Matlab-internen Matrix-Routinen sehr schlecht an die Architektur angepaßt sind, ergeben sich durch den kombinierten Effekt guten SPP-Codes und der Parallelisierung teilweise dramatische Verbesserungen, so daß sich der Aufwand wirklich lohnt.
Peter Junglas, Tel.: 3193
[1] nicht mit dem SPP-UX Shared Memory zu verwechseln, auch wenn jenes in diesem angelegt wird