Walter Tichy über empirische Software-Forschung und Parallelismus

Walter F. Tichy (Jahrgang 1952) ist seit 1986 Professor am Karlsruher Institut für Technologie (KIT), der früheren TH Karlsruhe. Er ist Mitglied der kollegialen Leitung des Instituts für Programmstrukturen und Datenorganisation (IPD). Seine Arbeitsgebiete sind empirische Softwaretechnik, Konfigurationskontrolle,  paralleles Rechnen und Sprachverarbeitung in der Softwaretechnik. Im Forschungszentrum Informatik (FZI) leitete er u.a. das von der Firma SUN autorisierte Java Center. Bevor er den Ruf nach Karlsruhe annahm, war er Senior Scientist bei der Carnegie Group, Inc., in Pittsburgh, PA, und Assistenzprofessor an der Purdue University in West Lafayette, IN. Er ist in Fachkreisen bekannt als der erste Entwickler eines Software-Versionsverwaltungssystems  (RCS). Mehrere seiner Fachbeiträge erregten weltweites Aufsehen. Nebenbei übt Tichy eine intensive Beratertätigkeit in der Industrie aus. Nach dem Studium der Informatik an der TU München (1974) absolvierte Tichy ein Masterprogramm an der Carnegie Mellon University (CMU) in Pittsburgh (1976) und erlangte dort 1980 den Ph.D. 

Bertal Dresen (BD): Als ich Sie das letzte Mal bei einer Veranstaltung Ihres Instituts besuchte, war ich überrascht, welche dedizierte Meinung Sie bezüglich gewisser Software-Produkte und ihrer Hersteller äußerten. Das passte eigentlich nicht zu dem Bild, das man sich in Deutschland allgemein von einem Universitätsprofessor macht. Hängt das mit Ihren ‚Lehrjahren‘ in Amerika zusammen? Sollten Ausbilder in technischen Fächern verfolgen, was in der Praxis geschieht? Wie weit dürfen Akademiker sich zu Fürsprechern bestimmter im Markt vertretener Produkte oder Methoden machen?

Walter Tichy (WT): Zunächst hat jedermann Meinungs- und Redefreiheit, auch Professoren. Während Universitäten gut beraten sind, sich neutral zu verhalten, müssen sich Professoren nicht unbedingt zurückhalten. Im Gegenteil! Manchmal müssen sie unangenehme Wahrheiten aussprechen. Insbesondere dürfen sie die Tauglichkeit von Produkten und Methoden wissenschaftlich vergleichen und die Ergebnisse publizieren. Dahinter steckt dann natürlich eine ganze Menge Arbeit und mehr als nur eine Meinung.

Selbstverständlich verfolge ich die Entwicklungen in der Praxis, denn mein Fachgebiet, die Softwaretechnik, wird in Lehre und Forschung wesentlich von Entwicklungen in der Industrie beeinflusst. Das hat mit meinen Lehrjahren weniger zu tun als mit meinem Anspruch, zeitgemäße Lehre und international beachtete Forschung zu leisten. Diesem Anspruch gerecht zu werden, sollte Ziel jedes Wissenschaftlers sein, egal wo er auf der Welt arbeitet.

Stellen Sie sich vor, ich würde noch in der Sprache Pascal von 1970 ausbilden, anstatt in einer modernen Sprache. Programmiersprachen werden aber heute hauptsächlich von Firmen definiert. Oder denken Sie an die agilen Methoden  ̶  hier muss ich leider feststellen, dass inzwischen zahlreiche wissenschaftliche Untersuchungen belegen, dass die viel gepriesenen Methoden Paarprogrammierung und testgetriebene Entwicklung nicht besser sind als traditionelle Methoden. Diese Erkenntnis ist natürlich unangenehm für Leute, die diese Methoden propagieren, aber ganz wichtig für die Praktiker.

BD: Die Softwaretechnik an den Hochschulen (das, was wir mit dem englischen Ausdruck ‚Software Engineering‘ meinen) scheint immer noch um ihr Selbstverständnis zu ringen. Dabei dauert die Diskussion schon über 40 Jahre, nämlich seit der Garmischer Tagung von 1968. Liegt das Problem darin, dass unsere Studenten die Mathematik nicht mögen (die Durchfallquoten sollen sehr hoch sein) oder fehlt es an der pädagogisch richtigen Darbietung von praktischem Wissen?

WT: Ich weiß nicht, wie Sie darauf kommen, dass Softwaretechnik um Selbstverständnis ringt. Sicher nicht bei den Firmen, die unsere Absolventen einstellen, und das ist was bei unseren Studierenden zählt. Hier einige Beispiele zum Bedarf an Softwareentwicklern: Am heutigen Montag bekam ich eine neue Stellenanzeige eines großen Rekrutierungsunternehmens. Das hatte mich schon in der letzten beiden Wochen angeschrieben, aber mit anderen Angeboten. Letzten Donnerstag und Freitag fand vor meinem Büro eine Veranstaltung einer bekannten Beratungsfirma statt. Alle Angebote richten sich an Softwaretechniker. Sogar Leiter für Software-Entwicklung in Indien wurden gesucht.

In der gleichen Woche kam auch noch ein Angebot einer weiteren Vermittlungsfirma, die Interviews in mehreren Großstädten anbot. Außerdem erhielt ich einen Brief der Bonding-Messe mit der Bitte, ich solle die Veranstaltung in meinen Vorlesungen ankündigen. Die Woche davor bekam ich ein Schreiben einer Firma, die in meiner Vorlesung eine Firmenpräsentation geben möchten, und, wenn ich wollte, auch gleich die ganze Vorlesung halten würde. Tatsächlich könnte ich in jeder Vorlesung einen ganzen Firmenwerbeblock einbauen! In der gleichen Woche erhielt ich auch noch das Angebot eines ehemaligen Habilitanden, der eine komplette Lehrveranstaltung für mich halten möchte (das ganze Wintersemester), nur um Kontakte zu knüpfen. Das Angebot war durchaus ernst gemeint, da er diese Vorlesung während seiner Zeit am KIT schon gehalten hatte. Mindestens zwei Anfragen pro Woche bzgl. Absolventen  ̶  so geht das nun schon seit Jahresanfang.

Der Mangel an Softwareentwicklern ist wieder fast so groß wie zu Zeiten der Dot-Com-Blase. Die Angebote, Studierende nach Mallorca zu Firmenpräsentationen zu locken, werden wohl bald wieder auftauchen. Von mangelnder Akzeptanz kann keine Rede sein. Auch am KIT selber nicht. Diejenigen, die der aufstrebenden Informatik eventuell kritisch gegenüber standen, sind inzwischen pensioniert. (Die Informatik am KIT wird dieses Jahr 40, und das ist länger als die übliche Professorenlaufbahn). Für die Kollegen von heute war die Informatik bereits vor ihnen da. Der Mangel an Software-Kompetenz ist diesen Kollegen durchaus bewusst und eher peinlich. Wenn man aber das jüngste Ergebnis der Exzellenzinitiative betrachtet, von der nur an einem einzigen Standort ein Informatik-Cluster gefördert wird, könnte man durchaus zu dem Schluss kommen, das die Informatik insgesamt als nicht so wichtig angesehen wird wie die traditionellen Wissenschaften.

Hier ein kleines Erlebnis: Vor meiner Softwaretechnik-Vorlesung fand eine Experimentalphysik-Veranstaltung statt. Da saß ein Häuflein von etwa zehn Studenten in einem Hörsaal, der 400 Menschen fasst. Ein junger Professor leitete Formeln her und zwei festangestellte Techniker waren ausschließlich dafür da, die Versuche aufzubauen. Als die Vorlesung endete, strömten etwa 340 Informatikstudenten in den Hörsaal. Zehn gegen 340  ̶  das war ein ziemlicher Kontrast, sowohl in der Menge als auch in schierer Energie (was sich in Lautstärke äußerte). Wer tut wohl mehr für die Zukunft Deutschlands: Die Physik oder die Informatik? Dennoch wird die Physik ungleich besser gefördert. Und die Ironie der Geschichte ist die: Physiker, die nicht eine wissenschaftliche Laufbahn aufnehmen, finden ja keine Physikindustrie vor, die sie einstellen würde. Daher verdingen sich viele von ihnen als Programmierer.

BD: [Hier muss ich eingestehen, dass meine vorhergehenden Fragen falsch zu verstehen waren. Niemand bestreitet, dass der Bedarf an Software-Entwicklern enorm ist. Mich beschäftigt die Frage, warum das seit 1968 andernorts eingeführte Software-Engineering-Studium in Deutschland kaum Beachtung gefunden hat. Ich hatte das Thema vor kurzem schon einmal aufgegriffen und werde es vermutlich nochmals tun]. Sie selbst haben vor über zehn Jahren unsere Fachkollegen aufgerüttelt, als Sie darauf hinwiesen, dass in der Forschung empirische Methoden zu kurz kommen. Hat sich dieses Problem gelöst? Wieweit können Hochschulen überhaupt empirische Forschung machen, deren Ergebnisse auch Praktiker überzeugen?

WT: Da hat sich inzwischen sehr viel verbessert. Ich war gerade auf der International Conference on Software Engineering (ICSE2012), der größten Veranstaltung für Softwaretechnik-Forschung. Sie fand dieses Jahr in Zürich statt. Fast alle wissenschaftlichen Beiträge, die ich mir anhörte, hatten einen beeindruckenden empirischen Evaluierungsanteil. Die meisten Arbeiten benutzen dazu Daten aus Projekten, insbesondere aus Datenbanken, die ganze Projekthistorien speichern, z.B. mit CVS und RCS :).

Hierzu ein Beispiel. Westley Weimer von der Universität von Virginia und seine Studenten hatten ein Verfahren entwickelt, das einige Fehlertypen in Software automatisch korrigieren kann. Die Idee alleine ist revolutionär — man stelle sich das vor: Defekte in der Software werden automatisch korrigiert! Man braucht nicht etwa formale Spezifikationen dazu, sondern lediglich automatisch ablaufende Testfälle, die die Defekte anzeigen. Das Verfahren kopiert Code von ähnlichen, aber korrekten Stellen im Programm, passt sie an den fehlerhaften Stellen an und probiert sie anhand der Testfälle einfach durch. Hier wird offenbar die Redundanz in Programmen ausgenutzt [Übrigens eine weitere Form von Redundanz, die mein letzter Beitrag übersah]. Aber funktioniert das überhaupt in der Praxis? Weimer und seine Studenten gingen so vor: Sie nahmen sich eine Anzahl quelloffener Projekte vor, wählten 105 Defekte aus, die tatsächlich korrigiert worden waren, und gingen dann auf die Versionen zurück, die diese Defekte noch enthielten. Dann ließen sie ihren Automatismus darauf los. Dieser korrigierte 55 der 105 Defekte! Die zugehörigen Testfälle wiesen danach keine Fehler mehr auf und die übrigen Testfälle liefen ebenfalls korrekt. Da sie die automatische Korrektur auf einem gemieteten Cloudrechner laufen ließen, konnten sie auch die Kosten angeben: $8 pro korrigierten Fehler. Derart günstig arbeitet kein Softwaretechniker!

Untersuchungen, die menschliche Subjekte einsetzen, sind dagegen seltener. Das beeindruckendste Experiment ist von Dag Sjoberg, der 300 professionelle Programmierer aus drei Ländern heuerte, um die Eigenschaften von Paarprogrammierung zu untersuchen. Es handelt sich hier um das größte kontrollierte Experiment in der Softwaretechnik, das mir bekannt ist. Wegen der Verwendung von Profis dürfte es auch Praktiker überzeugen. [In einem früheren Eintrag dieses Blogs wurde das Sjobergsche Projekt bereits kommentiert,] Solche Experimente sind teuer (aber nicht teuer im Vergleich zu Experimenten in der Pharmazie). Wir können sie wohl nur bei wirklich wichtigen Fragen einsetzen. Aber Benchmarks, wie sie Weimer verwandte, sind eine kosteneffektive Alternative, um automatische Werkzeuge zu testen und zu verbessern. Inzwischen erwarten die Gutachter der besten Konferenzen derartige Validierungen. Ohne sie kann man dort nicht publizieren.

BD: Seit etwa fünf Jahren haben Sie Ihr Interesse auf das Thema ‚Mehrkernrechner‘ (engl. multicore processors) gerichtet. Hier drängt sich mir eine Reihe von Fragen auf. Fangen wir bei der Hardware an. Gilt das Mooresche Gesetz jetzt nur noch zur Hälfte, d.h. die Packungsdichte wächst weiter, aber nicht mehr die Leistung?

WT: Die Mooresche Regel gilt weiterhin. Sie besagt, dass sich die Anzahl der Transistoren mit jeder Chip-Generation verdoppelt. Heute benutzt man oft die Abwandlung, dass sich die Anzahl Prozessoren verdoppelt. Wie lange noch ist unklar. Die Erhöhung der Taktfrequenz  hat etwa 2004 ein Ende gefunden, schlicht weil die Chips zu heiß wurden. Die Mooresche Regel sagt übrigens nichts über die Taktfrequenz aus. Wichtig ist folgende Schlussfolgerung: Zukünftige Leistungssteigerungen werden nur noch über Parallelverarbeitung erreicht. Das so genannte „free lunch“, d.h. die automatische Steigerung der Rechenleistung, ist vorbei. Bei leistungshungrigen Anwendungen ist das Ende der sequentiellen Verarbeitung schon heute gekommen.

BD: Parallelität hat Software-Entwickler schon immer fasziniert. Nur stand der Aufwand in keinem Verhältnis zum Ertrag. Wir werden gezwungen, über Probleme nachzudenken, die sehr schwierig sind, zum Beispiel Wettläufe.  Wir müssen Programme testen in Konfigurationen, die sich nur schwer simulieren lassen. Wie sehen diese Probleme heute aus? Gibt es neue Ansätze, etwa zum Testen?

WT: In der Tat gibt es sehr ermutigende Ansätze. Gerade für das Aufdecken von Wettläufen gibt es inzwischen brauchbare Methoden. Eine dieser Methoden beruht auf den so genannten Vektoruhren von Fidge und Mattern von 1988. Vektoruhren erzeugen eine partielle Ordnung von Ereignissen in parallelen Programmen, wodurch ungeordnete Zugriffe auf gemeinsame Variable detektiert werden können. Ergänzende Methoden erzeugen alle möglichen Verschränkungen von konkurrenten Prozessen, wodurch zur Testzeit alle Wettlauffehler auftreten. Noch überraschender ist, dass man Wettläufe durch das Einführen von Sperren automatisch korrigieren kann, und das auch noch zur Laufzeit! Der Grund für diese erfreuliche Entwicklung liegt darin, dass Wettläufe eine sehr enge, klar definierte Defektart darstellen, nach der man viel gezielter suchen kann als nach generellen Fehler in der Programmlogik. Auch Blockaden kann man detektieren. Damit wird man wichtige Fehlerquellen bei der Parallelprogrammierung beherrschen können.

BD: Jetzt – so sagen Sie – haben wir gar keine Wahl mehr. Sollte man nicht lieber die Parallelität soweit verbergen wie es geht? Warum kann nicht alles im Betriebssystem abgefangen werden und der Anwender denkt weiter in sequentiellen Prozessen?

WT: Ich fürchte, das Verbergen der Parallelität wird nur in ganz eingeschränkten Fällen funktionieren. In allen Anwendungen, die wir inzwischen parallelisiert haben (und dabei waren einige sehr große) hätte eine Bibliothek wenig genutzt. Natürlich brauchen wir eine Bibliothek zur Prozessverwaltung und Synchronisation, aber wo und wie parallelisiert wird, mussten wir uns immer genau überlegen und mehrere Varianten durchprobieren. Aber das ist nicht verwunderlich: auch sequentielle Anwendungen benutzen zwar Bibliotheken, aber nur aus Bibliotheksaufrufen bestehen die wenigsten Anwendungen. Die Verarbeitungslogik muss immer noch von den Programmierern eingebracht werden. Auf der positiven Seite kennen wir nun eine Reihe von Abstraktionen, wie z.B. Fließbandverarbeitung oder Arbeitgeber/Arbeiter (engl. Master/Slave, oder politisch korrekter, Master/Worker), die sich gut für Parallelisierung eignen.

BD: Für die Forschung ist Parallelität weiterhin ein herrliches Thema. Da kann man sich die Zähne dran ausbeißen. Da wir in Deutschland längst keine Rechnerindustrie mehr haben, leisten wir evtl. nur Amerikanern und Chinesen Hilfe. Ist die systemnahe Programmierung nicht Sache der Hardware-Hersteller? Warum kümmern sich Anwender um die Leistungssteigerung von Systemen, die in 20 Jahren bereits einen Faktor 1000 erreichten? Sehen Sie es anders? Wenn ja, treiben wir da Forschung der Forschung wegen?

WT: Keinesfalls. Aber erst Mal: Man kann nicht Deutschland mit ganz China und ganz Nordamerika vergleichen. Da muss man schon Europa nehmen, und da gibt es durchaus Firmen die Prozessoren entwickeln, z.B. ARM, Infineon, oder Dialog Semiconductor. Richtig ist, dass in der Vergangenheit Parallelrechner die Domäne des wissenschaftlichen Rechnens waren. Das hat sich aber seit etwa 2002 drastisch geändert. Parallelrechner sind inzwischen überall. Im vierten Quartal 2011 verkaufte Apple etwa 35 Millionen Mobilfone, die mit Doppelprozessoren ausgestattet sind. Anfang dieses Jahres führte HTC ein neues Telefon mit fünf(!) ARM-Prozessoren ein. Ernst zu nehmende Parallelrechner sind also schon in der Hosentasche angekommen. Dienstrechner sind bei acht, 16 oder mehr Kernen angelangt. Grafik-Prozessoren bieten Hunderte von Rechenwerken. Wegen der stagnierenden Taktraten müssen nun anspruchsvolle Anwendungen aller Arten parallelisiert werden  ̶  Warten auf die nächste Prozessorgeneration hilft nicht mehr!

Hier zwei Beispiele aus meiner eigenen Erfahrung. Für Agilent in Waldbronn haben wir die Software eines medizinischen Analysegerätes parallelisiert. Bei vier Prozessoren erzielten wir eine etwa 3-fache Beschleunigung. Für den Hersteller kostet ein Vierkerner so viel wie ehemals ein Einzelprozessor. Damit kann Agilent seinen Kunden zum gleichen Preis ein Gerät liefern, das wesentlich schneller arbeitet.

Für SAP haben wir das Laster-Planungsproblem parallelisiert. In diesem Problem hat man eine Reihe von Fabriken und eine Lasterflotte von Hunderten von Fahrzeugen. Die Aufgabe ist nun, die Produkte der Fabriken an Tausende Kunden möglichst schnell und kostengünstig zu liefern. Der Kenner merkt, dass sich da gleich zwei NP-vollständige Probleme verstecken: das Packungsproblem für die Laster (die auch noch unterschiedliche Kapazitäten haben) und des Problem des Handlungsreisenden (vervielfacht). Eine hochoptimierte, sequenzielle Version lässt ein Anwender etwa acht Stunden laufen und begnügt sich mit der bis dahin gefundenen (suboptimalen) Lösung. Wir konnten diese Laufzeit mit 24 Kernen auf 20 Minuten drücken. Zwanzig Minuten Wartezeit gegenüber einem ganzen Arbeitstag  ̶  das ist ein beachtlicher Fortschritt. Damit kann man bei Stornierungen oder Ausfällen sogar jederzeit nachplanen; vorher war das undenkbar.

Im Automobil konnten wir zeigen, dass man aus Stereobildfolgen eine Tiefenschätzung und Fahrbahnverfolgung in Echtzeit ausrechnen kann, ohne spezielle FPGAs einsetzten zu müssen, was einen entscheidenden Kostenvorteil bedeutet. Man sieht, dass Parallelverarbeitung schon heute einen konkreten Nutzen in der Praxis erzielt. In Anspielung auf Ihre Frage denke ich, dass wir durchaus China und Amerika Hilfe bieten können, und zwar in dem wir Parallelsoftware exportieren.

Viele Praktiker beginnen sich für die Parallelwelt zu interessieren. Eine Veranstaltung, die Konferenz Parallel2012 in Karlsruhe, war überfüllt und musste Interessenten abweisen. Auch eine Veranstaltung am FZI zum Thema Multicore war gut besucht. Wenn man die bekannte Technologie-Aufnahme-Kurve zugrunde legt, dann schätze ich, dass wir uns derzeit in der Pionierphase befinden. Bis spätestens 2020 denke ich, dass die frühe Mehrheit die Technik aufgegriffen haben wird. Danach kommen die späte Mehrheit und schließlich die Nachzügler. Heute schon bilden wir am KIT alle Softwaretechnik-Studenten in Parallelität aus, beginnend im zweiten Semester. Unsere Absolventen werden gefragter sein als je zuvor!

BD: Haben Sie vielen Dank, Herr Tichy, für dieses interessante Interview. Besonders gefreut hat es mich, sogar neueste Forschungsergebnisse kennen zu lernen, über die in diesem Monat auf der ICSE berichtet wurde.