Start frei für die dotnet Cologne 2011 – eine der kleineren, aber durchaus wichtigen Entwicklerkonferenzen für den .NET-Bereich.

Positiv fällt auf, dass die Location wirklich schön ist. Freundliche Konferenzräume, heller, wenn auch sehr kleiner Ausstellungsbereich. Negativ bleibt festzuhalten, dass es im Ausstellungs-und Pausenbereich absolut keine Stühle gibt (ich sitze auf einer Kiste). Liebe Veranstalter, das könnt ihr beim nächsten Mal sicher besser machen.

In diesem Jahr nehmen die Themen Silverlight und Windows Phone 7 sehr viel Raum ein. Unser Highlight ist aber selbstverständlich der Vortrag zum Thema „Parallelisierung und Skalierbarkeit in nativer C/C++ Softwareentwicklung – leichter als je zuvor“ von Hubert Haberstock.

Ich werde live davon bloggen, hatte aber schon vorher die Möglichkeit, Hubert ein paar Fragen zu stellen.

Hubert Haberstock

Wen adressiert Intel Parallel Studio XE? Welche Programmierer profitieren am meisten davon?
Parallel Studio XE ist ein Visual Studio-Plug-In, das Parallelisierung von nativem Code unter C und C++ ermöglicht. Es bietet diverse Multithreading-Methoden und Tools, die Entwicklern helfen, auf der Hardware-Ebene schnellere und fehlerbereinigte Apps zu programmieren. Auch Fortran wird von Parallel Studio unterstützt.

Von welchen Funktionen profitieren Anwender?
Vor allem natürlich von der Vektorisierung. Programmierer können ab sofort Multimedia-Register-OPs verwenden wie AVX, und so mit einfachen Methoden parallelen Code produzieren. Zudem profitieren Entwickler von der Möglichkeit, ohne Managed Code direkt die Hardware zu steuern.

Stichwort Debugging: Was können Programmierer von den Debugger-Erweiterungen erwarten?
Es gibt eine Parallel Debugging Extension, die selbstverständlich nicht den Microsoft-Compiler ersetzt, unter Cilk, OpenMP und TBB (Intel Threading Building Blocks) aber sehr gute Dienste leistet.

Data Races und Bootlenecks gehören zu den häufigsten Schwachstellen in parallelem Code. Was leistet hier Parallel Studio XE, um Fehler dieser Art zu vermeiden?
Parallel Studio XE bietet leistungsstarke Performance- und Analyse-Tools, die dazu beitragen, typische Fehlerquellen im Code offenzulegen, selbstverständlich zunächst im seriellen Code. Allen voran der VTune Amplifier, der Bottlenecks aufspürt. Ein weiteres wichtiges Tool ist der Inspector, mit dem Entwickler sehr schnell Data Races und Deadlocks erkennen können. Insofern arbeitet der Inspector als Debugger. Als sehr praktisch erweist sich die Option, den kompletten Code zunächst mit dem Statitc Security Analyzer einer sehr schnellen, statischen Analyse zu unterziehen und im Anschluss Codebestandteile in Echtzeit zu prüfen. Der Programmierer weiß dann, wie sich der Code tatsächlich innerhalb der App verhalten wird.

Intel Array Building Blocks steht mit der Beta-Version in den Startlöchern. Kannst du unseren Lesern das Konzept hinter den Intel Array Building Blocks kurz erklären?
Intel Array Building Blocks sind Spracherweiterungen für parallele Patterns, die eine Parallelisierung schon auf Code-Ebene ermöglichen. So werden unter Intel Array Buildung Blocks (ArBB) „for“-Loops durch Vektoranweisungen ersetzt. Ein zweiter Aspekt: Die dynamische Laufzeitumgebung passt den Code auf die Target-Architektur an, also exakt auf die Hardware, für die der Code konzipiert wurde.

Letzte Frage: Mit welchen Tools zur Parallelprogrammierung sollten sich Entwickler unbedingt beschäftigen, um effizienter zu arbeiten?
Keine Frage, das ist Parallel Studio – ein komplettes Öko-System aus optimierenden Compilern, Libraries, Tuning-Tools und Analyzer-Werkzeugen für native Code-Umgebungen. Nicht nur, aber auch gerade für Einsteiger ein unverzichtbares Tool-Set.

Heute nachmittag geht es weiter. Dann werde ich selbstverständlich auch von Huberts Präsentation berichten.

Was war deine größte Herausforderung beim Umstieg auf die Parallelprogrammierung?

Was ist ein guter Tipp für angehende Parallelprogrammierer?

Was bringen Sandy Bridge und AVX für parallel ablaufende Anwendungen?

Der zweite Teil hingegen befasst sich mit Fragen wie:

Welche Programmiermodelle werden sich durchsetzen?

Laut Asafs Aussage werden objektorientierte Programmiermodelle wie C++ zwar weiterhin bestehen, allerdings stoßen sie beim Parallelprogrammieren immer wieder an ihre Grenzen, da es sehr schwer ist, Tasks zu kontrollieren. Asaf glaubt, dass man in Zukunft auf der obersten Abstraktionsebene viel stärker in Tasks denken muss, um dann im weiteren Verlauf mit Objekten arbeiten zu können. Allerdings behebt auch diese Heransgehensweise nicht das Problem immer wieder auftretender Zufallsabstürze, wie man sie beispielsweise bei Borland C++ 5.0 beobachten kann. Fazit: neue Programmiermodelle müssen her! Und Tools wie der VTune Amplifier XE für das Aufspüren potenzieller Abstürze von parallel programmierten Anwendungen.

Welche Programmiersprachen bevorzugst du?

Asaf setzt für seine Programme – der ersten Frage zum Trotz – am liebsten noch auf C und C++ (für den Programmcode) und auf C# (für das Programmieren für Bedieneroberflächen). Zudem lassen sich beide Sprachen mithilfe von .NET-Wrappern prima innerhalb derselben Entwicklungsumgebung wie Visual Studio verwenden.

Was sollte man Studenten empfehlen, die sich mit dem Thema Parallelprogrammierung beschäftigen wollen?

Guter parallel programmierter Code beginnt bereits mit dem Design. Denkt also nicht seriell, sondern parallel! Gute Anwendungen müssen sogar parallel programmiert sein, da der Computer von Haus parallel arbeitet, da er ja auf mehrere Ereignisse aus unterschiedlichen Richtungen gleichzeitig reagieren muss. Um den seriellen Eingabestrang, dem wir immer noch unterworfen sind, aufzubrechen, sollte man laut Asaf mit Threads oder Thread-Pools arbeiten. Parallelprogrammierung beginnt also in den Köpfen und erfordert sehr viel Arbeit und Umdenken beim Einsatz bekannter Modelle.

Das vollständige Interview können Sie auf dem SoftTalk-Blog nachlesen (Teil 1 und Teil 2).

Zudem möchten wir Sie an dieser Stelle noch einmal herzlich zu der exklusiven und kostenlosen Entwickler-Veransaltung einladen! Es sind nur noch wenige Plätze frei. Melden Sie sich am besten noch heute an!

Nun aber zu dem Interview: Eine wichtige Frage handelt von den Herausforderungen, mit denen Asaf in Sachen Parallelprogrammierung konfrontiert wurde. Dazu hat er eine ganz einfache Antwort parat: Der Umstieg war die größte Hürde, da es gar nicht so einfach war, parallel und nicht mehr seriell zu denken. So hatte er echte Schwierigkeiten, für kritische Code-Abschnitte einen Mutex anstatt eines Locks zu verwenden. Außerdem musste er beispielsweise erst mal lernen, dass ein Mutex nicht die kritische Sektion, sondern die betreffende Ressource, also die involvierten Speicherbereiche schützt.

Ein sehr schönes Bild hält Asaf auf die Frage bereit, was denn der beste Tipp in Sachen Parallelprogrammierung sei. Sein Antwort: Man muss wie Menschen und nicht wie Maschinen denken. Als konkreten Fall nennt er einen Schnellimbiss, bei dem mehrere Leute an mehreren Verkaufstheken gleichzeitig bestellen, und diese Bestellungen anschließend von verschiedenen Mitarbeitern des Restaurants bearbeitet und an die Kunden ausgegeben werden. Genau so verhält es sich nämlich mit asynchroner Datenverarbeitung mithilfe von Task-Queues, Worker-Threads und vielem mehr.

Interessant sind auch Asafs Antworten auf die Fragen, was Sandy Bridge und AVX für Entwickler tun können. So sieht er in der neuen Core-Architektur eine erhebliche Verbesserung für parallel programmierte Anwendungen, da aufgrund des Core-to-Core-Designs Daten schneller zwischen den einzelnen Prozessorkernen hin- und herfließen können, was die Zahl an Bottlenecks erheblich reduziert.

Als Beispiel führt er die Berechnung einer Aufgabe an, die ohne AVX vier Prozessorkerne mitsamt aller Sycnhronisationsalgorithmen erfordert. Mithilfe von AVX geschieht dies wegen der breiteren Register auf einem einzigen Prozessorkern, was natürlich viel zu besser handhabbar ist. AVX kann laut Asaf in bestimmten Fällen bis zu 16 Prozessorkerne eliminieren.

Die Fortsetzung des interssanten Interviews können Sie am Freitag hier lesen.

Manuel spricht in unserem Interview über die Optimierungen, die Nik Software an HDR Efex Pro vorgenommen hat. Die Rede ist aber auch von den Leistungssteigerungen, die das Lübecker Unternehmen dank des Einsatzes von AVX-Operationen erzielen konnte. Manuel spricht dabei von 30 bis 40 Prozent.

Und zu guter Letzt geht es noch um die Frage, welche Intel-Tools Nik Software zur Multicore-Optimierung seiner Anwendungen einsetzt. Die zugehörige Antwort fand ich dann doch einigermaßen überraschend. Doch seht am besten selbst…

Zusammengefasst kann man sagen, dass Entwickler ein oder zwei Augen auf die neuen Intel Array Building Blocks werfen sollten, mit deren Hilfe mathematische Operationen in Zukunft recht einfach auf mehreren Prozessorkernen parallel ausgeführt werden können. Darüber hinaus nahm er sich sogar die Zeit, das Konzept hinter den verwandten Intel Threading Building Blocks zu erläutern.

Darüber hinaus verfolgt Intel mit MIC eine interessante Strategie: dieser Quasi-Nachfolger von Larrabee wird wohl im nächsten Jahr auf den Markt kommen und von sämtlichen Tools unterstützt werden, die es jetzt auch schon gibt. Nur in angepasster und verbesserter Form, natürlich.

Aber auch zu MeeGo und den passenden Entwicklertools hatte James eine dedizierte Meinung, wie sich anhand der Beispiele für künftige MeeGo-Gerätschaften erkennen lässt: so nennt er Tablet-PCs an Nummer Eins, aber auch Handhelds, In-Car-Infotainment- und andere Gadgets werden in Zukunft mit MeeGo laufen. Sagt zumindest Chefentwickler James Reinders.

In welche Fallen tappen Software-Entwickler gemeinhin, wenn sie versuchen, seriell programmierte Anwendungen zu parallelisieren?

Gibt es Fälle, in denen es keinen Sinn macht, Teile einer Software-Anwendung zu parallelisieren?

Existieren gute Beispiele für erfolgreiche und erfolglose Versuche, bestehenden Code zu parallelisieren?

Na, dann viel Spaß mit dem Videointerview!

Ein wesentlicher Punkt ist unter anderem der Einsatz des Intel C++ Compilers, der laut Maxon schon mal ohne nennenswerte Änderungen am Code etwa 15 Prozent mehr Speed bringt. Aber auch der Intel Thread Profiler steht bei Maxon ganz oben auf der Liste, wenn es darum geht herauszufinden, wie sich das parallelisierte Programm verhält, ob also die anfallenden Threads möglichst gleichmäßig auf die vorhandenen Ressourcen verteilt werden (Skalierung ist hier das Zauberwort).

Darüber hinaus kommen VTune Performance Analyzer und Intel Threading Building Blocks zur Sprache. Ok, dann würde ich mal sagen, den Rest solltet ihr euch am besten selbst ansehen. Viel Spaß dabei!

Warum ich das alles erzähle? Nun, ich hatte gestern die exklusive Gelegenheit, mit Noel Borthwick ein ausführliches Telefonat zu führen. Noel ist CTO von Cakewalk, also der führende technische Kopf des Unternehmens. So gesehen hat Noel eine ganze Menge über Sonar und dessen Multithread-Fähigkeiten zu erzählen.

Zunächst einmal gab es ein wenig Geschichtliches. So erfuhr ich, dass Cakewalk Pro Audio etwa 1993/94 entstanden ist und damals schon multithread-fähig war. Ok, natürlich nur auf einer Multisocket-Plattform mit zwei parallel geschalteten Prozessoren, mit deren Hilfe es möglich war, die komplette Bedieneroberfläche auf einen separaten Thread auszulagern und die Audio Engine auf die zweite CPU. Das war sicherlich nicht sonderlich effektiv, zeigt aber, das sich Cakewalk schon seit mehr als 15 Jahren mit dem Thema Multithreading beschäftigt – und das sehr erfolgreich, wie die Firmenhistorie zeigt.

Im Jahr 2001 vollzog Cakewalk dann den Namenswechsel: Aus Cakewalk Pro Audio wurde Sonar und damit ein skalierendes Produkt, das auf Basis einer komplett neu entwickelten Audio Engine die Möglichkeiten des damals aufkommenden Software-Multithreadings erheblich besser ausnutzen konnte als sein Vorgänger. Hierfür war neben dem Redesign der Software auch ein eigener Task Scheduler notwendig, der in Sachen Funktionsumfang dem Task Scheduler der Intel TBB ähnelt. Für eine optimale Skalierung werden also die vorhandenen Ressourcen (Kerne) ermittelt und anhand dessen die anstehenden Aufgaben (Tasks) intern in Threads umgewandelt und zur Laufzeit dynamisch auf die vorhandenen Prozessorkerne verteilt.

Um diese Software-Skalierung zu perfektionieren, arbeitet Cakewalk kontinuierlich an Sonar. So kommt beispielsweise permanent der VTune Performance Analyzer zum Einsatz, um ausgeglichene Kernel Workloads zu erzielen. Aber auch Treiberprobleme lassen sich auf diesem Weg ermitteln und beheben. Dies führt insgesamt zu geringeren Ladezeiten, was sich vor allem bei großen Musikprojekten positiv bemerkbar macht, die sich aus einer Vielzahl von Tracks, Plugins und anderen Objekten zusammensetzen. Zudem lassen sich mit VTune recht einfach Cache Misses und andere unschöne Dinge ausfindig machen.

Der Thread Checker ist für Cakewalk immer wieder von Vorteil, wenn es zum Beispiel um das Aufspüren von Synchronisationsproblemen von Threads geht, die ja meist erst zur Laufzeit auftauchen. So half Thread Checker Cakewalk beim Eliminieren eines Priority Inversion-Problems, das sich eines Tages in Sonar 8 bemerkbar machte: Aufgrund einer falschen Thread-Priorisierung verhielt sich das Tool an manchen Stellen völlig anders als erwartet, was natürlich mit unzufriedenen Kunden endete. Dank Thread Checker konnte das Laufzeitproblem behoben werden und alle waren wieder glücklich.

Surftipp: Wenn ihr mal sehen wollt, wie sich Multithreading in Sonar 8 bemerkbar macht, solltet ihr unbedingt diese Webseite ansurfen. Dort gibt es sehr aufschlussreiche Benchmarks, die Sonar 8 mit dessen Vorgänger Sonar 7 vergleichen. Vor allem beim Sonar-eigenen Benchmark kamen Steigerungsraten von bis zu 240 Prozent heraus. Ich sag mal, da haben die Cakewalk-Entwickler multithreading-seitig ganze Arbeit geleistet!

Das Extrahieren dieser Daten geschieht in Echtzeit, also während des laufenden Betriebs. Um eine möglichst reibungslose Archivierung zu garantieren, hat sich die CSP schon sehr früh auf das Multithreaden ihrer Anwendung konzentriert.

Das gesamte Konzept ist also auf parallele Datenverarbeitung ausgelegt. Es findet sogar eine doppelte Parallelisierung statt: Es kommt ein Mini-Cluster zum Einsatz, in dem einzelne Server bestimmte Aufgaben übernehmen. Und innerhalb dieser Server gibt es eine hohe Multithreading-Kultur, die eine skalierende Ausführung der Anwendung sicherstellt.

Chronos ist übrigens vollständig in Java programmiert und findet innerhalb der Java Runtime Environment statt, die standardmäßig mit Java-Threads auskommt. Auf diesem Weg können Java-Anwendungen mithilfe bestimmter Bibliotheken und Klassen parallelisiert werden. Für die komplette Verwaltung sämtlicher Threads hat CSP übrigens einen eigenen Threadmanager entwickelt, der im Hintergrund analog zu den Threading Building Blocks die einzelnen Tasks auf die vorhandenen Prozessoren und Threads verteilt. Für eine bestmögliche Auslastung der Ressourcen.

Wieso können sich die Entwickler von CSP aber so sicher sein, dass Chronos wirklich optimal auf Intel Multicore-Plattformen skaliert? Nun, um das herauszufinden, besorgte man sich in Pilsting-Großköllnbach das kostenlose Tool Concurrency Checker, mit dessen Hilfe festgestellt werden kann, ob eine Anwendung effizient auf Intel Multicore-Plattformen läuft.

Und die Entwickler der CSP GmbH waren ziemlich schnell davon überzeugt, dass der Concurrency Checker das richtige Tool für ihre Zwecke ist. Denn sie waren sehr zufrieden mit der Bedienbarkeit des Programms, da sie für einen ausführlichen Multicore-Test gerade mal einen halben Tag investieren mussten. Danach war den CSP-Programmierern klar, dass sich der Concurrency Checker für ihre Zwecke optimal einsetzen lässt. Und dass Chronos auch das hält, was es verspricht: eine optimale Ausnutzung der vorhandenen Systemressourcen, sprich der Prozessorkerne und Threads.

Wie unterstützt das .NET Framework 4.0 die parallele Programmierung?
Hierfür gibt es diverse Komponenten. Es wird sowohl für den Bereich “Managed Applications” – also C# und Konsorten – als auch für native Programmiersprachen (Fortran, C++ etc.) Bibliotheken und ähnliche Dinge geben. Für beide Programmiermodelle wurde die Concurrency Runtime entsprechend aufgebohrt.

Für die .NET-Entwickler gibt es dann zwei neue Modelle, und zwar die Task Parallel Library (TPL) und PLING. Mit der TPL lassen sich Aufgaben abstrahieren, was unter der Oberfläche und mithilfe der Concurrency Runtime zu Threads führt, um deren Verteilung auf die einzelnen Prozessorkerne sich der Entwickler nicht mehr kümmern muss. PLINQ stellt eine parallelisierte Erweiterung von LINQ dar. Und LINQ wiederum ist “eine Komponente von Microsofts .NET-Framework, mit der SQL-, XLink- und XQuery-Anfragen direkt in .NET-Programmiersprachen wie C# 3.0 oder VB.Net 9.0 als Code statt als String eingebunden werden können” (Quelle: Wikipedia).

Aber auch bei den nativen Sprachen gibt es neue Ansätze bezüglich der Concurrency Runtime: Dies ist zum einen die Parallel Pattern Library, die sich mit den Intel Threading Building Blocks vergleichen lässt. Zum anderen bietet Visual Studio 2010 eine Agent Library für C++ und Co, die bestimmte Aufgaben verwalten und ausführen kann.

Was sagen Sie Entwicklern, wenn Sie mit ihnen über die parallele Programmierung reden?
Das hängt davon ab, mit wem ich spreche. Entwickler, die sich zum Beispiel schon länger mit serviceorientierten Anwendungen beschäftigen, in denen separate Aufgaben durch Dienste erledigt werden, verstehen das Konzept der parallelen Programmierung oft schneller als Programmierer, die nur die rein serielle Entwicklung kennen. Wichtig dabei ist die Erkenntnis, dass es in den meisten Anwendungen Programmteile gibt, die man loslösen kann von der restlichen Programmlogik. Ein Beispiel hierfür ist die parallele Speicherung von Daten.

Für viele Entwickler stellt aber die Parallelisierung von Bedieneroberflächen ein großes Problem dar, da hier vieles noch vom Betriebssystem mithilfe von Nachrichtenschlangen verwaltet wird. Hierfür wird es in .NET 4.0 entsprechende Bibliotheken geben, die diese Aufgaben automatisch übernehmen.

Welche Anwendungsgruppen werden von der Parallelisierung hauptsächlich profitieren?
Da sind zum einen die algorithmus-basierten Anwendungen zu nennen (Bildbearbeitung, Encoder etc.), aber auch klassische Geschäftsanwendungen wie CRM-Systeme bergen viel paralleles Potenzial. Hier können beispielsweise Anfragen an das Backend simultan ausgeführt werden, was die Wartezeiten auf das Ergebnis verkürzt. Allerdings liegt allen parallelisierten Anwendungen eine bestimmte Arbeit vor dem eigentlichen Kodieren zugrunde: Welche Programmbereiche kann ich logisch zusammenfassen und daraus einzelne Aufgaben machen, die als Tasks abstrahiert werden können und sich dann von der Concurrency Runtime als separate Threads ausführen lassen.

Wie unterstützt Microsoft die Community in Sachen Visual Studio 2010, .NET 4.0 und Parallelprogrammierung?
Neben den kommerziellen Konferenzen wie der Microsoft Tech-Ed oder dem Tech Summit gibt es beispielsweise die Möglichkeit, über Microsoft in ein Early-Adopter-Programm hineinzukommen, um auf diesem Weg Betatester zu werden. Darüber hinaus kann man uns auch direkt auf gewünschte Workshops und ähnliche Dinge ansprechen. Und natürlich nutzen wir die gesamte Online-Vielfalt wie Webcasts und Blogs, um unsere Themen zu kommunizieren. Aber auch viele Microsoft-nahe Communities stehen derlei Themen offen gegenüber. Dort trägt Microsoft an und ab selbst zur Aufklärung in Sachen Multicore und ähnlichen Dingen bei.

Aus diesem Grund werde ich mich heute und morgen Nachmittag im Messezentrum München herumtreiben und diesbezügliche Informationen zusammentragen. So treffe ich unter anderem die Leute der Dotnetpro, die auf der OOP mit einem eigenem Stand vertreten sein werden. Eines ihrer Themen wird die erste deutschsprachige Multicore-Konferenz sein, die am 23. April diesen Jahres ebenfalls in München stattfindet.

Am Dotnetpro-Stand hoffe ich die Hauptredner des Multicore-Powerday zu treffen, Ralf Westphal und Bernd Marquardt. Mit beiden plane ich kurze Interviews, in denen sie mir hoffentlich ein wenig mehr über ihre Sessions auf der Eintagesveranstaltung im April erzählen werden.

Nach diesen Interviews treffe ich mich mit einer weiteren Koryphäe der Multicore-Programmierung: Walter F. Tichy von der Uni Karlsruhe, der um 17:45 Uhr mit seinem Vortrag “Herausforderung Mehrkernsysteme” dran ist. Im Gespräch mit ihm werde ich versuchen, die scheinbaren Widersprüche aufzulösen, die in seinem Gastbeitrag zu stecken scheinen, den er für die Online-Ausgabe der Computerzeitung geschrieben hat. In seinem Vortrag scheint er ebenfalls ein, zwei diskussionswürdige Thesen zu vertreten:

Der Vortrag skizziert die gegenwärtige Hardwareentwicklung und geht dann auf erste Erfahrungen mit der Parallelisierung nicht-numerischer Anwendungen ein. Insbesondere werden einige der üblichen Parallelisierungsempfehlungen als Mythen entlarvt.

Wie dem auch sei, ich bin schon sehr gespannt, was die Herren Westphal, Marquardt und Tichy zu erzählen haben. Und was sonst noch alles auf der OOP 2009 los ist, sehe ich mir ebenfalls an und werde darüber live und in Farbe berichten. So, stay tuned …

Update: Ich habe während der OOP 2009 zwei Vorträge zum Thema Multicore-Programmierung besucht. Daraus sind 12 Thesen zur Multithread-Entwicklung enstanden sowie eine mehrteilige Mini-Serie zum Thema Multicore-Programmierung (Teil 1, Teil 2, Teil 3).

In beiden Fällen wollten wir natürlich wissen, welche Anstrengungen unternommen wurden, um die Spieletitel zu parallelisieren. Tja, und heute haben wir Teil eins unserer Fragen zurückbekommen, und zwar von Crysis. Geantwortet hat der Director of Technology höchstpersönlich, Mister Mark Atkinson. Mark zeichnet übrigens verantwortlich für erfolgreiche Titel wie Burnout Revenge und Football Manager 2009, die er vor seiner Zeit bei Crytek mitentwickelt hat.

Software Dev Blog: Mit welchen Tools haben Sie Crysis für Multicore-Plattformen optimiert?
Mark Atkinson: Wir setzen im Wesentlichen eigene Tools ein, um den Quellcode unserer Spieletitel wie Crysis für Multicore-Plattformen zu optimieren. Aber auch externe Anwendungen wie der VTune Performance Analyzer kommen bei uns zum Einsatz. Dieser ist für uns vor allem wegen des Thread Profilers interessant, mit dessen Hilfe wir überprüfen können, in welchem Umfang und in welcher Qualität die Parallelisierung des Spieletitels gelungen ist.

Welche Hürden mussten Sie bei der Multicore-Optimierung überwinden?
Atkinson: Die wesentliche Arbeit bestand darin, die Game-Engine völlig umzukrempeln. Wir mussten nämlich große Teile des sequenziell programmierten Quellcodes parallelisieren, damit bestimmte Aufgaben wie die KI, Effekte etc. gleichzeitig ablaufen. Nur so konnten wir das optimale Spielerlebnis erreichen, das Crysis auszeichnet.

Welche Tipps würden Sie Entwicklern geben, wenn diese parallelen Programmcode schreiben wollen?
Atkinson: Die Hauptregel lautet: Erstelle fehlerfreien Sourcecode vom ersten Moment an. Denn parallel programmierte Anwendungen und Spiele lassen sich nur sehr aufwändig testen und debuggen. Daher sollte man von Anfang an darauf achten, dass sich erst gar keine Fehler in den Code einschleichen. Wir setzen hierfür erprobte Methoden, Bibliotheken und Hilfesysteme ein, die uns dabei unterstützen. Außerdem sorgen wir dafür, dass unsere Software-Entwickler bestens in Sachen Paralellprogrammierung ausgebildet sind. Denn nichts erfordert mehr Know-how als der Umstieg von der sequenziellen auf die parallele Programmierung.