Lesetipp: Elektroniknet.de über die “Softwarefirma Intel”

Ok, die jährlich stattfindende Intel-Software-Konferenz iSTEP ist schon wieder eine ganze Weile her, aber nichtsdestotrotz hat es sich Kollege Joachim Kroll von elektroniknet.de nicht nehmen lassen, die Veranstaltung und seine Lehren und Erkenntnisse daraus auf drei Seiten zusammen zu fassen. Es ist ein sehr gelungener Beitrag geworden, dessen Kernaussagen ich ein wenig kommentieren möchte.

Einer der großen Meilensteine war dabei die Übernahme des Embedded-Softwareherstellers Wind River durch Intel.

Absolut richtig. Allerdings ist die Schlussfolgerung des Kollegen Kroll nicht ganz zutreffend:

Einzig und allein die Ankurbelung des Prozessorgeschäfts ist die Triebkraft, die die  Aktivitäten Intels antreibt.

Das stimmt im Falle des Wind-River-Deals so nicht ganz, wenn man sich die derzeitige Embedded-Strategie Intels ansieht. Denn mit der Akquisition des Embedded-Spezialisten hat man nicht nur in Sachen Multicore und Parallelisierung viel Expertise eingekauft, sondern auch eine Menge Know-how im Bereich Mobile Linux und Mobile Gadgets ins Haus geholt. Und das kann Intel hinsichtlich seiner Moorestown-MeeGo-Smartphone-Aktivitäten ganz gut gebrauchen.

Vielmehr wird Intel auch mit der Software »inside« bleiben und Entwicklungswerkzeuge, Bibliotheken und Middleware für Betriebssystemhersteller und Anwendungsentwickler anbieten.

Diesen Passus finde ich ein wenig verwirrend. Klingt so, als ob Intel gerade dabei ist, zur Beschleunigung bestehender Software-Titel Tools auf den Markt zu bringen, die Software-Entwickler dabei unterstützen sollen, ihre Apps zu parallelisieren. Dass das so nicht stimmt, weiß der Autor allerdings schon, nur an dieser Stelle könnte der Eindruck entstehen, als ob Intel mit Software-Tools bis dato nix am Hut hat.

Echte Parallelität und »paralleles Denken« bei der Konzeption von Anwendungen stehen hingegen noch ganz am Anfang.

Hm, wie soll man diese Aussage bewerten? Sicher, viele Entwickler verlassen sich nach wie vor darauf, dass ihre Anwendungen von schneller werdenen Prozessoren und Architekturen beschleunigt werden, was natürlich nicht stimmt. Allerdings sind vor allem die größeren Entwicklerschmieden schon längst auf den Parallel-Zug aufgesprungen. Da kann man einfach mal bei DivX, Nik Software, Crysis, Exasol, Maxon, Nero und all den anderen nachfragen.

Eine fest codierte Verteilung (z.B. mit pthreads oder Windows threads) ist aber wenig zukunftssicher.

Absolut richtig! Der daraus resultierende Rat, den Software-Spezialisten wie Mario Deilmann oder andere geben, lautet: “Denkt in Tasks, nicht in Threads!”. Denn das thread-basierte Programmieren läuft bei vielen Anwendungen auf eine schlecht skalierende Programmausführung hinaus und ist zudem sehr fehleranfällig. Viel besser und effizienter ist es hingegen, seine Anwendung von Anfang an so zu strukturieren, dass eine Abstraktion des Quellcodes möglich ist. Und mit den richtigen Frameworks wie Intel TBB oder .NET 4 von Microsoft muss sich der Programmierer um das Verteilen der Tasks auf die zugehörigen Threads gar nicht mehr kümmern.

Allerdings ist eine neue Programmiersprache für die Parallelverarbeitung nicht in Sicht [...]

Tja, eine gewagte Aussage. Denn mit funktionalen Programmiersprachen wie F#, die mit dem Erscheinen von Visual Studio 2010 Bestandteil der Microsoft-Entwicklungsumgebung ist, lässt sich die Parallelprogrammierung durchaus vereinfachen. Inwieweit sich F# und andere funktionale Sprachen durchsetzen werden, ist natürlich fraglich.

Viele Entwickler suchen allerdings nach weniger anspruchsvollen Erweiterungen [wie OpenMP und die MPI-Bibliothek], mit denen sich in C/C++ geschriebene Desktop- und Embedded-Anwendungen parallelisieren lassen [wie mit Intel TBB].

Es stimmt natürlich, dass OpenMP nicht so mächtig ist wie die C++-Bibliothek Intel TBB. Aber OpenMP als anspruchsvolle Erweiterung zu bezeichnen, ist ein bisschen übertrieben. Gerade mit OpenMP lassen sich mit wenigen Handgriffen vor allem Schleifen parallelisieren. Hierzu bedient man sich lediglich einiger, weniger Pragmas, die in den bestehenden Quellcode eingefügt werden müssen. Der Rest geschieht dann quasi von selbst.

Keine ähnlichen Artikel.