MATLAB und Shared Memory - eine Zwangsehe

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