Intel Ulm und die Linux-Debugger-Tools
Vorige Woche war ich auf Reisen. Die Destination meiner Unternehmung: Die württembergische Außenstelle der Firma Intel, die sich in Ulm befindet. Um es kurz zu machen: Sehr beeindruckend, was ich dort alles gesehen und gelernt habe. Zunächst einmal muss ich aber ein paar Dinge klarstellen, über die ich im Vorfeld berichtet hatte:
1. Der Windows-C++-Compiler für Windows CE wird in Ulm nicht mehr entwickelt und spielt seit dem Erscheinen des Atom-Prozessors auch keine große Rolle mehr. Denn selbst Embedded-Systeme setzen immer öfter auf die Netbook-CPU und ermöglichen damit den Einsatz standardisierter Betriebssysteme wie Linux und Windows mit den zugehörigen Entwicklertools.
2. Die Software-Werkzeuge, um die es bei Intel in Ulm vor allem geht, helfen Programmierern und Entwicklern, ihre Anwendungen fehlerfrei unters Volk zu bringen. Hierfür konzentrieren sich die Ulmer Kollegen auf die Debugger-Tools, die sowohl unter Windows als auch unter Linux zum Einsatz kommen. Interessant an meinem Besuch war unter anderem die Erkenntnis, dass die Parallel Debugger Extension, die sowohl im Parallel Studio als auch in der aktuellen Version des Intel-C++-Compilers stecken, “made in Ulm” sind. Na ja, auf jeden Fall zu einem großen Teil.
3. Das Intel-Büro in Ulm ist entgegen meinen ersten Erwartungen alles andere als beschaulich. Es befindet sich in einem architektonisch höchst interessanten Gebäude, das sogar über einen eigenen Teich verfügt. Auf zwei Stockwerken arbeiten 30 bis 40 Leute vorwiegend an den neuesten Debugger-Tools – auf dass künftige Software möglichst fehlerfrei läuft. Aber auch diverse Entwicklertools für den Atom-Prozessor werden in Ulm konzipiert und entwickelt.
ISC’09: Intel Parallel Inspector im Detail
Nach Heinz Basts sehr interessantem Beitrag über Parallel Composer ist Levent Akyil von Intel dran, um zunächst über Parallel Inspector zu reden, später dann über Parallel Amplifier.
Parallel Inspector ist, einfach gesagt, eine Kombination aus Threading- und Speicher-Checktool, und das sogar “proaktiv”. Proaktiv bedeutet in diesem Zusammenhang eine Fehlersuche zur Laufzeit der Anwendung. Darüber hinaus integriert sich der Inspector in Visual Studio und macht damit die Bedienung ziemlich einfach. Der Programmierer muss sich nur für eine der beiden Optionen entscheiden: Finde Threadfehler oder Speicherfehler.
Speicherfehler: Hier geht es um so unschöne Dinge wie Memory Leaks, Speicherüberläufe und Zeigerprobleme. Schön daran ist die Möglichkeit, irrelevante gefundene Probleme auszublenden. Dies macht das Aufspüren der wichtigen Fehler einfacher.
Threading-Fehler: Stichworte sind Deadlocks, Data Races und andere Synchronisationsprobleme, und das zur Laufzeit der Anwendung. Auch hier lassen sich unwichtige Probleme direkt ausblenden.
Parallel-Studio-Serie (3): mehr Infos zum Parallel Inspector
In den ersten beiden Teilen der Serie “Mit Parallel Studio Anwendungen multithreaden” ging es um die drei aktuellen Komponenten des Entwicklungstools: Parallel Composer, Parallel Inspector und Parallel Amplifier. Heute werde ich mir den Inspector noch mal ein wenig genauer ansehen.
Im Parallel Inspector steckt ein erprobtes Tool, und zwar der Thread Checker. Daher ist der Inspector primär für das Auffinden von Fehlern zuständig, die sich in Multithread-Code eingeschlichen haben. Um dies alles erledigen zu können, beherrscht das Debug-Tool eine Menge Dinge:
- Es entdeckt Speicherprobleme und -fehler, findet also fehlerhafte Speicherzuweisungen und korrupte Speicherdaten, die möglicherweise zu schwerwiegenden Fehlern während der Laufzeit führen würden.
- Die bekannten Threading-Fehler wie Deadlocks und Race Conditions spürt der Inspector zuverlässig auf. Gerade diese nicht-deterministischen Laufzeitprobleme können mit herkömmlichen Debug-Tools kaum oder nur mit größtem Aufwand gefunden werden.
- Der gesamte Multithread-Code wird nach Fehlern durchforstet. Vor allem die zur Laufzeit auftretenden Probleme erkennt der Inspector und führt den Programmierer direkt zu der betroffenenen Stelle. Dabei wird auch der zugehörige Call Stack angezeigt und die betroffenen Speicherstellen. Warnhinweise und Fehlermarkierungen helfen dabei, die aufgetretenen Probleme besser und schneller zu verstehen.
- Das alles findet dank der Integration in Visual Studio unter einer einheitlichen und vertrauten Entwicklerumgebung statt. Damit lassen sich Fehler schneller erkennen, verifizieren und eliminieren. Das Gute daran: Es muss nicht jedesmal ein “Rebuild” des Quellcodes durchgeführt werden.
