Wer die stürmische Entwicklung der Mikroprozessor-Technik in den letzten beiden Jahrzehnten verfolgt hat, hörte sicherlich schon von Gordon Moores empirischen Gesetz nach dem sich die Anzahl der Transistorfunktionen auf einem Chip alle 18 Monate verdoppelt und damit die Rechnergeschwindigkeit atemberaubend schnell anstieg.
Auf einem Apple II war es unter UCSD-Pascal möglich, mittels Include-Dateien Programme mit ca. 1.300 Zeilen zu compilieren. Dieses hat mit Erstellung einer Listdatei auf Diskette etliche Minuten gedauert. Heute kann man den "nächtlichen Build" der vielen Millionen Programmzeilen von Windows 7 in einigen Stunden auf einem Quad Core Prozessor erledigen (Aussage eine Microsoft-Managers in c't).
Die Technik der Mikroprozessoren und auch anderer CPUs hat jedoch eine technische Grenze erreicht. Intel hat es nicht mehr geschafft, einen Pentium-Prozessor mit mehr als 4 GHz Taktfrequenz zu realisieren. Da die erzeugte Abwärme überproportional mit der Frequenz wächst, würde die spezifische Wärme in W / mm2 eine Herdplatte mühelos übertreffen, d.h. solche Prozessoren würden den Wärmetod sterben, da eine Kühlung nicht mehr möglich ist. Zusätzlich treten als Problem Leckströme auf, die zu undefinierten Bitzuständen führen können.
Mit Ausnahme von mir hat noch niemand das "Dezimal-Bit" erfunden (nur in ironischem Umfeld). Die Bit-Zustände "0" bzw. "1" müssen natürlich zweifelsfrei sein. Die Schlussfolgerung aus obigem lautet: Die Zeit der sequentiellen Programmierung geht langsam zu Ende. Eine Geschwindigkeitssteigerung ist nur noch durch parallele Verarbeitung möglich, sofern die Algorithmen schon optimiert sind.
Anmerkung: Anfang der 80er Jahre hat der Lauf eines Datenmodell-Generators auf einem Prozessrechner ca. 40 Stunden benötigt. Dummerweise hatten mittendrin die Operateure nachts die zentrale Stromversorgung dieses Rechners abgeschaltet. Durch Neuimplementierung des Flaschenhalses "Sortiervorgang" mittels Quicksort wurde die Laufzeit dann auf 2 Stunden reduziert.
Sollten solche Probleme auf Mikroprozessoren vorkommen, bleibt den Softwareentwicklern nichts anderes übrig als sequentielle Programmierung durch verteilte Programmierung zu ersetzen. Bisher wurde dafür in jedem Projekt das Rad von Neuem erfunden. Dies ist natürlich nicht effizient. Daher schauen wir uns nach möglichen Standards dafür um (nach Schwierigkeit sortiert):
- openMP (open Multi Processing)
- MPI (Message Passing Interface)
- CORBA (Common Object Request Broker Architecture)
Diese Bereiche der Softwaretechnik sind unter dem Sammelnamen IPC = Inter Process Communication bekannt. Alle diese Standards sind selbstverständlich rechnerunabhängig und können daher auch jenseits der PC-Technik eingesetzt werden.
OpenMP
OpenMP ist ein internationaler Standard, der verteilte Berechnungen auf Prozessoren mit gemeinsamen Hauptspeicher ermöglicht, z.B. Multi Core Prozessoren wie Intel Core2Duo, i5, i7 oder entsprechende CPUs von AMD. Damit kann der Compiler mit geringer Unterstützung durch den Softwareentwickler z.B. Schleifen parallel berechnen, sofern die Teilberechnungen voneinander unabhängig sind.
Beispiel: ex = summe (xn / n!, n=0..unendlich)
Eine CPU mit 2..1024 Kernen wäre für diese Art von Berechnung also nützlich.
OpenMP ist für C/C++ und Fortran spezifiziert (nein, für Java nicht) und wird für das Hochleistungsrechnen (HPC = High Performance Computing) eingesetzt.
Die Implementierung erhält man durch die Compiler-Hersteller GNU, Microsoft, Intel u.a. Ein Informationsportal findet sich unter www.openmp.org.
MPI
MPI ist ebenfalls ein internationaler Standard für portable parallele Programmierung, bei dem die Berechnung auf viele Rechnerknoten verteilt wird, die über Rechnernetzwerke, z.B. TCP/IP kommunizieren. Dieses lohnt sich natürlich nur, wenn der Kommunikationsaufwand gegenüber Einzelberechnung auf einem Rechnerknoten vernachlässigbar ist. Dabei werden typischerweise Hunderte, Tausende oder 100.000 Prozessoren parallel eingesetzt.
MPI steht in C/C++ und Fortran 90 zur Verfügung.
Beispiel: Wettervorhersage; dabei ist ein gekoppeltes System partieller Differentialgleichungen (pDGL) numerisch zu lösen, da eine analytische Lösung unmöglich ist. Unter anderem sind die physikalischen Parameter nicht hinreichend bekannt, um an eine symbolische Lösung auch nur zu denken. Man stelle sich ein Gitter von z.B. 10 km Kantenlänge über Deutschland vor und dann noch in die Höhe. Natürlich stehen nicht an allen Gitterpunkten Sensoren um Temperatur, Luftdruck und 3-dimensionale Windgeschwindigkeit zu erfassen.
Dieses ist "Hardcore-Programmierung" in Reinkultur. Es können auch MPI und openMP gemeinsam für solche Probleme eingesetzt werden.
Die Referenz-Implementierung ist kostenlos.
CORBA
CORBA ist ein Standard um beliebige Nachrichten zwischen mehreren Rechnern zu transportieren. Dabei können die Rechner verschiedene Betriebssysteme haben, z.B. Linux, Windows ab NT, VMS, andere Unixe. Binäre Daten können ausgetauscht werden zwischen Rechnern mit unterschiedlicher Byte-Anordnung, z.B. Intel, VAX mit "Little Endian" und älteren MacIntosh-Rechnern auf Motorola 68.000 Basis mit "Big Endian" Format.
| Little Endian (Intel, VAX, etc.) | Das niederwertigste Byte von Integer-Zahlen und Gleitpunkt-Zahlen steht auf niedrigeren Adressen, das höherwertigste Byte steht auf höheren Adressen |
| Big Endian (Motorola 68.000) | Das höherwertigste Byte von Integer-Zahlen und Gleitpunkt-Zahlen steht auf niedrigeren Adressen, das niederwertigste Byte steht auf höheren Adressen |
Die CORBA-Software, die den Status von Middleware (zwischen Betriebssystem und Anwendersoftware) hat, dreht also bei Bedarf die Anwenderdaten um, sodass es auf dem Zielrechner passt. Dabei sind Gleitpunkt-Zahlen (z.B. 1,23) nach dem IEEE 754 Standard vorausgesetzt. Dieses wurde von Intel seit dem 80387-Koprozessor implementiert. Andere Hersteller wie AMD, DEC usw. können dieses natürlich auch. Strings werden auf ASCII-Basis vorausgesetzt, EBCDIC von IBM-Großrechnern wird meines Wissens nicht unterstützt.
Historische Wortlängen, z.B. 48 Bit bei TR440 oder 22 Bit bei den Apollo-Bordrechnern sind daher heute nicht mehr so angesagt. Jetzige Rechner haben eine 2er Potenz als Wortlänge (8, 16, 32, 64, 1024 Bit etc.)
Die unterschiedliche Byte-Anordnung in den Verwaltungsdaten wird von der Netzwerksoftware transparent erledigt. Das Netz spricht "Big Endian", d.h. bei Übertragungen mittels TCP/IP muss die IP-Adresse eines Intel-Rechners gedreht werden, diejenige eines älteren Macs hingegen nicht. Dieses erfolgt transparent durch Netzwerk-Funktionen, die auf Intel also die IP-Adresse "tatsächlich" drehen und auf älteren Macs nur "Dummy-Funktionen" sind. Darum muss sich also der Anwendungsprogrammierer nicht im Detail kümmern. Die Byte-Anordnung in den Anwender-Nutzdaten wird durch die Netzwerksoftware (z.B. TCP/IP) NICHT gedreht. Darum muss sich der Anwender kümmern oder eine Software wie CORBA.
CORBA ist ein sehr allgemeiner Standard zur Übertragung von Nachrichten. In der Vergangenheit wurden z.B. 3(4)-schichtige Rechnersysteme (n*Hilfsrechner, 2*Vorrechner, 2*Hauptrechner, 1*Hintergrundrechner) verkauft und in jedem Projekt wurde die Middleware für die Kommunikation erneut erfunden (vor TCP/IP). Diese Produkte hatten dann so "schöne Namen" wie:
- E/A-Verwaltung
- queuing system
- Nahtstellen-System
Letzteres ist unter dem Namen "message passing system" international für diese Gruppe von Software gebräuchlich. Im Bereich der Leittechnik z.B. bei EVUs war dies der Standard.
CORBA ist definiert für C++ und Java.
Eine Referenz-Implementierung von CORBA wurde durch Professor Douglas C. Schmidt von der Vanderbilt-Universität in Nashville/USA durchgeführt unter dem Namen ACE = Adaptive Communication Environment. Mitgewirkt haben dabei u.a. Siemens, Microsoft, Nasa und viele andere Partner. Diese Implementierung unterstützt nur C++.
Diese Implementierung ist kostenlos erhältlich für Unixe und Windows + Microsoft Visual Studio (2003, 2005, 2008) ab NT.
Anm. d. Red.: Nach dieser ausführlichen Übersicht wird dem geneigten Leser eine Verschnaufpause gegönnt, bevor die drei angesprochenen Standards in weiteren Teilen des Artikels näher vorgestellt werden.