Intel-Ausstellungsbereich mit Florian und Monika

Und nun zu den Developer-Tools, die jeder Parallel-Programmierer kennen sollte. Zumindest deren Unterschiede, Stärken und Schwächen, denn so fällt es nicht nur leichter, sich für das richtige Werkzeug zu entscheiden, sondern auch Fehler im Code zu minimieren. Aber natürlich lassen sich die Tools im Einsatz auch kombinieren.

Merken Sie sich auf jeden Fall diesen Namen: Parallel Building Blocks. Denn diese Toolsuite vereint drei der wichtigsten Werkzeuge für Parallel-Programmierer: Cilk Plus, Threading Building Blocks (TBB) und die neuen Intel Array Building Blocks (ArBB), die derzeit noch in der Beta-Phase sind.

Cilk und Intel Array Building Blocks (ArBB) werde ich hier näher vorstellen.

Cilk Plus

Cilk Plus ist unbestritten das einfachste Tool und auch für Einsteiger sicher gut geeignet. Streng genommen sind sich Cilk und OpenMP recht ähnlich. Beide produzieren schnellen, parallelen Code ohne viel Overhead. Und beide werden von Intel Compilern unterstützt. Das gilt im Übrigen auch für OpenMP in der Version 3. Es gibt aber auch gravierende Unterschiede, die Cilk für Entwickler deutlich attraktiver machen als OpenMP.

Das beginnt schon bei der Bedienung. Wer sich jemals mit Cilk auseinandergesetzt hat, wird sich an das Schlüsselwörter-Prinzip erinnern. Mit den drei Kommandos cilk_spawn, cilk_sync, cilk_for erledigen Sie die wichtigsten Aufgaben im Code. Dabei kontrolliert die Cilk Plus Runtime die Threads und deren zeitliche Ausführung. Gerade dieser sehr zuverlässige Cilk Runtime Scheduler hebt sich wohltuend von OpenMP ab. Die Zahl der Threads im Code wird hierbei automatisch den vorhandenen Prozessorkernen angepasst. Der Entwickler kann dies aber auch korrigieren, wenn er das möchte.

Auch auf Data Races hat Cilk Plus eine Antwort. Natürlich lassen sich Variablen auch mit der Mutex-Methode schützen, aber Cilk Plus geht hier deutlich eleganter vor, indem es Hyperobjects nutzt. Das sorgt für eine deutliche bessere Performance.

Herauszuheben sind last but not least die Array Notations in Cilk Plus. Darüber freut sich der Compiler, der Vektoranweisungen viel besser verarbeiten kann als Schleifen. Weitere Infos gibt es übrigens auf der sehr guten Seite www.cilk.com.

Intel Threading Building Blocks (TBB)

Die Intel Threading Building Blocks (TBB) bieten eine C++-Laufzeitbibliothek und sind als Open Source oder per Compiler verfügbar. Sie sind plattform- und sprachenunabhängig und adressieren vor allem fortgeschrittene Developer. Mit anfängertauglichen Parallelfunktionen wie „parallel_for“ statt „for“ werden die TBB aber auch zunehmend für Einsteiger interessant.

Intel Array Building Blocks (ArBB)

Die jüngste Sprössling der Parallel Building Blocks heißt Intel Array Building Blocks (ArBB).
Vereinfacht ausgedrückt erledigen die ArBB folgenden Job für Code in C++: Sie parallelisieren und optimieren nativen Code, und zwar genau für die Hardware, für die er konzipiert wurde und geben den Code an den Compiler zurück.

Vorteil für den Entwickler: Er muss den Code auch für unterschiedliche Pattformen nur ein einziges Mal schreiben, kann ihn mit ArBB neu kompilieren und dann automatisch auf die Ziel-Hardware ausrichten. Wer es selber ausprobieren möchte: ArBB steht als Beta zum kostenlosen Download bereit.

So, das war’s aus Köln. In der nächsten Woche werde ich wieder live berichten – dann vom ISN Black Belt Event in München. Schönes Wochenende!

Nun aber zum Inhalt der Konferenz: Zu Beginn hat Aaaron Coday, Intel-Experte für Visual Computing, Graphics and Gaming, einen erweiterten Überblick zu den aktuellen Prozessorgenerationen gegeben und die Vorteile für Entwickler verdeutlicht. Eine kleine “Überraschung” zu Beginn: Von „Sandy Bridge“ will Intel künftig nicht mehr sprechen, sondern nur noch von der offiziellen Bezeichnung „2nd Generation Intel Core Processor Family“. Das finde ich ein „bisschen“ sperrig und bleibe dann doch lieber bei der geläufigen Bezeichnung „Sandy Bridge“.

Sandy Bridge ist zu Beginn des Jahres mit den Zielen gestartet, energieeffizienter zu arbeiten, mehr Leistung bereitzustellen (nicht nur, aber vor allem für grafisch anspruchsvolle Anwendungen) und Multimedia-Inhalte wie Videos schneller und besser zu en- und dekodieren, indem das Preprocessing und Encoding nicht mehr software-basiert, sondern von der Hardware vorgenommen wird.

Aus Developer-Sicht ist in diesem Zusammenhang auch die Bedeutung des Intel Media SDK hervorzuheben. Es gibt Codeschreibern die Möglichkeit, über nunmehr nur noch eine API auf die optimierten Libraries des Intel Compilers zuzugreifen und Videos damit schneller und vor allem einfacher zu berechnen.

Aaron verdeutlichte, dass der SSE-Nachfolger AVX mit der doppelten Registerbreite (nun 256 Bit gegenüber 128 Bit bei SSE 4.0) sowohl Spielern als auch Game-Programmierern deutlich mehr Komfort und Möglichkeiten eröffnet. So lassen sich grafisch sehr anspruchsvolle Spiele auch auf ressourcenschwachen Netbooks flüssiger abspielen, weil dank AVX die einzelnen Bilder schneller geladen und synchronisiert werden. Zu diesem Thema habe ich ja in der Vergangenheit ebenfalls sehr ausführlich berichtet.

Interessant in diesem Zusammenhang: Aaron prophezeite, dass schon im übernächsten Jahr die Zahl der Single-Core-Systeme fast auf null sinken werde, hingegen werde jeder zweite, weltweit eingesetzte PC vier oder mehr Prozessor-Kerne besitzen.

Einen Blick in die Zukunft wagte auch James Reinders in seinem Vortrag über „Software Ecosystems“. Im kommenden Jahr werde Intel eine Reihe neuer Tools veröffentlichen, die den aktuellen und kommenden technischen Standard der Prozessortechnologie berücksichtigen und damit bereits auf Knight Ferry/Knighs Corner ausgerichtet werden. Dazu gehören:

• Intel Cilk Plus für weitere Compiler

• Intel Array Building Blocks

• Intel Threading Building Blocks 4.0

Am morgigen Mittwoch werde ich ein Video-Interview mit James Reinders führen und sicherlich noch das eine oder andere Detail zu den künftigen Tools erfahren.

Update: Das Videointerview mit James steht ab sofort zum Anschauen bereit.

Die erste interessante Aussage, die Ralf während seiner 75-Minuten-Session abgefeuert hat, war die Erkenntnis, dass Software-Entwickler sich selbst um das Parallelisieren ihrer Anwendungen kümmern müssen und dies nicht nur dem Betriebssystem oder anderen Instanzen überlassen dürfen. Ein weiterer Satz war nicht ganz überraschend und auch nicht neu, dafür umso wichtiger: “The free lunch is over!” Dieser Ausspruch stammt übrigens nicht von Ralf, sondern von Herb Sutter, der das bereits 2005 formuliert hat. Die Grundaussage dahinter lautet:

Künftige Prozessoren werden nicht mehr unendlich schneller, sind dafür mit immer mehr CPU-Kernen ausgestattet. Daher müssen Programmierer umdenken, um ihre Anwendungen in Zukunft zu beschleunigen.

Schenkt man Ralf Glauben (und das tue ich), steht die Parallelprogrammierung im Wesentlichen für folgende Dinge:

Reduced latency, higher performance, hiding latency, higher responsivness and increased throughput.

Dann folgten zwei eher rhetorische Fragen, deren Antworten man mit ein wenig Nachdenken sehr schnell selbst beantworten konnte:

Does firing up as many threads as cores are available help to accelerate apps? No, because this will cause threads waiting!

Does firing up as many threads as needed helps to accelerate apps? No, because it doesn’t scale!

Mit einem sehr schönen Vergleich leitete Ralf dann den Abschnitt “CCR” ein, indem er die digitale Kommunikation via E-Mail mit der asynchronen Programmierung verglich. Denn wie beim Verteilen von Aufgaben per Mail erfolgt das Ausführen von Tasks mithilfe der CCR genauso asynchron, indem ständig priorisiert und verteilt wird. Sehr anschaulich, oder?!

Dazu passen auch folgende Aussagen:

Concurrency Coordination Runtime (CCR) helps to let data flow around and make thus asynchronous apps possible.

Parallel Computing is all about cooperative multitasking where you have to think about small processes and steps.

Anschließend folgte die sehr anschauliche Demo, die den Einsatz der CCR in Form eines Programmierbeispiels zeigte. Dies hier wiederzugeben, wäre ein wenig zu umfangreich und auch kaum hilfreich. Allerdings stellt Microsoft angeblich sämtliche Sessions als Webcast online. Sobald Ralfs verfügbar ist, werde ich sie hier verlinken.

Natürlich haben wir Ralf nicht gehen lassen, ohne ihm drei Fragen zu stellen, die mit seinen Vorträgen auf der TechEd zu tun haben, mit der CCR und einer ganz exklusiven Geschichte, die er am Ende seiner Session zum ersten Mal in der Öffentlichkeit vorgestellt hat. Sobald das Videointerview online ist, werden ich es hier reinstellen.

Sein Vortrag hatte allerdings eher den Charakter eines technischen Workshops, indem er selbst zunächst eine Menge zum Thema Intel, Microsoft und Multicore-Shift inklusive .NET 4 und Visual Studio 2010 erzählt hat. Auszüge gefällig?

TPL of .NET 4 delivers the right number of threads regarding the available number of cores/threads.

Needs around 200.000 instruction cycles to create a thread and 100.000 for releasing it again. As a developer you have take this into account!

TPL delivers several parallel classes like Parallel.For() and Parallel.Invoke which abstracts threads to tasks.

Visual Studio 2010 will deliver the appropriate debugger tools for parallelized applications.

Was seiner Techsession allerdings ein wenig fehlte war der Blick in seine Glaskugel, die uns Anwesenden etwas über die Zukunft der Parallelprogrammierung hätte erzählen können. Zumindest war ich genau aus diesem Grund in seinem Vortrag. Das ließ sich allerdings ganz schnell nachholen, indem wir unsere Videokamera aufgebaut und Tiberiu drei schlaue Fragen gestellt haben. Die erste handelt vom Inhalt seiner Präsentation, Nummer zwei beschäftigt sich mit seiner Podiumsdiskussion vom Montag und mit der Beantwortung von Frage drei ließ er uns in die Zukunft der Parallelprogrammierung blicken.

Nur so viel dazu: Laut Tiberiu müssen sich Software-Entwickler ab sofort mit Multithreading und Co. auseinander setzen, denn der Multicore-Shift hat schon längst begonnen. Und den Rest schaut ihr euch am besten selbst an, sobald unser Videointerview fertig und online ist.

Update: Das Video ist fertig!

Zunächst einmal muss festgehalten werden, dass die Session genauso gut besucht war wie die gestrige von Steve Teixeira. Darüber hinaus wurde schnell klar, dass die meisten Anwesenden weder wussten, dass Intel noch etwas anderes produziert als Mikroprozessoren, noch die Intel-Tools wie VTune Performance Analyzer kannten (was angesichts des “weder” keine Überrraschung war).

Ramis Präsentation befasste sich mit drei Kerngebieten: Intels aktuelle und zukünftige Mikroprozessor-Architekturen, .NET-4-Verbesserungen in Sachen Multithreading und wie Intel-Tools wie der besagte VTune Performance Analyzer Software-Entwicklern helfen können, ihre Apps auf Korrekheit hin zu überprüfen. Zu diesem Behufe sagte Rami einige bemerkenswerte Dinge:

Moore’s law doesn’t help software developers anymore as frequencies aren’t going up anymore. The good news: the number of core does!

With Nehalem you get Non Uniform Memory Acess (NUMA) which connects every CPU and memory to each other which has huge advantages.

Come to Intel booth in hall 4.2 to see one of the first desktop PCs which is able to run 128 threads in parallel!

Multithreading is not equal parallelism!

Poor scaling .NET applications can be powered up with the help of Intel VTune Performance Analyzer and Visual Studio 2010 / .NET 4

.NET 4 provides the Background Garbage Collection which speeds up managed code significantly.

Worker stealing within .NET 4 will help to achieve better multithreaded balanced managed applications.

VTune profiles and samples .NET applications in order to find critical code sections where a lot of computing time is being wasted

Vtune also helps identifying false sharing problems. Means VTune will detect and solve cache line misses.

To eliminate  false sharing problems helps to speed up your .NET apps on 8 core system by 70x!

Sehr anschaulich und beeindruckend war auch die Maze-Solving-Demo, die Rami dabei hatte. Ziel solch eines Maze Solvers ist das Aufspüren des optimalen Pfades innerhalb einer zweidimensionalen Umgebung, wie dies beispielsweise in Logistikanwendungen häufig notwendig ist. Um die Leistungsfähigkeit von .NET 4 und Multithreading zu demonstrieren, startete Rami die Demo zunächst unter .NET 3.5 im seriellen Modus. Das Problem wurde unter .NET 3.5 in 14 Sekunden gelöst, unter .NET 4 hingegen in 12, und das nur wegen der architekturellen Verbesserungen im .NET-4-Framework. Und klar, dass die Multithreading-Variante in .NET 4 das Problem blitzschnell in wenigen Sekunden löste.

Spannend fand ich auch seine Ausführungen bezüglich VTune und .NET. Denn dieses Tool wird vorwiegend zur Fehlersuche in nativ programmierten Anwendungen eingesetzt. Umso überraschender war die Erkenntnis, dass VTune auch .NET-Entwicklern bei ihrer Arbeit helfen kann. Hierzu erstellt VTune ein Profil der laufenden Anwendung und generiert dabei eine große Zahl an Samples, die dann kumuliert und gewichtet werden. Das Ergebnis zeigt auf einen Blick, wo sich mögliche Hotspots innerhalb des Codes befinden.

Natürlich hatten wir während Ramis Präsentation die Kamera aufgebaut und diese bis zum Schluss mitlaufen lassen. Klar ist aber auch, dass wir daraus keinen 75-Minüter bauen. Tom schneidet gerade die besten Szenen zusammen, mischt diese mit dem Interview, das wir mit Rami nach seinem Vortrag geführt haben, und wenn das Video fertig auf Youtube steht, werden wir es hier veröffentlichen. Freut euch schon mal auf sehr anschaulichen Content.

Update: Das Video ist fertig!

Intel Parallel Studio = Amplifier + Inspector + Composer + Advisor = Multicore optimization

Parallel Advisor helps you to parallelize your native code. But from 2010 onwards only.

With Parallel Inspector you find memory errors before they happen. Works on serial AND threaded code.

Intel Parallel Amplifier is a child of VTune Performance Analyzer, but easier and more intuitively to use. Profile you parallel code.

On http://wwwintel.com/go/para… you’ll find more information about Parallel Studio and more.

Nach der Parallel-Studio-Session gab es das dann das lang ersehnte Netbook, ein Sony Vaio. Sehr schickes Teil. Der Durchgang zwischen Theater und Intel-Stand war entsprechend für eine kurze Zeitspanne komplett verstopft. Kein Wunder: Netbooks sind gerade der große Renner.

Für alle, die nicht dabei sein konnten, haben wir Ralphs Vortrag und die Netbook-Verlosung mit unserer JVC-Kamera auf SD-Karte gespeichert. Sobald Tom die besten Bilder zusammengeschnitten hat, geht das Video hier online.

Update: Hier ist das Video. Viel Spaß damit!

So wie heute morgen um 9:00 Uhr in der Früh, was aber die anwesenden Software-Entwickler nicht davon abgehalten hat, den Raum bis auf den letzten Platz zu füllen. Das zeigt zweierlei: Erstens hat das Thema Multithreading viele Leute schon erreicht, und zweitens besteht offensichtlich noch eine Menge an Informationsbedarf. Und da ist Steve genau der richtige, um vorhandene Wissenslücken zu füllen.

Für alle, die es nicht mitbekommen haben: Ich saß in der Session und habe mir die Seele aus dem Leib getwittert. Ein paar Kostproben gefällig?

First demo: LINQ versus PLINQ. Guess who is faster? Got it?! Yes, PLINQ is 3.3x faster.

The only difference between LINQ & PLINQ is a little “AsParallel()”. Very easy, very intuitive!

ParallelEnumarable() fits perfectly for parallel computing with huge data. Think of financial applications, e.g.

There’s one important advice by Steve: Don’t use threads but tasks. .NET 4 is supporting with Parallel.Invoke() e.g.

With .NET 4 you can delay tasks in order to run them later as soon you need them.

Diese und andere Aussagen ergaben ein klares Bild: .NET 4 soll und wird die Parallelprogrammierung verbessern, und das mit einem klaren Konzept, mit Tasks statt Threads und den passenden Tools wie einem Debugger, der viele Informationen über die laufenden Threads und Tasks liefert.

Direkt nach der Session konnten wir übrigens Steve Teixeira dazu überreden, uns vor der Kamera ein paar Fragen zu beantworten. Kollege Papadhimas ist gerade am Schnitt dran. Sobald das Video fertig und auf Youtube gestellt ist, kommt hier der Embedcode rein. Damit ihr auch etwas davon habt.

Update: Das Video ist fertig geschnitten, gerendert und auf Youtube. Und hier. So, Film ab.

• Steve Teixeira wird morgen früh (Di, 9:00) etwas zu “Parallel Computing for Managed Developers” erzählen. Hoffentlich bekommen wir Steve hinterher für ein Interview vor die Kamera.
• Um 15:15 Uhr geht es dann um das Thema HPC und Virtualisierung. Auch hier planen wir ein anschließendes Videointerview.
• Intel-Kollege Rami, der am Mittwoch seine Techsession hat, wird uns in seiner Demo zeigen, wie Managed Code mithilfe von VTune optimiert werden kann.
• Natürlich werden wir auch Bilder von der Parallel-Studio-Session inklusive Netbook-Verlosung zeigen.
• Am Mittwoch hat dann Rami seine besagte Techsession. Hinterher stellen wir im ein paar schlaue Fragen.
• Um 10:15 Uhr geht es direkt weiter mit F# und dessen parallelen Fähigkeiten. Hinterher gibt’s hoffentlich ein Videochat mit Donald Syme.
• Tiberiu Covaci hält um 12:20 Uhr seinen Vortrag mit dem Titel “The Future of Parallel Programming”. Anschließend werden wir Tiberiu zu seinen diversen Techsessions befragen. Auch zu denen, die wir heute Morgen leider nicht besuchen konnten.
• Und falls ihr nochmals die 15-Minuten-Präsentation samt Netbook-Verlosung sehen wollt: Am Mittwoch ist wieder Gelegenheit dazu.
• Der Donnerstag beginnt mit einer Parallelsession mit dem Titel “Going Parallel for a Living: Introduction to the Concurrency Coordination Runtime” des lieben Kollegen Ralf Westphal. Mal sehen, ob er uns auch vor der Kamera etwas erzählt.
• Um 15:15 Uhr ist Steve Teixeira noch mal dran, und zwar mit seiner Session “Building High Performance Parallel Software”. Ob Steve sich zweimal von uns interviewen lässt?
• Natürlich gibt es auch am Donnerstag die fast schon lieb gewonnene 15-Minuten-Session inklusive Netbook-Vergabe. Aber diesmal schenken wir uns das vielleicht. Wir wollen ja niemanden langweilen.
• Und klar, dass die Intel-Kollegin Beatrice noch zu Wort kommt. Sie will nämlich unbedingt etwas zum Intel Atom Developer Program erzählen.

So, und nach so vielen Programmankündigungen kommen jetzt endlich die Impressionen aus Berlin. Film ab!

Bevor ich es ganz vergesse, folgen hier noch ein paar organisatorische Dinge: Der Intel-Stand, an dem ihr mich und die Kollegen treffen könnt, befindet sich in Halle 4.2 und liegt von der Halle 7 kommend direkt am Eingang. Das ist die so genannten Visual Studio Partner Zone. Dort gibt es unter anderem eine Menge nützliche und erhellende Infos rund um das neue Intel Atom Developer Program, das Software-Entwicklern dabei helfen soll, windows- und moblin-basierte Anwendungen speziell für Netbooks zu entwickeln und diese zu einem späteren Zeitpunkt auf Netbooks zu bringen. Falls ihr euch für dieses Programm direkt am Stand registriert, gibt’s auch eine kleine Überraschung.

Darüber hinaus findet ihr eine Menge Infos rund um unser liebstes Baby, das auf den schönen Namen Intel Parallel Studio hört und in rund zwei Wochen sein Halbjähriges feiert. Falls ihr also C-/C++-Programmierer seid, Visual Studio einsetzt und eure Anwendungen threadsicher parallelisieren wollt oder einfach nur gucken wollt, ob sich besonders fiese Bugs eingeschlichen haben, die sich möglicherweise erst zur Laufzeit zeigen, ist Parallel Studio genau das richtige Tool für euch. Hier könnt ihr sogar eine Test-CD abgreifen, um euch mit Parallel Studio vertraut zu machen.

Und falls ihr ein neues Netbook wollt, solltet ihr ebenfalls am Stand V1/V2 vorbeikommen. Beantwortet ein paar Fragen, tragt eure Daten ein und schwups, ab mit der Karte in die zugehörige Losbox. Und schon gewinnt ihr vielleicht eins der schicken Teile. Die erste Verlosung ist allerdings erst morgen Nachmittag, die ausgefüllten Karten werden aber auch schon heute akzeptiert.

So, dann mach ich mich wieder auf den Weg zum Stand. Um den Monitor zu installieren, der gerade gekommen ist. Damit ihr auch besser sehen könnt, was ich twittere und blogge. Man sieht sich!

Ach ja: Auf der anderen Seite der Halle hat Intel noch einen Stand, auf dem es rund um das Thema Datacenter geht. Also alles über Servertechniken, Virtualisierung und Co. Und dort gibt es ebenfalls etwas zu gewinnen, nämlich schicke, ultradünne Notebooks. Ihr seht, ein Besuch der Halle 4.2 lohnt sich auf jeden Fall.

Multithreaded programming is “hard” today

Das bedeutet für Microsoft (und Intel), Software-Entwicklern dabei zu helfen. Hierzu bieten beide (Intel und Microsoft) passende Tools, die Programmierer unterstützen. Dazu gehören laut Steve aber auch Programmiersprachen und Plattformen.

Ein kleines Schleifenbeispiel führt Steve vor, das zeigen soll, wie sich seriell programmierter Quellcode parallelisieren lässt – inklusive potenzieller Probleme.

Als Lösung für das Sortierproblem eignet sich laut Steve LINQ, das Teil von .NET 3.5 ist. Weitergesponnen bietet die parallele Version von LINQ = PLINQ eine viel bessere Lösung für Sortieralgorithmen – und mehr!

Die nächste Folie – und Steve hat eine Menge davon – zeigt den Aufbau von Visual Studio 2010. Dazu gehören Tools wie Parallel Debugger und Profiler Concurrency Analysis, Programmierungsmodelle wie PLIN!, Task Parallel Library (TPL) und mehr.

Ein paar Daten zu TPL: Es handelt sich dabei um eine parallel API mit speziellen Konstrukten wie parallel_for, parallel_invoke, critical_section (Synchronisation), task_group (Tasks), combinable<T> (Container) etc.

Jetzt folgt ein Beispiel für die anwesenden C++-Programmierer: Es zeigt eine Matrizenberechnung, genauer gesagt eine vektorbasierte Addition. Zuerst geht es um die serielle Implementierung der Rechenaufgabe, dann um die parallele mithilfe einer Lambda-Funktion und der parallel_for aus der TPL. Dabei muss man sich ernsthafte Gedanken um Race Conditions machen. Die Lösung des Problems: Es gibt mehrere Instanzen des Rückgabewerts, die am Ende addiert werden.

Die Asynchronous Agents Library eignet sich vor allem für das asynchrone Ausführung paralleler Quellcode-Abschnitte. Damit lassen sich parallel ablaufende Programminstanzen generieren, die nichts voneinander wissen, die damit nicht synchronisiert oder gelockt werden müssen. Das erlaubt eine sichere Implementierung der parallelisierten Anwendung.

Der Concurrency Runtime Scheduler ist ein Dieb: Tasks werden auf die Worker Threads verteilt und parallel ausgeführt. Sobald einer der Worker Threads nichts zu tun hat, “stiehlt” er eine laufende Aufgabe eines anderen Worker Threads, was zu einer besseren Auslastung der vorhandenen Prozessorkerne führt.

Jetzt ist das Aufspüren möglicher Fehler an der Reihe, die sich beim Parallelisieren von Anwendungen ergeben können. Das Beispiel, das Steve hierfür verwendet, ist eine Matrizenmultiplikation. Also nichts Spektakuläres. Hierfür steht in Visual Studio 2010 eine Art Thread Checker parat, der eine Anwendung analysiert und das Ergebnis grafisch aufbereitet. Dazu gehört die CPU-, Core- und Threads-Auslastung.

Die Session beginnt mit einer Folie, die all das zeigt, was Intel in Sachen High Performance Computing tut.

Folie 2 beschäftigt sich mit der Frage, welche Dinge zu berücksichtigen sind, um das Optimum aus seiner Anwendung zu holen. Dazu gehören die Wahl der richtigen Algorithmen, der passenden Programmiersprache und Compiler und natürlich die Frage nach den passenden Software-Tools, mit denen sich Anwendungen optimieren lassen.

Mit Fragen der Portabilität und der Produktivität sollten sich Entwickler ebenfalls beschäftigen. Auch hier geht es um Dinge wie Programmiersprachen, Tools, Betriebssysteme etc.

Jetzt dreht es sich um das Thema Skalierung und was getan werden muss, um eine Beschleunigung der Anwendungen zu erhalten, die sich an der Zahl der vorhandenen Prozessorkerne und Hardware-Threads orientiert.

Ok, jetzt wird’s interessanter. Der Intel-Kollege spricht über die vorhandenen Entwickler-Tools, die Intel bereit hält. Natürlich ist die Rede von Parallel Studio für C/C++-Entwickler, aber auch von Workstation-/Server- und HPC-Tools wie VTune Performance Analyzer, Intel TBB und mehr.

Wer übrigens glaubt, dass Intel sich nur der Windows-Welt verpflichtet fühlt, der irrt. Der Chiphersteller bietet ebenso Software-Tools für die Linux- und Mac-Entwickler dieser Welt.

Eine sehr schöne Folie: die Unterschiede zwischen Task- und datenbasierter Parallelprogrammierung.

Natürlich darf Parallel Studio nicht fehlen. Es geht also um Parallel Advisor, Parallel Composer, Parallel Inspector und Parallel Amplifier.

Vier Schritte, um eine serielle programmierte Anwendung zu parallelisieren:

1. Der Wechsel zum Intel Compiler verbessert ohne direkten Eingriff in den Code die Laufzeit der Anwendung.

2. Die Vektorisierung des Sourcecodes mithilfe von SIMD-Befehlen.

3. Die Implementierung von Intel-MKL-Code.

4. Automatische Parallelisierung mithilfe von OpenMP und andere Techniken.

Ein wenig Zukunftsaussichten gehören natürlich auch dazu: Intel wird seine Tools weiterentwickeln und damit sicher stellen, dass zukünftige Plattformen mit zukünftigen Anwendungen weiterhin skalieren. Dazu gehören unter anderem Weiterentwicklungen basierend auf Cilk++ und Ct.

Am Schluss gibt es noch ein paar Surftipps: Intel Software Network und whatif sollten Parallelprogrammierer auf jeden Fall kennen. Und natürlich das Software Dev Blog. Aber das stand leider nicht auf der Folie …

Aspekt #1: Single-Core-Maschinen werden immer mehr von Multicore-Rechnern abgelöst. Das hat damit zu tun, dass sich der CPU-Takt nicht weiter erhöhen lässt.

Problem #1: 3D-Game-Programmierung ist nicht trivial, weder sequenziell noch parallel. Was schon geschieht ist ein zeitversetztes “Update World” und “Rendering” (z.B. auf der Xbox 360).

Hoffnung #1: Viele Dinge bei der 3D-Programmierung lassen sich parallelisieren, z.B. Rendering, Physics, KI, Particles.

Herausforderung #1: Wie verteile ich das Spiel auf die notwendigen Threads und auf die vorhandenen Ressourcen (= Core)?

Parallele 3D-Programmierung #1: Mach aus einzelnen Tasks – wie KI, Physics, Rendering, Update World – Subtasks!

Herausforderung #2: Definiere Abhängigkeiten der einzelnen Tasks!

Lösung #1: Intel TBB hilft Gaming-Entwicklern dabei, die anfallenden Tasks möglichst gut auf die vorhandenen Cores zu verteilen. Hierzu bedient sich Intel TBB eines Thread Pools, der für jeden Task einen eigenen Thread bereit hält.

Analogie #1: Beim Verwalten von Tasks geht es genauso zu wie im Supermarkt: Sobald ein Task-Queue frei wird (=Kasse), wird ein bereits wartender Task in eine freie Queue verschoben ( =Task-Stealing).

Lösung #2: Die “Größe” einer Task wird vom Task Partitioner bestimmt, um ein Load Imbalancing zu vermeiden.

Lehre #1: Wenn mehr Game Designer mehr über parallele Programmierung und deren Grenzen/Möglichkeiten wüssten, würden sich die Spieleprogrammierer ein gutes Stück leichter tun.

Ausblick #1: Larrabee wird eine Manycore-GPU-Lösung sein, die wohl Ende nächsten Jahres auf den Markt kommen wird.

Ausblick #2: Eines Tages werden CPUs und GPUs verschmelzen und zu einer leistungsfähigen Einheit mutieren.

Ausblick #3: OpenCL wird die Programmiermethoden verändern (und hoffentlich verbessern).

Die CCR ermöglicht ein neues Programmiermodell für parallel laufende Anwendungen. Ein sehr schöner Ausspruch von Ralf lautet übrigens: “Vergesst Threads!”, da Threads synchronisiert werden müssen, was Ralf nicht wirklich mag. Um das besser verdeutlichen zu können, schreibt er in Echtzeit verschiedene kleinere Programme. Sehr schlau!

Das Besondere an der CCR ist das Warteschlangenprinzip: Jeder Befehl oder jedes Datum wird im Hintergrund aus der Warteschlange ausgelesen und verarbeitet, sobald eine Ressource frei ist. Damit müssen keine expliziten Threads erzeugt und wieder beendet werden, da sich die CCR automatisch darum kümmert. Hierfür steht die DispatcherQueue-Klasse zur Verfügung.

Die CCR erlaubt sowohl den Einsatz des Standard-Threadpools als auch eigene Threadpools auf Dispatcher-Basis.

Folgende Elemente kommen zum Einsatz:

• Parallele Erweiterungen für LINQ = PLINQ

• Schleifen parallelisieren: Die hierzu gehörige Klasse heißt System.Threading.Parallel. Schleifen werden auf mehrere Threads aufgeteilt werden, aber nur, wenn die einzelnen Schleifendurchläufe unabhängig voneinander sind. Dabei müssem die Indezies alle gleich sein. Am Ende der Schleife werden alle Threads synchronisiert. Fazit: Schleifenparallelisierung lohnt sich nur bei komplexen und großen Schleifen! Wichtig ist auch die richtige Verteilung einer Schleife auf die vorhandenen Prozessorressourcen. Dies gelingt, indem die einzelnen Schleifendurchläufe in kleinen Portionen verarbeitet werden.

• Aggregationen: Hierbei geht es um das Zusammenfassen von Ergebnissen. Dabei ist Locking meist erforderlich. Zwischenwerte werden über sogenannte ThreadLocateState weitergegeben. Der Ablauf sieht folgendes vor: Initialisierung, Zwischenspeichern der einzelnen Thread-Ergenisse und das abschließende Zusammenführen der Zwischenwerte inklusive Locking. Übrigens: Aufgrund des Zusammeführens der einzelnen Thread-Zwischenergebnisse kann ist bei der parallelen Ausführung zu Rundungsfehlern kommen und das Ergebnis weicht vom sequentiellen Programm ab.

• Codeblöcke parallelisieren: Hier kommt die Invoke-Methode zum Einsatz.

• Die Task-Klasse: Diese funktioniert ähnlich wie die ThreadPool-Klasse und haben dieser gegenüber wesentliche Vorteile: Sie lassen sich mit wait() synchronisieren und abbrechen. Interessant an dieser Task-Klasse ist die Tatsache, dass dahinter ein spezieller Thread-Pool steckt, der deutlich schneller als der Standard-Threadpool arbeitet.

• Die Future-Klasse: Sie ist abgeleitet von der Task-Klasse und ermöglicht die asynchrone Berechnung von Daten. Dabei wird auf Daten, die noch berechnet werden, automatisch gewartet oder das Endergebnis sofort ausgegeben. Die Future-Klasse eignet sich übrigens dazu, die Bedienoberfläche von Hintergrundberechnungen zu entkoppeln und damit die Anwendungen performanter zu machen.

• Concurrent Exceptions: Im Gegensatz zu sequentiellen Anwendungen können in parallelisierten Applikationen zu einer bestimmten Zeit mehrere Exceptions ausgeworfen werden. Hierfür ist natürlich ein anderer Exception-Mechanismus erforderlich. So müssen zum Beispiel im Falle einer Exception mehrere Threads gleichzeitig angehalten werden.

• Synchronisierung: Hierfür sind diverse Klassen im .NET-Framework vorhanden wie Lazyinit und WriteOnce.

Tipps und Tricks:

• Bei Parallel.For und Parallel.ForEach muss die (Anzahl der Durchläufe * Dauer) auf jeden Fall groß genug sein (beispielsweise schlägt bei der Matrix-Multiplikation die Parallelisierung erst bei sehr großen Matrizen voll durch).
• Nur äußere Schleifen parallelisieren wegen der Abhängigkeiten der Variablen
• Amdahl’s Gesetz berücksichtigen

• Statisches Threading birgt vor allem ein Problem: Es gibt statische Variablen, die von mehreren Threads gleichzeitig schreibend genutzt werden können.

• Threading mit instanzierten Klassen: Jeder Thread hat seine eigene Instanz, also zum Beispiel seine eigenen Variablen, was natürlich ein wenig mehr Ressourcen kostet.

• Steuerung von Threads: Hierbei geht es um die Priorisierung von Threads sowie das Starten, Pausieren und Stoppen von Threads. Die Herausforderung ist hier der jeweils richtige Zeitpunkt, ein Thread zu manipulieren. Außerdem muss man feststellen können, ob ein Thread gewollte beendet wurde. Dies kann per Bool’scher Variable erreicht werden.

• .NET-Threadpool: Der Pool soll ein einfaches Arbeiten mit mehreren Threads ermöglichen. Diese Threads “leben” meist relativ lang oder werden regelmäßig wiederkehrend benötigt. Es gibt eine maximale Anzahl an Threads innerhalb eines Pools. Wir ein Pool-Thread 30 Sekunden nicht benötigt, wird der Thread aus dem Pool entfernt. Schwierig dabei kann auch sein, dass ein neuer Pool-Thread erst nach einer halben Sekunde erzeugt wird, wenn kein laufender Thread in dieser Zeit beendet wird. Und: Jeder Prozess hat seinen eigenen Thread-Pool.

• Asynchrone Methoden: Einzelne Aufgaben werden in eigenen Threads ausgeführt. Die hierzu benötigten Methoden heißen BeginInvoke und EndInvoke. Allerdings sind diese Methoden kaum sinnvoll anwendbar.

• BackgroundWorker: Besteht aus drei Klassen: DoWork, ProgressChanged und ReportProgress.

• Synchronisierung: Im .NET-Framework gibt es Klassen für die Synchronisierung von Objekten.

• Atomare Anweisungen: Viele Befehle dürfen nicht unterbrochen werden. Daher stellt die Interlocked-Klasse sicher, das Grundbefehle vollständig ausgeführt werden, wenn mehrere Threads auf die Variablen zugreifen können: Increment/Decrement, Exchange, CompareExchange, Read (new), Add (new). Dies ist zum Beispiel für Sortieralgorithmen wichtig.

Zunächst geht es um echte Basics wie Multithreading mit Single- und Multicores. Fakt ist: Multithreading allein bringt gar nichts, dafür sind mehrere Prozessoren und die Zerlegung eines Programms in parallel zu verarbeitenden Bereiche notwendig.

Eine weitere Herausforderung sind Latenzzeiten, die sich aus asynchroner Prozessorverarbeitung ergeben. Das lässt sich mithilfe einer Kombination aus Multithreading und Multitasking auf mehreren Prozessoren optimieren.

Es gilt aber zugleich, den Durchsatz zu erhöhen. Dies gelingt ausschließlich auf Multicore-Systemen.

Es gibt ein grundsätzliches Problem bei der Parallelverarbeitung: den Zugriff auf gemeinsame Ressourcen. Diese Herausforderung meistern Zugriffskontrollen mithilfe explizierter Sperren. Hierfür sperren zum Beispiel einzelne Tasks gemeinsamen Speicher. Allerdings müssen die Zeitspannen und die Granularität dieser Sperren genau passen. Ein große Gefahr hierbei sind übrigens mögliche Deadlocks, die gerade bei parallel programmierten Anwendungen erst zur Laufzeit auftreten. Deadlocks lassen sich durch dieselbe Sperrreihenfolge vermeiden.

Jetzt redet Bernd über Data Races, die immer dann entstehen, wenn mehrere Threads auf dieselbe Ressource wie eine Variable schreibend zugreifen. Und das ist leider nicht vorhersehbar, da der schnellere Thread meist “gewinnt”.

Abschließend geht Bernd noch auf das Gesetz von Amdahl ein. Das hat mit dem Aspekt zu tun, dass die meisten Anwendungen nicht vollständig parallelisiert werden können bzw. sollen. Daher ist die Temposteigerung von seriellen Programmen, die parallelisiert werden, meist nicht optimal. Und das bedeutet laut Amdahl, dass der sequenzielle Teil einer Anwendung maßgeblich für die Temposteigerung zuständig ist.

Eine weitere Einschränkung bei der Geschwindigkeitssteigerung sind limitierende Faktoren wie das Erzeugen und Zerstören von Threads, Cache-Synchronisierungen und so fort. Die Erzeugung eines Threads dauert zum Beispiel so lang wie die Addition von 1.000 Integer-Zahlen. Abhilfe schaffen Threadpools, mit deren Hilfe ein Thread einmal erzeugt wird und dann immer wieder zur Verfügung steht. Wichtig ist aber auch die Granularität der Threads, damit die vorhandenen Ressourcen optimal genutzt werden.

Fazit: Es gibt je nach Rechendauer und -aufwand einen optimalen Parallelisierungsgrad. Und Threadpools helfen, parallelisierte Anwendungen zu beschleunigen.

Den Anfang macht Rami Radi von Intel, der die Einführungsrede hält und die Anwesenden auf das Thema Multicore einstimmen will.

Rami beginnt seinen Vortrag mit Hardware, nicht mehr Software. Namentlich spricht er über den Core i7-Prozessor, der ja im höchsten Maße multithreading-tauglich ist. Core i7 verarbeitet nämlich pro Prozessorkern zwei Threads simultan.

Die nächste Folie zeigt die ganze Vielfalt der Intel-Entwicklertools, über die ich hier schon ausführlich berichtet habe, also über Compiler, VTune etc.

So, jetzt wird’s ernst. Rami spricht über die Parallelprogrammierung im .NET-Umfeld, was seiner Meinung nach nicht einfach ist (wären wir sonst hier?). Zu den Herausforderungen gehören unter anderem falsch genutzter Speicher, zu viele und zu wenige Threads, gemeinsam genutzte Speicherbereiche, Load Balancing und viele andere. Wie gut, dass es für diese “Issues” die passenden Tools gibt wie den VTune Performance Analyzer.

Aber es gibt laut Rami auch genug Fälle, in denen parallelisierte Anwendungen langsamer laufen als serielle. Das hat diverse Gründe: Der serielle Code nimmt immer noch zu viel Raum ein, die kritischen Pfade sind nicht vernünftig parallelisiert oder die Speicherbandbreite reicht nicht aus.

Die nächste Folie zum Thema .NET-Konstrukte wirkt auf den ersten Blick ein wenig überfrachtet. Zum Glück will sich Rami auf die wirklich wichtigen Aspekte konzentrieren. Dazu gehören Thread-Pools. Rami zeigt ein kleines Beispiel anhand einer kleinen Fotoverwaltung, die in C# geschrieben ist.

Der Vorteil von Thread-Pools ist in diesem Fall, dass nicht ein, sondern zwei oder mehr Bilder gleichzeitig aus der SQL-Datenbank ausgelesen werden können, die die Bilder aufbewahrt. Der Trick hierbei ist übrigens, die Thread-Parameter in die For-Schleife zu packen. Außerdem muss ein Wait-Signal eingebaut werden, damit die Anwendung am Ende weiß, dass alle Bilder angezeigt worden sind. Darüber hinaus ist ein Lock-Befehl einzufügen, der die SQL-Zugriffe synchronisiert.

Interessant: Innerhalb des .NET-Umfelds kann nativer Code eingesetzt werden, um leistungsfähige Bibliotheken zu nutzen.

Jetzt gibt’s noch ein paar nützliche Tipps, mit denen man multithread-optimierten Code noch besser machen kann. Dazu gehören das Auslesen der vorhandenen Prozessorressourcen, das Zusammenfassen mehrerer Funktionen zu einem einzigen Thread, das Cachen von häufig benutzen Daten und das Benutzen von parallelen Datenbankverbindungen.

Schließlich gibt es noch eine kleine Einführung in VTune, mit dem sich Anwendungen prima analysieren lassen.

Status quo aus Intel-Sicht sind die HPC-basierten Tools der Gegenwart, die permanent weiterentwickelt werden. Daneben wird es sehr bald (wohl im Mai) Parallel Studio geben für den Mainstream-Entwickler. Und drittens sind die vorhandenen Tools einer ständigen Evolution unterworfen (so kommt ein verbesserter Compiler irgendwann im Juni auf den Markt).

Die Evolution des Parallel Studio umfasst folgende Dinge:

• der Parallel Advisor wird wichtiger Bestandteil der Suite
• beste Kompatibilität mit Windows 7 und Visual Studio
• Unterstützung der nächsten Microsoft Concurrency Runtime
• Ergänzungen (was immer das bedeutet)

Den dritten Teil seines Vortrags leitet James mit einem Traum ein:

If you focused on “data parallel programming”, could you make it easier for the program to be deterministic and scale?

Die Antwort lautet natürlich “Yes” und mündet in der Vorstellung des Ct-Projekts, das Ende 2009 eine Beta-Version eines neuen Produkts gebären soll. Das Thema ist die datenbasierte Parallelprogrammierung unter C++. Die Hauptmerkmale sehen wie folgt aus:

• eine höchst abstrahierte, beschreibende Programmiersprache, die nicht mehr in Aufgaben “denkt”
• hoch skalierend
• C++ wird um neue Templates erweitert (vergleichbar mit Intel TBB). Es sind keinerlei Änderungen an den bekannten Compilern erforderlich.

Ct wird beispielsweise die Programmierung von Bild- und Videobearbeitungstools erheblich vereinfachen, da nicht mehr sämtliche Varianten der datenorientierten Programmierung berücksichtigt werden müssen (Threading auf SSE- und einer höheren Ebene). Die Beschleunigung mittels Ct geschieht quasi im Hintergrund und entlastet den Programmierer bei seiner Arbeit.

Ct wird also die parallele Programmierung von datenbasierten Anwendungen deutlich vereinfachen und eines Tages in sämtlichen Intel-Softwaretools integriert sein.

Ein sehr schöner Einstieg in das Thema Tuning ist folgendes Zitat: “Ich weiß, wie ich vier Pferde dazu bringe, einen Wagen zu ziehen. Wie aber geht das mit 1024 Hühnern?” Das ist eine wirklich passende Analogie zur Optimierungsarbeit beim parallelen Programmieren. Denn es gibt so viele Fallen, in die man beim Multithreading tappen kann: nicht-skalierender Code, Deadlocks oder Data Races zur Laufzeit und vieles mehr.

Dafür gibt es den Parallel Amplifier, der Flaschenhälse findet, die Skalierbarkeit der Anwendung ermittelt und mehr. Es hilft also Entwicklern und Programmierern, die parallele Struktur und das parallele Verhalten ihrer Anwendung besser zu verstehen.

Wie schon der Composer und Inspector, integriert sich Parallel Amplifier in Visual Studio und findet folgende Probleme:

• Wo verbraucht meine Anwendung die meiste Zeit?

• Wann gehen die Prozessoren in den Idle-Modus?

• Wo gibt es ungewollte Wartezeiten?

Sobald Amplifier die möglichen Fehler gefunden hat, lassen sich die entsprechenden Quellcode-Stellen per Mausklick öffnen und auf die Fehler hin überprüfen.

Parallel Amplifier findet aber auch Unter- und Überschäftigung der vorhandenen Prozesorkerne, zeigt also sehr anschaulich, in welchem Umfang die Ressourcen genutzt werden.

Praktisch ist auch die Vergleichsfunktion, die es ermöglicht, die Ergebnisse zweier Durchläufe grafisch darstellen zu lassen. Also vor und nach der Optimierung und deren Auswirkung auf die Ausnutzung der Ressourcen.

Jetzt folgt eine Livedemo, die den Amplifier präsentiert. Und auch hier muss ich leider sagen, dass sich das geschriebene Wort nicht dafür eignet, das Gesehehene vernünftig zu beschreiben. Aber ich versuche auch in diesem Fall, etwas Anschauliches nachzuliefern. Interessant dabei ist die Tatsache, dass der Amplifier die EXE-Datei zur Laufzeit analysiert und anschließend innerhalb von Visual Studio die Ergebnisse darstellt. Das macht das Aufspüren der betreffenden Quellcodestellen ziemlich einfach.

Überraschend war übrigens der Wechsel des Compilers, um in diesem Anwendungsfall eine spezielle Bibliothek nutzen zu können. Die Laufzeit reduzierte sich von 15 Sekunden auf unter eine Sekunde. Dies ist auf den Intel-C++-Compiler zurückzuführen, der diese Bibliothek bereithält und die Laufzeit dramatisch verringert.

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.

Ein schöner Nebenaspekt des Parallel Inspector ist dessen Compiler-Unabhängigkeit: Man kann also sowohl den Intel-C++- als auch den Microsoft-Compiler oder jeden anderen kompatiblen Compiler verwenden.

Sehr hübsch: Je nach gewünschter Intensität lässt sich der Inspector-Test (Speicher oder Threading) mithilfe eines virtuellen Zeigers einstellen. Das macht die Wahl des passenden Tests sehr intuitiv.

Die abschließende Demo ist wirklich sehr anschaulich und zeigt die einfache Handhabung des Inspectors aus Visual Studio heraus. Leider lässt sich das an dieser Stelle nur schlecht darstellen. Ich überlege mir aber etwas, wie ich das nachträglich zeigen kann. Versprochen!

Fazit: Parallel Inspector ist ein wirkliche gutes Tool, mit dem sich mögliche Threading- und Speicherprobleme identifizieren lassen, und das mit wenigen Mausklicks. Zudem geschieht dies aus der gewohnten Visual-Studio-Umgebung heraus.

Die ersten Multithread-Erfahrungen hat Nero mit seiner Brennsoftware vor vielen Jahren gemacht, was der Firma heute noch dabei hilft, neue Software-Titel für die aktuelle Hardware-Generation so zu schreiben, dass sie möglichst gut skalieren.

Nach einer ganzen Menge an marketinglastigen Infos wird’s endlich technisch. Zunächst geht es um die Frage, welchen Herausforderungen sich ein Entwickler gegenüber sieht, wenn er Multimedia-Software möglichst leistungsfähig schreiben will. Dazu gehört unter anderem Realtime-Encoding (und das natürlich parallel) – in möglichst vielen Datenformaten. Aber auch hoch komplexe Codecs, HD-Inhalte, große Datenmengen und DRM-/Sicherheitsaspekte stellen Herausforderungen dar.

Doch wie schafft es Nero, in Multicore-Dimensionen zu denken? Nun, hierfür sind laut Charly Lippoth neue Kenntnisse und ein neues Denken erforderlich. Dazu gehört beispielsweise die Erkenntnis, dass Funktionen möglichst gut auf den vorhandenen Prozessorkernen skalieren müssen.

Aber auch die Programmierung auf Maschinencode-Ebene hilft Nero beim Optimieren der Software, indem beispielsweise SSE-Befehle optimal eingesetzt werden. Ein weiterer Aspekt ist aber natürlich der Einsatz der richtigen Tools.

Ein gutes Beispiel für effizientes Multithreading sind Audio- und Videocodecs, bei denen es ein hohes Parallelisierungspotenzial gibt. Das beginnt beim Videoscaling und endet bei der Transformation von HD-Content in 2K- oder 4K-Inhalte.

Folgende Nero-Anwendungen sind parallelisiert: Move It, LiquidTV, Recode, 1080p-Wiedergabe und Mediamanagement.

Nero setzt auf Intel-Tools wie VTune Performance Analyzer und Parallel Inspector, mit deren Hilfe die aktuelle Bluray-Software verbessert werden konnte, da es in der Vergangenheit Probleme beim Synchronisieren von Daten und Threads gab.

Die abschließende Recode-Demo zeigt, was mit einer parallelisierten Anwendung möglich ist: HD-Videocontent lässt sich auf einem Core-i7-System in Echtzeit in ein portables Format konvertieren. Damit gelangen hochaufgelöste Inhalte innerhalb kürzester Zeit auf iPod, iPhone und Co.

Fazit: Nero lernt jeden Tag dazu und will und wird in Zukunft verstärkt auf Parallel Studio, Threading Building Blocks und die Task Parallel Library setzen. Und Entwickler und Programmierer kontinuierlich weiterbilden, für möglichst skalierende Anwendungen.

Dann durfte einer der Chefentwickler noch etwas zu seinen Erfahrungen mit Parallel Studio erzählen. Er zeigte sich sehr angetan von diesem Tool hinsichtlich des Aufspürens von Speicherproblemen zur Laufzeit. Aber: Der generierte Overhead ist nicht ganz trivial und muss noch verringert werden. Und an der Geschwindigkeit muss auch noch geschraubt werden. Aber darum nennt sich das Ganze auch noch “Beta” …

Den Anfang macht eine Demo mithilfe einer Mandelbrot-Berechnung, die auf einem Prozessor und auf 24 Prozessorkernen läuft – und das signifikant schneller! Das überrascht nicht wirklich …

Eines der Hauptprobleme beim parallelen Programmieren ist laut Eric – und das ist nicht nur seine Ansicht – die bestehende Ausbildung der aktuellen Studentengeneration, da diese nicht entsprechend ausgebildet werden.

Die Integration von Intel Parallel Studio in Visual Studio 2010 hat laut Eric diverse Vorteile: Load Balancing und Task Scheduling geschehen sehr ausgewogen. Außerdem werden die vorhandenen Ressourcen wie Intel TBB und Microsoft PPL optimal gemeinsam genutzt.

Eine weitere Demo zeigt den Unterschied zwischen LINQ und PLINQ, mit deren Hilfe ein Datensatz in einer Datenbank gefunden werden kann. Überraschung: Dank der Parallelisierung von PLING wird derselbe Datensatz in vier Sekunden identifiziert anstatt in 27 Sekunden auf LINQ-Basis.

Interessante Aussage: “The manycore is a disruption for developers but also a high opportunity!”

Eric stellt jetzt letztlich dieselbe Fragen wie James Reinders: Wie können Entwickler parallel entwickeln? Wie können sie dabei unterstützt werden, dies effizient und skalierend zu tun? Und wie können Entwickler möglichst einfach Programme erstellen und testen?

So, jetzt geht es um Visual Studio 2010. Eric stellt PLINQ im Detail vor.

Ein weitere Demo zeigt die Lösung des Monte-Carlo-Problems mithilfe einer parallelen Anweisung, die sich in wenigen Sekunden in den Sourcecode einfügen lässt. Und tatsächlich: Dank der Parallelisierung steht die Lösung auf einer Dualcore-Maschine nach knapp sieben Sekunden zur Verfügung (im Vergleich: Im seriellen Modus dauerte die Berechnung rund zwölf Sekunden).

Die Concurrency Runtime zeichnet sich durch zwei Hauptmerkmale aus: Load Balancing Scheduler (LBS) und Dynamic Resource Management (DRM).

Ohne große Umschweife kommt James auf Parallel Studio zu sprechen. Das Feedback der Beta-Tester ist wohl sehr gut. Gleichzeitig ist es aber wichtig, so Reinders, dass die Segmentierung der Tools klar ist: Parallel Studio wird in Zukunft den Mainstream der C++-Programmierer adressieren, während sich die anderen Softwarewerkzeuge eher an Highend-Entwickler wenden – unter anderem an diejenigen, die nicht in C++ unter Windows programmieren.

Klar, dass James auch über geplante Produkte redet. Zum einen über die nächsten Multicore-Prozessoren, die ein Vielfaches an Threads wie die aktuellen CPUs parallel verarbeiten können. Aber auch Larrabee kommt kurz ins Gespräch.

Jetzt liegt gerade eine interessante Folie auf, die das ganze Dilemma vieler Programmierer aufzeigt: Mehr Prozessorkerne bedeuten nicht zwangsläufig mehr Leistung, da die Taktraten nicht weiter nach oben gehen und aus diesem Grund die Anwendungen für parallel ablaufende Threads optimiert werden müssen. Und zwar so, dass die Software auch dann skaliert, wernn die Hardware nicht nur vier Prozessorkerne bietet, sondern 8, 16, 32 oder mehr.

Auf die Bühne kommt – Intel Threading Building Blocks, übrigens Teil des Parallel Studio.

“Tools must help” – sowohl in vergangenen Zeiten als Hilfsmittel als auch heute und morgen für korrekt und skalierend programmierte Anwendungen.

Ok, jetzt wird’s parallel: James spricht über Parallel Studio und stellt die vier Stufen der parallelen Programmierung vor: Design, Programmierung/Testen, Verifizierung, Tuning.

Design: Hiefür wird es eines schönen Tages den Parallel Advisor geben, der aber zunächst nicht Bestandteil von Parallel Studio sein wird.

Programmierung/Testen: Hierfür gibt es Parallel Composer, der verschiedene Tools in sich vereint: OpenMP 3.0, C++-Compiler, Parallel Debugger Plug-in, Integrated Performance Primitives, Threading Building Blocks, Lambda-Funktionen etc.

Verifizierung: Parallel Inspector kümmert sich um die Fehler und Bugs, die sich bei der parallelen Programmierung eingeschlichen haben. Letztlich ist der Inspector eine verbesserte Variante des Thread Checker, den es ja schon eine ganze Weile gibt. Was der Inspector besser macht ist das Aufspüren von Speicherproblemen, und das natürlich zur Laufzeit. Daneben findet Inspector Fehler in Multithreading-Segementen wie Dead Locks Data Races – und gleich die passenden Programmzeilen dazu.

Tuning: Parallel Amplifier spürt ähnlich wie VTune und Thread Profiler Flaschenhälse und Hotspots innerhalb einer parallel programmierten Anwendungen auf. Hierfür kann man sich beispielsweise seine Software benchmarken, indem man die vorhandenen Funktionen unterschiedlich anordnet und mithilfe des Amplifier herausfindet, welche Anordnung am besten ist.

Jetzt kommt James doch noch mal auf Parallel Advisor zu sprechen, der im Laufe des Jahres allen Studio-Anwendern zur Verfügung stehen wird. Dieses Tool wird Entwicklern dabei helfen, den besten Ansatz für die Parallelisierung seiner Anwendung zu finden.

Auch ein wichtiges Thema ist die geplante Version von Microsoft Visual Studio 2010, die eine Menge an Parallelismus eingebaut haben wird. Interssant an der Folie ist der Hinweis, dass Intel die Microsoft Concurrency Runtime in Zukunft unterstützen wird. Bisher ist es nämlich vor allem für .NET-Entwickler recht schwierig, Multithread-Code zu “überwachen”. Das betrifft hauptsächlich den Task Scheduler, der sich um das Verteilen der anfallenden Threads auf die vorhandenen Prozessoren kümmert.

Interessanter Einwurf eines anwesenden Teilnehmers: Warum sollte man nicht einfach auf Visual Studio 2010 warten, anstatt Parallel Studio einzusetzen? Antwort von James Reinders: Parallel Studio setzt auf OpenMP und hat vor allem mit dem Parallel Inspector ein Debugger-Tool “onboard”, das zur Laufzeit Data Races und Deadlocks finden kann!

Und jetzt noch zwei schöne Schlussworte:

C- und C++-Entwickler benötigen ALLE Parallel Studio!

Parallel Studio ist das absolut beste Tool für die parallel Programmierung!

• Was ist Parallel Studio?
• Intels zukünftige Pläne

Das erinnert mich gerade ein wenig an die Verleihung der bekannten Hollywood-Statue: Anwesende werden begrüßt, Special Guests werden erwähnt und kleine Geschichten werden ausgetauscht. Ein sehr launiger Auftakt für solch eine Veranstaltung …

Dann wird’s aber doch technisch und die geplanten Redner werden vorgestellt: Microsoft, Nero und Intel werden den heutigen Tag inhaltlich gestalten. Daneben wird das Intel Software Network vorgestellt, die Plattform für technische Informationen rund um Intel-Softwareprodukte. Goparallel.com wird kurz erwähnt sowie die MSDN-Verlinkung, die geplante Microsoft-Intel-Roadshow und diverse Veranstaltungen.

Jetzt gibt Christian ein kurzes Update in Sachen Parallel Studio und dass es sogar auf der weltweiten Marketing- und Sales-Konference im Januar Erwähnungen gefunden hat. Weitere Tools werden im Juni vorgestellt, die vor allem für Apple- und Linux-Entwickler interessant sein werden.

Ein Video lässt verschiedene Menschen zu Wort kommen (Citrix, Microsoft, Novell, Red Hat, Autodesk etc.), die Intel-Tools wie VTune Performance und Intel Compiler Analyzer in den höchsten Tönen loben.

Und jetzt heißt es: Bühne frei für James Reinders!

Für alle, die bisher noch nicht mitbekommen haben, was hier am morgigen Dienstag in der Geburtsstadt Mozarts im Namen von Intel stattfinden wird, folgt jetzt die ultimative Stichwortsammlung:

James Reinders, Obersoftwareguru bei Intel, wird zeigen, dass sich Multicore-Plattformen vom Nischendasein emanzipiert haben und im Massengeschäft angekommen sind. Und dass es für Softwareentwickler noch ein Menge zu tun gibt, um ihre oftmals sequenziell programmierten Anwendungen an die aktuellen und zukünftigen Prozessorgenerationen anzupassen, die es gerne parallel mögen.

Eric Vernié, Softwarevordenker bei Microsoft in Frankreich, macht sich dann daran, die gemeinsamen Anstrengungen von Intel und Microsoft in Sachen Multicore-Programmierung vorzustellen. Stichworte sind Visual Studio 2010 samt .NET 4.0 einerseits und Parallel Studio andererseits. Es wird aber auch um künftige Programmiersprachen wie F# gehen, die für noch mehr automatischen Parallelismus in Anwendungen sorgen sollen.

Charly Lippoth, Chefstratege der Nero AG, kommt anschließend zu Wort und wird über die Erfolgsgeschichte referieren, warum Nero-Software und Intel-Multicore-Plattformen wie der Core i7 so gut harmonieren und was seine Programmierer und Entwickler alles dafür tun mussten. Stichworte in diesem Zusammenhang sind VTune Performance Analyzer und Intel Compiler.

Nach soviel Übersichtsinfos geht es dann ans Eingemachte: Heinz Bast und Levent Akyil nehmen sich im Detail des Parallel Studios an. Stichworte hierbei sind Parallel Composer, Parallel Inspector und Parallel Amplifier. Da sollten eine ganze Menge Einblicke dabei sein.

Und was ist sehr beliebt am Ende solch einer Konferenz? Genau, ein Blick in die Glaskugel: Was kommt, was können wir noch alles erwarten, was wird in Zukunft benötigt. Das erledigt natürlich der Chef selbst: James Reinders wird also noch einmal die Bühne erklimmen und einen kurzen Ausblick verschaffen, was Parallel Studio noch alles zu bieten haben wird und was es mit dem Forschungsprojekt Ct auf sich hat.

Jetzt fehlt nur noch der Hinweis, den RSS-Feed des Software Dev Blogs zu abonnieren, oder?!

Ray Tracing zeichnet sich durch vier wesentliche Aspekte aus: Flexibilität, Qualität, Einfachheit und Robustheit.

Flexibilität: Auf Basis der Rasterisierung lassen sich unterschiedliche Perspektiven nur mit viel Aufwand darstellen. Vor allem dann, wenn die Zahl der darzustellenden Datenobjekte sehr groß ist. Ray Tracing ist hierfür viel besser geeignet. Aber: Rasterisierung ist schneller als Ray Tracing. Daher ist für akzeptables Ray Tracing leistungsfähige Hardware notwendig.

Qualität: Die erzielbare Bildqualität ist mit Ray Tracing deutlich höher als mit Rasterisierung. Dies betrifft vor allem Schatten, spiegelnde Flächen wie Wasseroberflächen etc. Doch wer braucht diesen Level an realistischer Bildqualität? Nun, vor allem Architekten, Produktdesigner, Animationsfilmer und natürlich Spieleentwickler.

Einfachheit: Die Implementierung einer Rasterisierung-Engine ist im Vergleich zu Ray Tracing deutlich einfacher, aber bei der Programmierung neuer Effekte haben Ray Tracer große Vorteile. So lassen sich bestehende und neue Shader-Effekte mit weniger Programmierzeilen in eine 3D-Anwendung implementieren.

Robustheit: Rasterisierungs-Implementierung sind meist nicht robust genug. Vor allem die Zunahme verschiedener Effekte innerhalb einer Szene überfordert Rasterisierungs-Engines zusehend. Dieses Problem lässt sich mit Ray Tracing recht einfach lösen. Das geht allerdings mit großen Anstregungen hinsichtlich der Render-Engines einher. Denn eines ist klar: Robuste 3D-Engines sind äußerst wichtig, da gerade beim Erstellen von 3D-Szenen etc. viel Zeit und damit viel Geld aufgewendet wird.

Der Saal ist gut gefüllt, die Themen scheinen also voll im Trend zu liegen. Als erster ist Mat Pharr dran, der sich bei Intel um das Thema Larrabee kümmert.

Matt beginnt mit einer kurzen Einführung: Fließpunkt-Arithmetik ist mittlerweile ausreichend vorhanden und 3D existiert in Software und nicht mehr ausschließlich in Hardware. Das bedeutet, das Prozessoren immer flexibler werden, vor allem, wenn man an neue Anwendungsgebiete wie 3D-Darstellungen denkt.

Ein kurzer Rückblick: 2001 war die Darstellung von 3D-Daten sehr gebunden an die Hardware. Mittlerweile kann das dank der enormen Rechenleistung vollständig in Software geschehen.

Was ist Larrabee? Letztlich der Zusammenschluss einer Multicore-CPU und einer programmierbaren, parallelisierten Grafikeinheit.

Schöner Versuch: Was bringt die Erhöhung der verfügbaren Prozessorkerne um den Faktor fünf in Sachen Rechenleistung? Den Faktor 160!

Das Larrabee-Blockdiagramm zeigt vor allem eins: Es gibt einen gemeinsamen L2-Cache, auf den sämtliche Prozessorkerne zugreifen.

Die Lehre der nächsten Folie: Sowohl das Berechnen einer 3D-Szene als auch Rendern dieser fertigen Szene sind in höchstem Maße parallelisierbar. Daher ist der Rasterisierer von Larrabee natürlich bestmöglich parallelisiert.

Dank Larrabee lässt sich in Zukunft die komplette 3D-Berechnung in Software realisieren und so der komplette 3D-Workflow als Software-Pipeline abbilden. Das macht Spezialhardware wie Grafikkarten selbst für aufwendige 3D-Berechnung künftig überflüssig.

Larrabee versteht sich auf das unmittelbare Umwandeln zwischen verschiedenen Datenformaten. So lassen sich FP32-Daten problemlos in FP16-Daten konvertieren, falls dies notwendig ist.

Problem heutige 3D-Spiele: Es gibt keinen ausgewogenen Workload, da jedes Game seinen eigenen Schwerpunkt hat in Sachen Alpha Blending, Pixel Shading, Rasterisierung, Vertex Shading etc. Mit Larrabee wird sich dieses Problem einfacher lösen lassen, da Larrabee sehr viel flexibler mit unterschiedlichen Workloads umgehen kann.

Die GPU-Programmierung wird sich mit Larrabee vollständig ändern: Sie wird parallel programmierbar!

Ziel der Intel-Präsenz auf der TechEd sind gleich mehrere Dinge: Zum einen geht es um das große Thema paralleles Programmieren innerhalb einer Multiprozessor-Umgebung. Software-Entwickler, die bis dato mit Intel-Tools für diese Zwecke noch nicht so viel zu tun hatten, sollen auf diesem Weg lernen, wie aus single-threaded Software-Code Multithread-Anwendungen werden und welche Werkzeuge Intel hierfür bietet.

Die anvisierte Zielgruppe ist ziemlich eindeutig: Windows-Entwickler, die in C++ programmieren und dies möglicherweise in einer Visual-Studio-Umgebung tun. Anwendungsseitig sollen Entwickler angesprochen werden, die vorzugsweise eigene Programme in Sachen Bildbearbeitung, Signal Processing, Simulation, Medizintechnik, Gaming und Windows-Clustering programmieren.

Aber auch ein brandneues Tool wird in Barcelona ein wichtiges Thema sein: Mit Intel Parallel Studio wird es ab dem zweiten Quartal 2009 ein spezielles Plugin für Microsoft Visual Studio geben, das den Software-Programmierern dieser Welt dabei helfen soll, ihre C++-basierten Windows-Anwendungen zu parallelisieren und somit für den Multicore-Einsatz zu optimieren.

Apropos: Aktuell sucht Intel Beta-Tester für sein Parallel Studio, für das sich interessierte Visual-Studio-Entwickler bewerben und so zu einer erfolgreichen Umsetzung des Plugins beitragen können.

Liveblogging-Tipp: Wir werden mit Laptop und Videokamera ausgestattet den langen Weg nach Barcelona antreten und live über die interessantesten Vorträge berichten, spannende Interviews mit spannenden Menschen führen und natürlich die Intel-Tools ein wenig näher beleuchten. Am besten merken Sie sich den Termin schon mal vor und nehmen den Software Dev BLOG in ihre RSS-Liste auf. Damit Sie auch ja nichts verpassen …