Zu den wesentlichen Verbesserungen der frei erhältlichen Linux-Compiler-Sammlung gehören unter anderem folgende Dinge:

>> Dank des AVX-Supports ist GCC 4.6 ab sofort für alle Sandy-Bridge-nahen Software-Projekte interessant. Damit werden mithilfe von -march=corei7-avx and -mtune=corei7-avx die aktuellen Core i3-, Core i5- und Core i7-Prozessoren auf Sandy-Bridge-Basis besser unterstützt.

Das bedeutet vor allem den Support der neuen 256 Bit breiten Register und der zugehörigen, register-nahen Befehlssätze. Daneben konnte aber auch das Zusammenspiel mit ARM-CPUs (Cortex-M4 und Cortex-A15) verbessert werden. Außerdem lassen sich mit GCC 4.6 Floating-Point-Operationen default-mäßig bei der Konfiguration einschalten. Dies geschieht mit dem Schalter –with-fpmath=avx.

>> Die Kompilierungszeiten konnten verkürzt werden und notwendiger Speicher wird effizienter genutzt. Die Kompilierzeiten sind vor allem bei Codeabschnitten mit umfangreichen Funktionen verbessert worden, die nicht vollständig in den Cache passen. Bei Tests auf 64-Bit-x86-Maschinen wurde eine Geschwindigkeitszunahme von 10 Prozent gemessen.

>> Pragma-basierte Fehlerwarnungen können jetzt mittels #pragma GCC diagnostic ein- und ausgeschaltet werden. Das ist beispielsweise für OpenMP-Programmabschnitte interessant.

>> Interessant ist auch die Verbesserung des – zumindest experimentellen – Supports des künftigen C++0x-Standards. Es lassen sich constexpr und nullptr inkludieren.

>> Der Support von Fortran 2003 und 2008 wurde verlängert.

GCC 4.6 wird wohl Mitte Mai in Fedora 15 Einzug halten, allerdings nicht der Standard-Compiler  von Ubuntu 11.04 sein, das Ende April erwartet wird. Sämtliche Verbesserungen und Ergänzungen findet man auf der zugehörigen Webseite.

Hierzu gibt es auch ein Video:

ISAT

Der zweite Tool-Tipp wendet sich an Linux-Entwickler unter C/C++: Kennen Sie schon das kostenlose ISAT? ISAT steht für Intel Software Autotuning Tool und wurde im Dezember von Intel veröffentlicht. Es handelt sich dabei um ein Tuning-Werkzeug, das automatisch nach optimalen Werten für Programm- und Code-Parameter sucht, um die Anwendung zu beschleunigen. Gute Dienste leistet es etwa bei Cache-Blocking-Faktoren in Matrix-Berechnungen, bei der Task-Granularität in Intel-TBB und OpenMP-Abschnitten. Die Optimierungen im Code werden dann automatisch anhand der vorherigen Suchergebnisse vorgenommen. Zudem liefert ISAT auch eine grafische Analyse der Performance in einem 3D-Modell, die dem Entwickler ein besseres Verständnis der empfohlenen Tuning-Prozesse ermöglicht.

ISAT veranschaulicht die Performance-Analyse im 3D-Modell

Das Tool funktioniert unter 32- und 64-Bit Linux; Python (Version 2.4 und 2.9) bei allen gängigen C/C++ Compilern.

Clojure

Und noch einen interessante Fundstelle. Der moderne Lisp-Dialekt Clojure hat sich vor allem in der so genannten nebenläufigen Programmierung einen Namen gemacht, weil Closure in der Java Virtual Machine läuft und mit Java Runtime eng verknüpft ist.

Jetzt beweist Clojure seine dezidierten Möglichkeiten auch im Bereich Multicore, vor allem beim Multithreading. Einen gut verständlichen Grundlagenbeitrag zu Clojure und Multicore habe ich bei Heise gefunden.

Das absolute Highlight des GUI-basierten Linux-Debuggers von Intel ist die Möglichkeit, einzelne Breakpoints zu setzen, zu speichern und bei Bedarf das so markierte Projekt wieder aufzurufen. Das ist vor allem dann hilfreich, wenn sich die Umgebungsentwicklung mal verabschieden sollte oder man andere Dinge zwischendurch zu tun hat, bevor man sich wieder dem Debuggen zuwendet. Ein Breakpoint wird dank der grafischen Bedieneroberfläche per doppeltem Mausklick erzeugt – und genauso schnell wieder entfernt. Das macht das Testen von C/C++ und Fortran-Projekten wirklich sehr komfortabel.

Aber auch das Testen parallel programmierter Projekte unter Linux geschieht mit dem Debugger von Intel recht überzeugend. So kann man in Echtzeit eine komplette Anwendung (oder Teile davon) auf mögliche Data Races hin untersuchen. Genau genommen identifiziert der Debugger Szenarien, in denen es zu gemeinsamen Datenzugriffen kommen kann, was vor allem das konkurrierende Speichern zweier Threads betrifft. Der Programmierer oder Entwickler muss dann selbst entscheiden, ob dieser parallele Schreibzugriff gewollt ist oder im schlimmsten Fall einen Absturz der Anwendung zur Folge haben kann.

Das Aufspüren von potenziellen Data Races kann übrigens ohne Breakpoint erfolgen. In diesem Fall muss man im Debugger die Option “Stop on Event” einstellen, und schon hält das Programm genau an der Stelle an, wo der “Crash” erfolgt. Zur schnellen Fehlerfindung wird die verursachende Stelle im Quellcode angezeigt. Dies können einzelne Adressen sein, aber auch vollständige Funktionen im Sourcecode.

Neben der klassischen Programmierung unterstützt der Linux-Debugger von Intel auch OpenMP, was immer öfter bei der parallelen Programmierung eingesetzt wird. In diesem Fall geht es vor allem um ein Überwachen des Threadpools: Sind sämtliche Threads, die sich dort befinden, thread-sicher und wenn nicht, an welchen Stellen kann es zu Data Races kommen?

Ach ja: Ein wichtiger Tipp beim parallelen Programmieren lautet: Denke von Anfang an parallel, entwerfe parallel, programmiere aber zuerst seriell. Dies stellt sicher, dass der sequentielle Quellcode fehlerfrei läuft und sich anschließend die parallelen Konstrukte einbauen lassen – beispielsweise mithilfe von OpenMP. In diesem Fall müssen für das serielle Debuggen nicht sämtliche OpenMP-Pragmas entfernt oder deaktiviert werden. Der Debugger führt nämlich die parallelen Konstrukte auf einem einzigen Thread aus, so als ob es sich um eine Single-Core-Maschine handeln würde.

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.

Wie der dritte Punkt genauer aussieht und welche Tools für welche Plattform im Donaustädtchen entstehen, erfahrt ihr dann auf diesem Sender, und zwar schon morgen. Nur mal schon vorab: Es geht um einen GUI-basierten Debugger für die Linux-Gemeinde, mit dem sich sowohl seriell als auch parallel programmierte Anwendungen auf mögliche Fehler hin überprüfen lassen. Stichworte hierbei sind Data Races und Data Sharing Detection.

PS: Es gibt natürlich einen gewichtigen Grund, warum Intel Ulm so sehr auf Debugger spezialisiert ist: Anfang dieses Jahrhunderts gingen nämlich Teile des Ulmer Unternehmens CAD-UL in den Besitz von Intel über. Die CAD-UL-Spezialisten hatten sich jahrelang mit der Entwicklung von XScale-basierten Debuggern beschäftigt, die vor allem im Bereich Embedded Systeme zum Einsatz kamen.