Ein neun Minuten langes Einführungsvideo, das an Beispielen erklärt, wie das Intel Parallel Studio die parallele Programmierung erweitert und wie sie mit dem Visual Studio verbessert werden kann.
Intel Parallel Studio ist eine Gesamtlösung zur Parallelität eines Visual Studios. Lassen Sie mich erklären, warum wir es eine Gesamtlösung nennen und begleiten Sie mich durch die Hauptfeatures eines Intel Parallel Studios. Wir nennen es Gesamtlösung, weil es Sie dabei berät, wo Sie in Ihrem laufenden Programm noch Parallelität zugeben sollten und wie Sie herausfinden, wo Sie am Besten Parallelität hinzufügen. Sie erhalten auch die nötigen Tools um Parallelität hinzuzufügen, sie auszutesten und zu tunen. Sehen wir uns als Beispiel das N-Queens Beispielprogramm an, in dem wir multiple Versionen dieses Beförderns mit dem Intel Parallel Composer haben, und der Teil des Parallel Studios ist. Das N-Queens ist ein Programm, das berechnet, wie viele verschiedene Schachpositionen gültig sind oder wie viele Arrangements eines Boards für ein End-by-End Board mit N-Queens darauf möglich sind, ohne dass die Queens sich gegenseitig gefangen nehmen können. Für ein 13 mal 13 Board gibt es einige Möglichkeiten, sehen wir sie uns genauer an. Wir haben hier ein laufendes Visual Studio 2008, in das ich jetzt eintrete. Als erstes möchte ich herausfinden, wo der Hot Spot des Programms ist. Ich rufe also das Tools Menü auf und öffne die Hot Spot Analyse. Wie Sie sehen, kann man im Tools Menü den Intel Parallel Amplifier aufrufen, der das Tool zum Tunen von Analysen in einem Programm ist, und wir wählen Hot Spot Analyse. Jetzt fährt der parallele Verstärker unser Programm und analysiert es. Sobald er damit fertig ist, stellt er die Ergebnisse zusammen. Und dann erscheint eine Erklärung, wo die Hot Spots sind. Das ist dann schon etwas greifbarer für den Ansatz wo unser Programm optimiert werden kann. In diesem speziellen Beispiel beansprucht offensichtlich die Funktion setQueen die meiste Zeit. Sie beansprucht weit mehr Zeit als die zweithäufigste Funktion. Das Analysetool hat die Funktionen in der Reihefolge organisiert, wie sie die meiste Zeit beanspruchen. Sehen wir uns also setQueen an. Wir können hier rechts im Bildschirm erkennen, dass es einen Stapelcall gibt. Wir können auch die Reihenfolge sehen, in der die Funktionen aufgerufen werden und wie wir zur Funktion setQueen kommen. Das wird sich noch als sehr wichtig erweisen. Klicken wir also auf setQueen und sehen uns den setQueen Quellcode an. Hier sehen wir ein Bündel Anweisungen und dass es ein rekursives Programm ist. Man kann nichts finden, wo eine Parallelität hinzu passen würde. Ich glaube nicht, dass diese Funktion einen passenden Platz für eine Parallelität hat. Darum wenden wir uns lieber dem Stapelcall zu. Und hier im Stapelcall können wir etwas Anklicken und sehen, dass setQueen immer von der Funktion Lösung aufgerufen wird und dass diese Lösungs-Routine der richtige Platz für eine Parallelität ist. Es ist der Haupttreiber für unser N-Queens Beispielprogramm. Am Besten sehen Sie immer auf der höchsten Ebene einer Anwendung nach, an der Sie eine Parallelität anfügen können. Hinzufügen und Verschachteln an verschiedenen Programmplätzen ist sicher eine gute Idee, aber zu Beginn fügen Sie Parallelität wahrscheinlich auf höheren Ebenen erfolgreicher ein. Wir fahren nur darüber und klicken auf den Stapelcall und die Quelldatei, öffnen sie und sehen uns die Lösungsroutine an. Und hier gehen wir nur zur Leitungsschleife und fügen einfach nur __par hinzu, um es parallel zu schalten. Nun, diesen Teil des Intel Parallel Composer, diese Funktionalität, nennen wir unsere Pragma-freie Syntax für OpenMP. Sie können genau dasselbe mit OpenMP Pragmas machen, oder dieses __par verwenden. Wir versuchen das __par. Und dadurch wird diese Leitungsschleife eine Schleife, die mit OpenMP parallel geführt wird. Wenn wir aber nur diese Anwendung, so wie sie ist, kompilieren, haben wir noch keine Parallelität, da wir für das Kompilat, ganz wichtig, auch das Feature OpenMP benötigen. Wir wechseln also in den Composer, auf die Seite Eigenschaften, Pull-down und sehen unter Sprache „C++“ an und wählen bei OpenMP Unterstützung aus, dass wireinen Parallelcode erstellen möchten. Nachdem wir nun die OpenMP Laufzeit gewählt haben, erkennt der Compiler die OpenMP Endungen und verlinkt in diejenige OpenMP Bibliothek, in der wir unsere Anwendung einbauen können. Hier erneuern wir unsere Anwendung, räumen auf und verfahren weiter, indem wir die ungenutzten Verstärkerfenster schließen. Wenn der Aufbau der Anwendung fertig ist, können wir sie laufen lassen. Und hier sehen wir, dass die Anwendung nur halb so viel Zeit wie zuvor benötigt hat, das sieht doch recht gut aus. Leider bekommen wir aber eine falsche Antwort. Ich kann mich erinnern, dass die Antwort bei 13 mal 13 N-Queens 73,712 Lösungen heißt. In diesem Fall wurden irgendwie vier Lösungen ausgelassen und es sind nur 73,708. Ein ausgezeichnetes Beispiel, an dem ich einen anderen wertvollen Teil des Intel Parallel Studios erklären kann. Wir gehen also zum Menü Tools und finden den Parallel Inspector im Pull Down, den wir jetzt starten. Es wird jetzt die Thread-Fehlersuche gestartet. Wir sehen hier, dass sie einige Data Race Proleme aufzeigt. Sie macht uns auf diese Data Races aufmerksam, die nicht erwünscht sind. Nun ist die ganze Datenerfassung fertig. Wir können uns die Data Race Probleme, die sie uns anzeigt, genauer ansehen. Wir klicken einmal auf das Data Race Problem und es wird der Quellcode angezeigt. Die angezeigten Data Races liegen in der setQueen Funktion und es zeigt an, dass ein Leser und ein Schreiber nicht richtig geschützt sind. Jetzt müssen wir etwas Synchronisation hinzufügen, ein kritisches Gebiet. Wir wenden also wieder unsere Pragma- freie Syntax für OpenMP an, indem wir __critical aufrufen. In diesem speziellen Fall legen wir es vor diese Erhöhung, die zählt wie viele Lösungen es gibt. Jetzt ist es geschützt. Wenn das Problem dadurch gelöst wurde, heißt dies, dass einige dieser Erhöhungen zwar parallel lagen, aber nicht miteinander synchronisiert waren und wir so im Ergebnis einige der Lösungen verloren haben. Wir bauen sie erneut auf. Und lassen sie laufen. Funktioniert bestens. Und es benötigt immer noch nur die Hälfte der Zeit wie zuvor. Die Einführung dieses kritischen Abschnitts hat das Programm nicht verlangsamt und man bekommt jetzt die richtige Antwort. Wie kann ich nun einen zusätzlichen Check machen und wie gut laste ich meine Maschine aus? Für diesen Fall haben wir hier eine Dual-Core Maschine. Wir gehen zum Menü Tools, Pull-down und öffnen Parallel-Amplifier. Im Parallel-Amplifier wählen wir die Gleichzeitigkeitsanalyse. Diese analysiert, wie gut die Gleichzeitigkeit auf unserer Maschine genutzt wird. In diesem Fall sehen wir, dass meine Anwendung nach dem Programmlauf und der Gleichzeitigkeitsanalyse mit 95 Prozent Effizienz läuft. Das heißt, dass wir auf zwei Cores die Geschwindigkeit gut heraufgesetzt haben. Bei dieser Anwendung können wir wahrscheinlich nicht mehr erreichen. Das war also ein kurzer Rundgang durch die Anwendungsmöglichkeit des N-Queens Programms - wir können mit dem Verstärker einen Hot Spot für uns finden und können eine Parallelität in einem kritischen Gebiet hinzufügen. Das kritische Gebiet, auf das wir aufmerksam gemacht wurden, nachdem das Programm nicht richtig gelaufen ist. Wir haben dann den Parallel Inspector zum schnellen Finden der Quelle dieses Data Race Problems verwendet, der uns zu einem nicht ordnungsgemäßen Programm geführt hat. Und hier haben Sie alles, einen Rundgang durch die Möglichkeiten, ein Visual Studio mit Hilfe des Intel Parallel Studios zu erweitern und parallel zu programmieren. So können Sie Aufgaben unkompliziert und erfolgreich erledigen. Weitere Informationen über das Parallel Studio erhalten Sie unter intel.com/go/parallel