ICSE: Coding von Multi-Core-Prozessoren

Zu Beginn der Schweizer ICSE 2012 (International Conference on Software Engineering) gab es gleich einen harten Brocken zu schlucken. Victor Pankratius vom MIT referierte über "Multicore Software Engineering and Auto-Tuning", auf deutsch: Performance-Optimierung durch parallele Programmierung. Das Szenario: Nahezu alle neuen Desktop-PCs und Smartphones arbeiten heute mit Multi-Kern-Prozessoren: AMD Opteron 12 Cores, Sun Niagara 16 Cores, Intel SCC 48 Cores, nVida GTX >300 Cores. Ziehen alle Kerne an einem Strang und arbeiten parallel an einer Aufgabe, kann das die Performance von Apps extrem steigern. Nur hinken die Software-Entwickler zurzeit noch hinterher - und verschenken Optimierungspotenzial.

Kein triviales Problem

Die "Open Specifications for Multi-Processing" (OpenMP) etwa werden zurzeit in 46 Projekten erprobt. OpenMP eignet sich hervorragend für numerische Apps (Grafiken, Vektoren, Matrizen) und unterstützt die Programmiersprachen C, C++ und Fortran. Pankratius berichtet jedoch von zahlreichen, undokumentierten Fehlern in den Projekten. Oft seien falsche Annahmen über die Sichtbarkeit von Variabeln und die Ausführungsreihenfolge der Codezeilen der Grund, zugegeben in parallelem Soucecode ein nicht gerade triviales Problem.

Microsoft hat für seine .NET-Sprachen die "Task Parallel Library" (TPL) vorgestellt. die Parallelität als Methode parallel.for einführt und ab .NET 3.5 funktioniert. Schleifendurchläufe etwa, in denen ein und derselbe Sourcecode zehntausend oder hunderttausend Mal in gleicher Weise abgearbeitet wird, bieten sich zur Optimierung an. Die klassische For-Schleife in C# wird normalerweise ganz brav sequentiell, also hintereinander abgearbeitet:

for (int i = 0; i < 100000; i++) {

    a[i] = a[i]*a[i];  }

Durch die Parallelisierung der 100.000 Schleifendurchläufe gewinnen die zwei Zeilen Code auf elegante Weise erheblich an Tempo:

Parallel.For(0, 100000, delegate(int i) {

     a[i] = a[i]*a[i]; });

Microsofts "Parallel Library" sei noch in einem frühen Experimentierstadium, da könne sich noch jede Menge ändern, meint Pankratius. Abgesehen von Bibliotheken und Frameworks müssen Software-Entwickler auf dem Weg zu optimiertem, parallelem Sourcecode viele mentale Fallstricke vermeiden: zum Beispiel die Granularitätsfalle. Der Software-Guru erzählt von seinem ersten Stück Parallelcode, wo er akribisch alle theoretisch parallelisierbaren Threads auch programmiert habe. Mit dem Ergebnis: Der parallele, also auf mehrere Prozessorkerne verteilte Code lief langsamer als das simple sequentielle Programm. Pankratius hatte zu viel parallelisiert: Der kommunikative Overhead zwischen den Subroutinen zwang die Performance in die Knie.

Nächste Seite: Erfolgsstrategien & Chip-Design