Azure Cloud-Sicherheit

Sessions der BASTA! 2012 im Heft! www.componentsource.com ActiveReports 7 ab 758 inkl. MwSt NEUES PRODUKT Die schnelle und flexible Reporting-Engine ist jetzt noch besser geworden. Neuer Seiten-Layout-Designer - bietet präzise Design-Tools für die komplexeste Form von Berichten z.b. Steuern, Versicherungen und Investitions-Formularen, etc. Mehr Steuerelemente - aktualisierte Tabellensteuerelemente, Barcode, Matrix und Kalender sowie Daten-Visualisierungs-Features windows.developer /update/2012/10 Deutschland 9,80 Österreich 10,80 Schweiz 19,50 sfr Mehr Anpassungsoptionen - neugestaltete Viewer- und Designer-Steuerelemente Meistgekauftes #1 ComponentSource Produkt - Ein komplettes Angebot mit Präsentations-Controls und Reporting-Lösungen für WinForms-, ASP.NET-, Silverlightund WPF-Anwendungen. Erwecken Sie Ihre Software mit intelligenten Touch-basierte Anwendungen zum Leben Nutzen Sie Ihre vorhandenen Entwicklungsfähigkeiten, um die wachsende Nachfrage nach überwältigenden touch-fähigen Apps auf allen Plattformen, einschließlich WinForms, WPF und ASP.NET, zu erschließen Stellen Sie sich Business-Anwendungen für die Windows 8 Metro Entwurfsästhetik neu vor Wende Sie anspruchsvolle Designs an oder kreieren Sie Ihre eigenen und integrieren Sie Ihre Unternehmensmarke Integrieren Sie Office-inspirierte und Business Intelligence-Dashboards in Ihr Design Lassen Sie Benutzer die Daten in überzeugender Weise ansehen und bearbeiten CodeRush hilft Ihnen, Ihre komplexe Code-Basis zu erstellen und zu verwalten, so dass mehr Zeit auf Ihrer Geschäftslogik fokussiert werden kann Wählen Sie eine einzelne Plattform oder erhalten Sie mehr mit Universal oder EnterpriseAbonnements Mehr über DXperience und preisgekrönte DevExpress-Produkte unter: www.componentsource.com/features/devexpress MonoTouch Professional ab 379 inkl. MwSt BEST-SELLER Leistungsstarke iphone- und ipad-apps mit C# und.net erstellen..net-kenntnisse zum Erstellen von Apps für iphone, ipod Touch & ipad nutzen Voller Zugriff auf alle nativen ios APIs bzw native Apps erstellen Jetzt mit leistungsstarkem Memory Profiler, Modultestsoftware Code gemeinsam für ios, Android und Windows Phone nutzen Windows 8. TFS. Xbox. WF 4.5. XAML. C++. PowerShell. NuGet. C#. Source Server DXperience DXv2 12.1 ab 1.424 inkl. MwSt NEUES PRODUKT Windows Azure Cloud-Sicherheit 32 Verfügbarkeit, Vertraulichkeit und Integrität Windows Azure Websites 16 Von kostenfrei bis hoch verfügbar IaaS oder PaaS? 23 Azure Virtual Machines & Cloud Services PowerShell NuGet Package Manager Team Foundation Server 2012 Teil 1: Beginning PowerShell eine Einführung 64 Funktionserweiterung in Visual Studio UI-Planung via Storyboard 1996-2012 ComponentSource. Alle Rechte vorbehalten. Alle Preise waren zum Zeitpunkt der Veröffentlichung dieses Dokuments korrekt. Online-Preise können sich aufgrund von Schwankungen und online angebotenen Preisnachlässen ändern. Hauptsitz in Europa ComponentSource 30 Greyfriars Road Reading Berkshire RG1 1PE Großbritannien Hauptsitz in den USA ComponentSource 650 Claremore Prof Way Suite 100 Woodstock GA 30188-5188 USA Hauptsitz in Japan ComponentSource 3F Kojimachi Square Bldg 3-3 Kojimachi Chiyoda-ku Tokyo Japan 102-0083 Vertriebs-Hotline: 0800 186 07 06 www.componentsource.com Zahlungen auf Rechnung und per Inlandsüberweisung auch gerne angenommen. www.windowsdeveloper.de 70 59

Parallelisierung in C++11. net-sprachen Teil 2: Going parallel with C++ Quellcode als Download auf www.windowsdeveloper.de Ein Muss für Skalierung Multi-Core, Vector-Unit und GPU moderne Hardware bietet heute mehr, als die meiste Software nutzt. Daher ist vielerorts Nachrüsten angesagt, Parallelisierung wird Pfl icht. Doch keine Angst, moderne Entwicklungswerkzeuge und Bibliotheken machen dies auch für C++-Programmierer zu einer durchaus zu bewältigenden Aufgabe. von Thomas Trotzki und Christian Binder Die Zeiten, in denen eine einzelne Anwendung das komplette Betriebssystem lahmlegen konnte, sind lange vorbei zu guter Letzt auch dank eines entsprechenden Parallelisierungskonzepts auf Systemebene. In Windows ist das seit Einführung von Windows NT der Fall. Mit NT 3.1 kamen im Jahr 1991 Processes und Threads sowie die Unterstützung des symmetrischen Multiprocessings. In den Folgeversionen kamen weitere Konzepte wie Fibers, Jobs und Thread Pools hinzu alles Dinge, die es uns Entwicklern einfacher machen sollen, die Multiprocessing-Fähigkeit des Systems zu nutzen. Das neueste Kind dieser Reihe: User Mode Scheduled Threads aus Windows 7. Im selben Zeitraum hat sich auch auf Ebene der Hardware einiges getan. Vor zwanzig Jahren waren bei PCs Systeme mit einer CPU und 33 MHz Taktrate angesagt. Damals wurde die Performanceverbesserung der Systeme nahezu ausschließlich mit einer Erhöhung der Taktrate gleichgesetzt. Physikalische Mehrprozessorsysteme gab es zwar, sie waren aber doch eher die Exoten. Somit konnte Parallelisierung zwar so man- Artikelserie Teil 1: Modern C++11 Teil 2: Going Parallel with C++ Teil 3: ALM for C++ www.windowsdeveloper.de 79

.net-sprachen. Parallelisierung in C++11 Listing 1 int _tmain(int argc, _TCHAR* argv[]) vector<int (*)[9]> v = get_sudoku_samples(); const int nfields = v.size(); for(int field = 0; field < nfields; field++) int (* sudoku) [9] = v[field]; int values = sudoku_getcount(sudoku); int solutions = sudoku_solve(sudoku, 0, 0); cout << field << " (" << values << "," << solutions << ")" << endl; delete [] sudoku; return 0; Listing 2 int _tmain(int argc, _TCHAR* argv[]) vector<int (*)[9]> v = get_sudoku_samples(); const int nfields = v.size(); task<void> *tasks = new task<void>[nfields]; critical_section cscout; for(int field = 0; field < nfields; field++) tasks[field] = task<void>([=, &cscout] () -> void int (* sudoku) [9] = v[field]; int values = sudoku_getcount(sudoku); int solutions = sudoku_solve(sudoku, 0, 0); cscout.lock(); cout << field << " (" << values << "," << solutions << ")" << endl; cscout.unlock(); delete [] sudoku; ); when_all(tasks, tasks+nfields).wait(); delete [] tasks; return 0; ches andere Problem lösen, Performancesteigerung gehörte aber nicht unbedingt dazu. Seit ca. fünf Jahren hat sich das grundlegend geändert, Hyperthreading und Multi-Core gibt es heute beim Discounter. Im Gegenzug dazu hat sich die Taktrate der Systeme nur noch eingeschränkt erhöht. Nicht mehr MHz und GHz zählen, sondern die Anzahl der Cores. Und wer davon profitieren möchte, der kommt an Parallelisierung eben nicht mehr vorbei. Das Problem: So richtig schick ist Multiprocessing mit dem klassischen Windows-API nicht unbedingt zu programmieren, sind doch Themen wie die Übergabe von Parametern und Synchronisierung recht schwierig umzusetzen. Und wenn wir in Richtung massive Parallelisierung auf einer GPU weiterdenken, dann sind wir in einer anderen Welt gelandet, die mit C++ eigentlich nichts mehr zu tun hat. Hier tut eine Neuerung dringend Not. Die Parallel Pattern Library (PPL) Für die.net-programmierer gibt es die Task Parallel Library (TPL), diese wurde in den letzten Ausgaben ausführlich vorgestellt. Für C++-Programmierer bietet Microsoft die Concurrency Runtime (ConcRT), die die Konzepte der TPL analog in die unmanaged Welt bringt. Sinn und Zweck dieser Bibliotheken ist die Abstraktion der Parallelisierung und damit eine Unabhängigkeit von den zu unterstützenden Windows-Zielplattformen. Werden auf der Zielplattform UMS Threads unterstützt, werden sie verwendet, andernfalls greift die Library auf herkömmliche Threads zurück. Die ConcRT besteht aus mehreren Teilkomponenten: Resource Manager: verwaltet Ressourcen wie Speicher und Prozessoren. Task Scheduler: stellt den Scheduler zur Verfügung, der die anstehenden Anforderungen auf die zur Verfügung stehenden Ressourcen verteilt. Parallel Pattern Library (PPL): bietet die beiden wesentlichen Aspekte parallele Schleifen und Tasks. Diese abstrahieren die Parallelisierungsmechanismen des Systems. Asynchronous Agents Library: bietet Unterstützung bei der asynchronen Bearbeitung von Datenblöcken. Im Wesentlichen ist es die PPL, die mit der TPL zu vergleichen ist. Resource Manager und Task Scheduler werden sie eher selten direkt verwenden, und auch die Agents Library wird deutlich weniger Anwendungsfälle finden. Lambdas Lambdas sind ein neues Sprachmerkmal in C++11 und wurden in der letzten Ausgabe ausführlich vorgestellt [1]. Sie spielen auch bei der Nutzung der PPL eine wesentliche Rolle, werden doch alle Thread-Prozeduren in der PPL durch Lambdas ausgedrückt. 80

Parallelisierung in C++11. net-sprachen Tasks, der einfache Weg zur Parallelisierung Im Gegensatz zum klassischen Win32 wird bei der Nutzung der PPL nicht unmittelbar von Threads gesprochen, sie sind lediglich eine wenngleich recht wichtige Umsetzungsoption für die Parallelisierung. Eine Task stellt eine elementare Ausführeinheit innerhalb der PPL dar und wird vom Task Scheduler der ConcRT verteilt. Bei dieser Verteilung berücksichtigt der Scheduler die auf dem Zielsystem zur Verfügung stehenden Ressourcen. Zur Veranschaulichung ein Beispiel: Sind zu einem konkreten Zeitpunkt weit mehr Tasks ausführbereit, als es physikalische Recheneinheiten gibt, so wird der Task Scheduler nicht für jede Task einen separaten System-Thread erstellen, sondern je nach Zielsystem die Tasks entweder sequenziell abarbeiten oder mehrere Tasks über UMS Threads zur Ausführung bringen. In den meisten Anwendungsfällen ist es tatsächlich so, dass wir Entwickler uns nicht um diesen Sachverhalt kümmern müssen und wollen. Die Einsatzszenarien für Parallelisierung sind vielfältig, Listing 1 zeigt eine kleine Codesequenz. Die Struktur des Codes bleibt erhalten, es wird nur Dekoration um die Schleife gebaut. Das Kernstück ist der Aufruf der Methode sudoku_ solve, die die Anzahl der möglichen Lösungen eines Sudoku-Rätsels liefert. (Hinweis: Für alle, die wissen wollen, wie Sudoku-Rätsel per Computer gelöst werden, steht der kleine Backtracking-Algorithmus als Download auf www.windowsdeveloper.de bereit) Diese Berechnung kann dauern, vor allem, wenn Sie, wie dargestellt, gleich mehrere Rätsel zu lösen haben. Mit der PPL wird die Parallelisierung recht einfach, betrachten Sie hierzu das nächste Code-Snippet in Listing 2. Die Struktur des Codes bleibt erhalten, es wird lediglich etwas Dekoration um die Schleife gebaut. Noch einfacher wird es durch die Verwendung der parallel_for-schleife, diese ist speziell für das gezeigte Szenario vorgesehen. Die Synchronisierung des Zugriffs auf gemeinsam genutzte Ressourcen im Beispiel anhand cout gezeigt wird ebenfalls durch Klassen der PPL unterstützt. Der Concurrency Visualizer Der Concurrency Visualizer hat bereits in Visual Studio 2010 Einzug gehalten. Er arbeitet mit der PPL zu- Anzeige

.net-sprachen. Parallelisierung in C++11 Abb. 1: CPU-Ausnutzung, parallel Abb. 2: Threads, parallel Abb. 3: Cores, parallel sammen und bietet eine recht anschauliche grafische Darstellung der Parallelisierung einer Anwendung. In Visual Studio 2010 wird der Cuncurrency Analyzer über Analyze Launch Performance Wizard gestartet, die Optionen werden im Dialog Performance Wizard auf Concurrency Visualize the behavior of a multithreaded application festgelegt. In Visual Studio 2012 hat der Concurrency Visualizer einen etwas exponierteren Eintrittspunkt erhalten und wurde bezüglich Geschwindigkeit deutlich optimiert. Hier erfolgt der Start über Analyze Concurrency Wizard Start with current Project. Die Arbeitsweise des Tools ist recht einfach: Während der Ausführung der Anwendung werden Profiling-Daten gesammelt, die anschließend ausgewertet und grafisch aufbereitet werden. Dabei liefert der Visualizer drei unterschiedliche Darstellungen, die im Folgenden anhand der parallelisierten Version des Sudoku-Solvers dargestellt werden. Die CPU-Ausnutzung unterscheidet sich deutlich zwischen sequenzieller und paralleler Ausführung. In Abbildung 1 ist auf den ersten Blick zu erkennen, wie die parallelisierte Version sich sofort nach dem Start auf alle logischen Kerne verteilt, die Gesamtlaufzeit beträgt hier ca. 5 s. Das analoge Diagramm für die sequenzielle Ausführung weist hingegen nur einen, dafür um einiges längeren Balken auf (12 s). In der Thread-Darstellung in Abbildung 2 wird deutlich, was die PPL dabei für uns leistet. Im gezeigten Beispiel werden 72 Sudoku-Rätsel mit jeweils 1 bis ca. 300 000 Lösungen parallel gelöst. Die PPL stellt fest, dass es nicht sinnvoll ist, tatsächlich 72 Threads zu erstellen, wo nur 8 logische Cores zur Verfügung stehen. Daneben vermittelt die Grafik auch einen raschen Eindruck vom Status der Threads und damit von der Qualität der Parallelisierung. Execution (grün), Synchronization (rot) und Preemption (gelb) wechseln sich ab. Dabei ist Preemption Overhead und daher unerwünscht, Synchronization ein Warten auf eine Systemressource. Im konkreten Beispiel haben wir recht wenig Preemption, und auch die Synchronization hält sich in Grenzen. Anhand der Cores-Darstellung in Abbildung 3 ist recht schnell zu erkennen, ob Threads auch wiederholt Listing 3 int _tmain(int argc, _TCHAR* argv[]) vector<int (*)[9]> v = get_sudoku_samples(); const int nfields = v.size(); critical_section cscout; parallel_for(0, nfields, [&cscout, v] (int field) int (* sudoku) [9] = v[field]; int values = sudoku_getcount(sudoku); int solutions = sudoku_solve(sudoku, 0, 0); cscout.lock(); cout << "(" << values << "," << solutions << ")" << endl; cscout.unlock(); delete [] sudoku; ); return 0; 82

Anzeige

Anzeige

Parallelisierung in C++11. net-sprachen auf demselben Core ausgeführt werden. Das bringt ebenfalls Performance, da die Wahrscheinlichkeit eines Cache-Hits steigt. Paralleles Debugging Hinsichtlich der Unterstützung beim Debugging von parallelen Anwendungen sind bereits in Visual Studio 2010 einige Merkmale in Richtung PPL integriert, Visual Studio 2012 liefert weitere Neuerungen. Breakpoints lassen sich jederzeit auch in parallel ausgeführten Code setzen, hier geht der Entwickler wie gewohnt vor. Wird ein Breakpoint von einem Thread angesprungen, werden alle Threads angehalten. Über das bereits seit Längerem vorhandene Threads Window werden die aktuellen Threads dargestellt, es kann hier auch der Kontext von einem Thread auf einen anderen umgesetzt werden. Seit Visual Studio 2010 wird in der Spalte Location auch der Call Stack dargestellt, das hilft ungemein beim Navigieren. Dabei genügt es auch, die Maus über eine Location zu bewegen, der Call Stack wird dann als Tooltip dargestellt. Analog zum Threads Window existiert auch ein Parallel Task Window, in Abbildung 4 dargestellt. Dort werden anstelle von Threads PPL-Tasks dargestellt. Tasks sind nach dem Anlegen im Status Scheduled. Erst wenn sie einem Thread zugeordnet werden, erhalten sie tatsächlich Ausführzeit (Active), zusätzlich wird in dem Parellel Task Window dann der zugeordnete Thread dargestellt. Eine Task kann auch im Status Waiting (wartet auf eine Ressource) oder Deadlock (zwei Tasks blockieren sich gegenseitig) sein. Das Parallel Stack Window bietet beim Debugging eine Orientierungshilfe und erlaubt ein schnelleres Navigieren zwischen den einzelnen Ausführeinheiten. In diesem Fenster kann über eine kleine Auswahlbox links oben zwischen Thread und Task gewechselt werden. Der Inhalt von Variablen wird beim Debuggen über Watch Window oder Locals visualisiert. Ebenfalls kann der Inhalt recht einfach über einen Tooltip ermittelt werden, es wird wie gewohnt einfach die Maus über die entsprechende Variable bewegt. Neu in Visual Studio 2012 ist das Parallel Watch Window. Dieses stellt beim Debugging die Variablen für alle Tasks dar, die die entsprechende Methode durchlaufen haben. Im Kontext unseres Backtracking-Beispiels wird die Leistungsfähigkeit des Parallel Watch Windows erst richtig deutlich. Abbildung 5 veranschaulicht, dass es bei Rekursion die entsprechenden Variablen über den gesamten Call Stack hinweg darstellt neben Thread, Task und Rekursionstiefe. Automatische Parallelisierung Hinsichtlich automatischer Parallelisierung bietet Visual C++ 2012 einige neue Features. Der Vorteil: Der Entwickler und seine Anwendungen profitieren hier ohne weiteres Zutun. So können z. B. Schleifen automatisch parallelisiert werden. Wird der dargestellte Abb. 4: Parallel Task Window Abb. 5: Parallel Watch bei Rekursion Code aus Listing 4 mit der Option /Qpar (Enable Parallel Code Generation) übersetzt, findet das Aufsummieren der Werte unter Nutzung von acht Threads statt. Mit #pragma loop(hint_parallel(n)) kann die Anzahl der gewünschten Threads festgelegt werden. Die Option /Qpar-report:1 veranlasst den Compiler darüber hinaus dazu, beim Übersetzen eine kleine Meldung auszugeben, ob eine Parallelisierung auch tatsächlich umgesetzt werden konnte. Automatische Nutzung von Vector Units Heutige CPUs unterstützen in der Regel Vector Units mit einem erweiterten Befehlssatz, der die Ausführung einer Operation auf mehreren Registern gleichzeitig zulässt. Konkret existieren die Register der CPU dabei mehrfach. In einem Fetch-Zyklus werden aufeinanderfolgende Daten gleichzeitig in alle Parallelregister Listing 4 int arr[0x10000]; #pragma loop(hint_parallel(8)) for(int i=1; i<0x10000; i++) int result = 0; for(int j=0; j<0x100000; j++) result = result + i + j; arr[i] = result; www.windowsdeveloper.de 85

.net-sprachen. Parallelisierung in C++11 übertragen. Mit dieser Option kann das Abarbeiten von Arrays proportional zur Anzahl der Parallelregister beschleunigt werden. Die Erkennung von Kandidaten für diese Optimierung funktioniert so stabil, dass sie standardmäßig aktiviert ist und explizit über #pragma loop(no_vector) für einzelne Schleifen deaktiviert werden muss. GPU-Programmierung mit C++ AMP Das Prinzip der Parallelregister wurde nicht für CPUs erfunden, sondern eher von der GPU abgeschaut. Eine GPU ist nicht unbedingt direkt mit einer CPU zu vergleichen, sind doch der Aufbau und die Arbeitsweise recht unterschiedlich. So haben GPUs kein Stack-Konzept und daher gewisse Probleme mit rekursiven Methoden. Dafür sind sie aber ausgelegt, sehr schnell die gleichen Dinge auf unterschiedlichen Daten zu machen. Erreicht wird das durch schnellen Speicher und eine massive Anzahl einfacher Cores, die alle die gleichen Befehle ausführen. Die bei GPUs verwendete Abkürzung SIMD (Single Instruction Multiple Data) umschreibt diesen Sachverhalt recht gut. Zur Veranschaulichung: Heutige Grafikkarten kommen mit 0,5-4 GB Speicher daher und verfügen über 256 4096 Cores da steht eine i7 CPU mit acht Cores weit hinten an. Bei einer richtigen Verteilung unserer Algorithmen auf CPU und GPU sind daher enorme Leistungsverbesserungen zu erzielen. In der Praxis wird das bislang aber nur selten umgesetzt: Shader-Code, andere Compiler und eine dürftige Integration in die Entwicklungsumgebung stellen oftmals eine zu große Hürde für den C++-Programmierer dar. Mit C++ AMP fällt diese Hürde. Der Programmierer deklariert in seinem Code die Passagen, die auf der GPU ausgeführt werden sollen. Compiler und Linker sorgen für die gesamte Infrastrukur. Konkret werden die als C++-AMP-Code gekennzeichneten Codeteile durch den normalen C++-Compiler extrahiert und da- Listing 5 template<typename _type> void mxm_single_cpu(int M, int N, int W, const std::vector<_type>& va, const std::vector<_type>& vb, std::vector<_type>& vresult) for(int k=0; k<m; ++k) for(int j=0; j<w; ++j) float result = 0.0f; for(int i=0; i<n; ++i) int idx_a = k * N + i; int idx_b = i * W + j; result += va[idx_a] * vb[idx_b]; vresult[k * W + j] = result; std::vector<float> v_a(1024*1024); std::vector<float> v_b(1024*1024); std::vector<float> v_res(1024*1024); mxm_single_cpu(1024, 1024, 1024, v_a, v_b, v_res); Listing 6 template<typename _type> void mxm_amp(int M, int N, int W, const std::vector<_type>& va, const std::vector<_type>& vb, std::vector<_type>& vresult) extent<2> e_a(m, N), e_b(n, W), e_c(m, W); array_view<const _type, 2> av_a(e_a, va); array_view<const _type, 2> av_b(e_b, vb); array_view<_type, 2> av_c(e_c, vresult); parallel_for_each(av_c.extent, [=](index<2> idx) restrict(amp) _type result = 0.0f; for(int i = 0; i < av_a.extent[1]; ++i) index<2> idx_a(idx[0], i); index<2> idx_b(i, idx[1]); result += av_a[idx_a] * av_b[idx_b]; av_c[idx] = result; ); // explicitly about copying out data av_c.synchronize(); std::vector<float> v_a(1024*1024); std::vector<float> v_b(1024*1024); std::vector<float> v_res(1024*1024); mxm_amp(1024, 1024, 1024, v_a, v_b, v_res); 86

Parallelisierung in C++11. net-sprachen raus HLSL (Shader Code) generiert. Dieser wird durch einen Shader Compiler übersetzt und vom Linker in das Executable integriert. Compiler und Linker sorgen auch dafür, dass entsprechende Stubs, die zur Laufzeit die Übertragung von Daten und Code zwischen CPU und GPU übernehmen, in die Anwendung integriert werden. Hierfür setzt Microsoft auf DirectX, die entsprechenden Mechanismen werden dort bereits seit Langem erfolgreich genutzt. In Listing 5 wird eine einfache Matrixmultiplikation dargestellt, die für Matrizen der Größe 1024 x 1024 auf einer CPU ca. 10 s zur Berechnung benötigt. Eine Verteilung auf die Cores der CPU bringt hier natürlich auch bereits eine gewisse Verbesserung. Jedoch werden wir selten mehr als acht Cores antreffen, im Vergleich zur GPU eher dürftig. Der gezeigte Code lässt sich mit C++ AMP wirklich sehr einfach auf einer GPU zur Ausführung bringen. Wie, zeigt die Codesequenz in Listing 6. Auch hier bleibt die Struktur des Codes erhalten, C++ AMP erfordert ebenfalls nur etwas Dekoration um die Schleife herum. extent, array_view und parallel_for_ each kommen aus einer kleinen Klassenbibliothek zu C++ AMP und sorgen für den notwendigen Transfer der Daten von und zur GPU. Restrict(amp) ist die Anweisung an den Compiler, den entsprechenden C++- Block in Shader-Code zu überführen. Abbildung 6 zeigt das Ergebnis der Bemühung über den Concurrency Visualizer. Das Ergebnis ist so gravierend, dass ganz genau hingeschaut werden muss. Rechts unten im Diagramm sind zwei recht kleine Zacken zu erkennen, das ist die Ausführung auf der GPU. Der riesige, grüne Balken darüber stellt die Ausführung auf der CPU dar. In Zahlen: Aus 10 s Rechenzeit auf der CPU werden weniger als 100 ms auf der GPU! Und die werden darüber hinaus hauptsächlich für den Transfer der Daten zur und von der GPU benötigt. Dass auch hinsichtlich Debugging bei Nutzung von C++ AMP keine größeren Einschränkungen in Kauf zu nehmen sind, dafür sorgt ein GPU-Emulator. Der Code wird zwar deutlich langsamer als auf einer physikalischen GPU ausgeführt, aber dafür können wie gewohnt Breakpoints genutzt werden, sogar das Parallel Watch Window funktioniert wird erwartet. Lediglich ein Mixed Debugging von CPU- und GPU-Code wird derzeit leider noch nicht unterstützt, es müssen zwei getrennte Debug-Sessions gestartet werden. Fazit Parallelisierung ist Pflicht! Und da ist es beruhigend zu sehen, dass Compiler-Hersteller mit Hochdruck daran arbeiten, dieses Thema für uns Entwickler einfacher zu gestalten. Microsoft hat in Visual Studio 2010 mit der Parallel Pattern Library und einer guten Werkzeugunterstützung bereits gute Vorarbeit geleistet. Diese wird mit Visual Studio 2012 noch weiter abgerundet. Use Task No Threads vorbei sind die Zeiten von CreateThread & Co, Lambdas machen das Leben leichter! Abb. 6: Performancevergleich von CPU und GPU Mit C++ AMP ist Microsoft ein weiterer, recht großer Wurf gelungen, denn nun wird die GPU für den C++-Programmierer zugänglich. Insbesondere der Aufwand für die Portierung bestehenden C++-Codes auf eine GPU wird damit deutlich minimiert. Bleibt zu wünschen, dass eine große Schar an Programmierern nun endlich die Zeit finden wird, sich um Parallelisierung zu kümmern. Denn auf Ebene der Hardware stehen wir hier sicherlich erst am Anfang, und die aktuelle Lücke sollte geschlossen werden, bevor sie zu groß wird. Thomas Trotzki ist ALM Consultant bei der artiso AG nahe Ulm und Microsoft-C++-Profi der ersten Stunde. Mit Microsoft C++ und den MFC beschäftigt er sich intensiv seit den ersten Betaversionen zu Microsoft C/C++ 7.0, also bereits vor der Geburtsstunde von Visual C++ und Visual Studio. Technologisch ist er neben C++ und den MFC auch mit COM/DCOM und der gesamten Managed Welt vertraut und hat umfangreiche Expertise im Application Lifecycle Management. Christian Binder arbeitet als ALM Architect in der Developer Platform & Strategy Group bei Microsoft Deutschland. Er arbeitet seit 1999 bei Microsoft, u. a. als Escalation Engineer, dann als Platform Strategy Manager, und kann so auf umfangreiche Erfahrungen im Bereich Application Development zurückgreifen. Auch war er im Product Development von Microsoft in Redmond tätig, was ihn 2005 zum Thema Application Lifcycle Management gebracht hat. Links und Literatur [1] http://it-republik.de/dotnet/windowsdeveloper-ausgaben/ Windows-Phone-000513.html www.windowsdeveloper.de 87