Ich baue Erkenntnisse, keine Features
Ein Gespräch mit Martin Lonkwitz, R&D Software Engineer im Team SAP on POWER bei IBM Deutschland, über Compiler, Kernel-Performance – und darüber, was Forschung & Entwicklung von klassischer Softwareentwicklung unterscheidet.
This conversation is also available in English.
Der SAP-Kernel ist das Herzstück jedes SAP-Systems: in C/C++ geschriebene Systemsoftware, die ABAP-Programme ausführt, Prozesse und Speicher verwaltet und mit der Datenbank spricht. Auf IBM-POWER-Systemen unter AIX und Linux läuft dieser Kernel in vielen der größten Rechenzentren der Welt. Damit er dort schnell und stabil läuft, arbeitet bei IBM Deutschland in Böblingen ein Team exklusiv für SAP. Martin Lonkwitz gehört seit Oktober 2020 dazu. Wir haben mit ihm gesprochen.
webartikel.info: Herr Lonkwitz, Sie beschreiben Ihre Arbeit als „Research & Development“. Für viele klingt das nach Labor und weißem Kittel. Was machen Sie tatsächlich den ganzen Tag?
Martin Lonkwitz: Kein Kittel, aber tatsächlich sehr viel Messen. Unser Team stellt sicher, dass der SAP-Kernel auf AIX und Linux on POWER läuft – und zwar mit der Performance, die die Plattform hergibt. Dazu gehört der Support für den IBM XL C/C++ Compiler, mit dem SAP den Kernel baut, die Mitverantwortung für die Kernel-Releases auf AIX und für die Gesamtperformance aller AIX-Kernel-Versionen.
Konkret heißt das: Wenn ein Kunde irgendwo auf der Welt meldet, dass sein SAP-System nach einem Kernel-Wechsel oder einer Hardware-Migration langsamer geworden ist, landet das bei uns. Dann messen wir zunächst, wo die Zeit tatsächlich verloren geht – in welchen Funktionen, in welchen Schleifen. Danach lesen wir den betroffenen Quellcode, bei Bedarf bis hinunter zu den Maschinenbefehlen, die der Compiler daraus erzeugt hat. Und wir sprechen mit den Leuten, die die Werkzeuge bauen: mit der Compiler-Entwicklung in Toronto und mit den AIX-Betriebssystementwicklern. Wir schlagen dort Fixes und Verbesserungen vor – und nicht selten entstehen aus unserer Arbeit offizielle Fixes für den IBM Compiler und für AIX selbst. Am Ende steht eine Ursache, die wir belegen können.
webartikel.info: Das klingt zunächst wie klassische Entwicklung mit Fehlersuche.
Lonkwitz: Der Unterschied liegt in der Frage, die man stellt. Ein Entwickler im Produktteam fragt: „Wie setze ich das Feature um, das im Backlog steht?“ Ich frage: „Was ist auf dieser Plattform überhaupt möglich – und lohnt es sich?“ Ich baue selten Features. Ich baue Erkenntnisse, Prototypen und Werkzeuge, die irgendwann in ein Produkt einfließen – oder eben nicht, wenn sich herausstellt, dass die Idee nichts taugt. Auch ein sauber belegtes „Nein“ ist in R&D ein Ergebnis.
webartikel.info: Nehmen wir das der Reihe nach. Ein Kernthema von R&D ist die Technologie-Evaluierung. Wie sieht das bei Ihnen aus?
Lonkwitz: Bei uns dreht sich sehr viel um den Compiler – also das Programm, das aus dem Quellcode der Entwickler den Maschinencode macht, den der Prozessor ausführt. IBM hat den XL C/C++ Compiler mit Version 17 auf eine LLVM/clang-Basis gestellt, ein Generationswechsel gegenüber der Version 16. Jede neue Version bringt neue Optimierungsfunktionen, neue Codegen-Optionen, Link Time Optimization. Meine Aufgabe ist, systematisch zu prüfen: Was davon bringt dem SAP-Kernel messbar etwas? Was bricht? Was verhält sich anders als dokumentiert? Ich baue den Kernel mit den neuen Optionen, lasse definierte Lastszenarien laufen, vergleiche die Messungen – und schreibe auf, was ich gefunden habe.
Dabei geht es nicht nur um das Neueste. Wir bauen bis hinunter auf AIX 6.1 mit dem V11-Compiler, weil damit bis heute Software entsteht, die SAP ausliefert – zum Beispiel der SAP Host Agent. Für dessen AIX-Code trage ich persönlich die Hauptverantwortung: Ich implementiere dort Neues in Sachen SAP Monitoring und behebe Fehler. R&D heißt also nicht, alte Plattformen hinter sich zu lassen. Es heißt, die ganze Spannbreite im Griff zu haben.
Das Gleiche gilt für Programmiersprachen. SAP setzt unter AIX auch Rust für den SAP-Kernel ein, und wir stellen den Rust-Support gegenüber SAP sicher – im gleichen Maße wie für die C/C++-Compiler-Versionen. Dazu habe ich Rust im systemnahen SAP/POWER-Umfeld evaluiert, indem ich Build-, Test- und Analysewerkzeuge prototypisch in Rust entwickelt habe. Nicht, weil Rust gerade in Mode ist, sondern um eine belastbare Aussage zu haben, wo es auf dieser Plattform trägt und wo nicht.
webartikel.info: Und die Hardware selbst?
Lonkwitz: Auch. Ein Prozessorwechsel – etwa von POWER9 auf POWER10 – ist für einen Kernel, der auf Performance getrimmt ist, nie ein Nullereignis. Cache-Verhalten, Pipeline, die Befehlsauswahl des Compilers: Alles kann kippen. Das muss man vorher wissen, nicht hinterher, wenn der Kunde anruft.
webartikel.info: Zweiter Punkt: Prototyping und Proofs of Concept. Die gängige Beschreibung lautet, der Code müsse dabei nicht perfekt sein, sondern die Idee demonstrieren. Sehen Sie das auch so?
Lonkwitz: Halb. Ein PoC muss nicht produktionsreif sein – keine Fehlerbehandlung für jeden Randfall, keine Dokumentation für Endanwender, keine Internationalisierung. Und das ist auch richtig so, denn ein großer Teil unserer PoCs sind Antworten auf Anforderungen: SAP trägt Fragen an uns heran, und wir müssen Lösungen auf der AIX-Plattform anbieten. Ein Beispiel ist Virtualisierung und Orchestrierung – Kubernetes in Verbindung mit versionierten WPARs, den Container-ähnlichen Partitionen von AIX. Eine von vielen Anfragen. Dazu kommen IBM-interne Themen, etwa KI-Workloads auf POWER oder Automatisierung mit Ansible. In all diesen Fällen geht es zuerst um die Machbarkeit, nicht um ein fertiges Produkt.
Aber: Der PoC muss korrekt sein und reproduzierbar. Ein Prototyp, der ein Ergebnis zeigt, das niemand nachstellen kann, ist keine Machbarkeitsstudie, sondern eine Anekdote. Bei uns ist ein PoC oft ein Messaufbau: eine Kernel-Variante, ein Lastprofil, eine Auswertung. Wenn ich sage „PGO bringt bei diesem Workload x Prozent“, dann liegen die Profildaten, die Build-Parameter und die Rohmessungen daneben. Sonst glaubt es mir zu Recht niemand – weder SAP noch die Compiler-Leute in Toronto.
webartikel.info: Sie haben Profile Guided Optimization erwähnt. Erklären Sie das kurz für Nicht-Compilerbauer?
Lonkwitz: Ein Compiler muss beim Übersetzen raten, welche Codepfade häufig laufen und welche selten. Bei PGO nimmt man ihm das Raten ab: Man baut den Kernel einmal in einer Messvariante, lässt einen repräsentativen Workload laufen und sammelt dabei Profildaten – welche Funktionen, welche Verzweigungen, wie oft. Dann übersetzt man ein zweites Mal mit diesem Wissen. Der Compiler legt häufig genutzten Code zusammen, optimiert die richtigen Schleifen und spart Funktionsaufrufe dort, wo es sich lohnt.
Die Kunst liegt nicht im Knopfdruck, sondern im Messszenario. Wenn das Trainingsprofil den echten Kundenbetrieb nicht abbildet, optimiert man am Ziel vorbei. Deshalb stecke ich viel Zeit in die Frage, was ein repräsentativer Workload für einen ABAP-Kernel überhaupt ist – und wie man das Ergebnis so misst, dass es einer Nachprüfung standhält.
webartikel.info: Dritter Punkt: Grundlagenforschung – Algorithmen, für die es noch keine Standardlösung gibt. Passiert das in Ihrem Umfeld?
Lonkwitz: In einem bescheideneren Sinn als in der KI-Forschung, ja. Es gibt keine Standardlösung für die Frage, wie man einen über Jahrzehnte gewachsenen Kernel auf einer bestimmten CPU-Generation optimal übersetzt. Es gibt keine fertige Methode, um eine Regression, die nur bei einem Kunden unter einer bestimmten Last auftritt, auf eine einzelne Compiler-Entscheidung zurückzuführen. Das erarbeitet man sich: mit Messwerkzeugen, mit eigenen Analyseprogrammen, manchmal mit einem Blick in den erzeugten Maschinencode. Grundlagen heißt für mich: verstehen, was unter der Oberfläche tatsächlich passiert.
Das soll nicht heißen, dass Erfahrung dabei keine Rolle spielt – im Gegenteil. Wissen kann man delegieren, Verstehen nicht. Und zum Verstehen gehört eine gute Intuition, die aus Erfahrung wächst, plus eine ordentliche Prise Kreativität. Das ist übrigens genau die Leistung, die über dem liegt, was eine KI heute beisteuern kann: Sie hat das Wissen, aber die Intuition, wo man suchen muss, kommt vom Menschen, der diese Systeme seit Jahrzehnten unter Last gesehen hat. Wer in wissenschaftlicher Arbeit nur trockenes Zahlenwerk sieht, nimmt sich selbst viel Potenzial weg.
webartikel.info: Vierter Punkt: Patente und Whitepaper. Schreiben Sie wissenschaftliche Arbeiten?
Lonkwitz: Keine Konferenzpapiere im akademischen Sinn. Aber ich schreibe sehr viel – Root-Cause-Analysen, Defect Reports, Evaluierungsberichte. Das ist das Äquivalent. Ein Defect Report an eine Compiler-Entwicklung muss aufgebaut sein wie eine kleine wissenschaftliche Arbeit: Umgebung, Symptom, Belege, Defektaussage, Reproduktion, Workarounds, geforderte Maßnahme, angehängte Evidenz. Meine Regel dabei: Überschriften sind Versprechen. Wenn über einem Abschnitt „Root Cause“ steht, steht darunter die Ursache – belegt – und nicht eine Vermutung. Und keine Behauptung ohne Verweis auf Daten. Das klingt streng, spart aber allen Beteiligten Wochen.
Fachvorträge habe ich früher gehalten, etwa 2009 auf dem Wiener Technikkongress über Performance in Fibre-Channel-Netzwerken. Heute findet Wissensweitergabe bei mir eher in der Einarbeitung neuer Kolleginnen und Kollegen statt. Als ich in diesem Team anfing, war das noch die altgediente Garde – Menschen, die bei IBM groß geworden sind und mehrere Jahrzehnte in diesem Bereich gearbeitet haben. Man konnte enorm viel lernen, und ich denke, ich habe diese ersten Jahre gut genutzt. Heute versuche ich, das weiterzugeben.
webartikel.info: Fünfter Punkt: Wissenstransfer. Was passiert mit Ihren Ergebnissen?
Lonkwitz: Das ist der eigentliche Zweck. R&D, das nicht in ein Produkt mündet, ist Hobby. Bei uns hat der Transfer zwei Richtungen. Nach oben zu Compiler und Betriebssystem: Wenn wir zeigen, dass eine Optimierung falschen oder langsamen Code erzeugt oder AIX sich an einer Stelle nicht so verhält, wie es sollte, geht das als Defect an die Entwicklung und wird dort behoben – davon profitiert dann jeder XL-C/C++- und AIX-Anwender, nicht nur SAP. Und in Richtung Produkt: Wenn eine Compiler-Option oder ein PGO-Setup messbar etwas bringt, geht es mit einer Empfehlung an SAP, es in den offiziellen Kernel-Build zu übernehmen. Dort sitzen die Kollegen, die daraus einen stabilen Release machen, mit allem, was dazugehört.
Meine Arbeit endet mit einem belegten Ergebnis und einer Übergabe. Das muss man aushalten können: Man baut Dinge, die andere fertigstellen.
webartikel.info: Sie haben aber auch klassische Entwicklungsverantwortung, richtig?
Lonkwitz: Ja, das ist bei uns kein Entweder-oder. Ich verantworte einige Kernel-Komponenten direkt: das SAP-Monitoring saposmon, den CIM-Code, den AIX-Teil des SAP Host Agent und das Google Robot Testframework. saposmon ist das Stück Kernel, das dem SAP-System sagt, wie es dem Betriebssystem geht – CPU, Speicher, Paging, Auslastung. Auf AIX mit LPARs, Micro-Partitioning und geteilten Prozessoren ist „Wie viel CPU habe ich gerade?“ eine überraschend tiefe Frage. Liefert saposmon dort falsche Werte, treffen Administratoren falsche Entscheidungen. Das ist Betriebsverantwortung im klassischen Sinn: Bugs beheben, Releases pflegen, Tests grün halten. Dazu kommen AIX-spezifische Lösungen, etwa Ansible-basierte Automation und RBAC-Konfigurationen.
Zusätzlich arbeite ich unserem Kollegen im Team zu, der direkt die SAP-Kundentickets rund um AIX und Linux on POWER bearbeitet. Wenn dort ein Fall tiefer geht als ein Konfigurationsproblem, kommt er zu mir – und umgekehrt sehe ich über diese Tickets, was bei den Kunden draußen tatsächlich passiert.
Ich finde die Mischung gesund. Wer nur forscht, verliert das Gefühl dafür, was im Betrieb wirklich wehtut. Wer nur betreibt, hört auf, Fragen zu stellen.
webartikel.info: Wie sind Sie in diese Nische gekommen? Ihr Werdegang ist ja alles andere als geradlinig.
Lonkwitz: Er wirkt nur ungeradlinig, wenn man auf Jobtitel schaut. Angefangen habe ich bei der Bundeswehr als IT-Spezialist – UNIX-Netzwerke, Militärsimulation, 1997 im Auslandseinsatz. Danach einige Jahre Unix-Engineering für Banken und Industrie, in Frankfurt, Neuss und Tokio, auf großen SUN-Systemen. Ab 2002 dann Lufthansa Systems: erst Linux und z/VM auf dem IBM-Mainframe, als das noch neu war, dann zehn Jahre SAN- und Storage-Betrieb für die Lufthansa und ihre Kunden, mit fast viertausend Fibre-Channel-Ports. Dort habe ich meine Monitoring- und Automationswerkzeuge in C und Perl selbst geschrieben, weil es nichts Passendes gab. Später Produktentwicklung auf dem Mainframe: zGuard, eine Kapazitäts- und Ressourcensteuerung in z/Assembler und C++, die bei Versicherungen, Banken und in der Automobilindustrie lief.
Der rote Faden ist immer derselbe: Systemsoftware nah an der Hardware, in C und C++, für Infrastruktur, die nicht ausfallen darf. Der SAP-Kernel auf POWER ist davon nur die konsequenteste Form.
webartikel.info: Was sollte jemand mitbringen, der in Richtung R&D im Systemumfeld will?
Lonkwitz: Drei Dinge. Erstens Geduld mit Messungen – die meiste Zeit geht nicht ins Programmieren, sondern in den Aufbau sauberer Vergleiche. Zweitens die Bereitschaft, unter die Abstraktion zu gehen: Compiler-Ausgaben lesen, Betriebssystemverhalten verstehen, Hardware-Dokumentation lesen. Und drittens Ehrlichkeit gegenüber dem eigenen Ergebnis. Der größte Fehler in R&D ist, das Resultat zu berichten, das man sich gewünscht hat. Eine Idee, die nach zwei Wochen sauber widerlegt ist, ist ein guter Ausgang. Eine Idee, die man drei Jahre lang schönredet, ist ein teurer.
webartikel.info: Herr Lonkwitz, vielen Dank für das Gespräch.
Martin Lonkwitz arbeitet seit 2020 als R&D Software Engineer im Team SAP on POWER bei IBM Deutschland in Böblingen. Schwerpunkte: SAP-Kernel-Entwicklung auf AIX und Linux on POWER, IBM XL C/C++ Compiler und Rust-Support, Profile Guided Optimization, SAP Monitoring (saposmon, CIM, SAP Host Agent).