C++ mit .NET
Bernd Marquardt
Microsoft Regional Director Germany
Software & Consulting
http://www.go-sky.de
Hinweis
Ja, es sind viele Slides…
…aber einige Slides sind nur der Vollständigkeit halber dabei und werden im Vortrag selbst sehr schnell erledigt!
Wir werden nicht alle Demo‘s hier testen…
…aber in einer „stillen Stunde“ können Sie die Demo‘s selbst ausprobieren
Agenda
Einführung C++ Managed Extensions für .NET
• Stand der Dinge
• Anwendung: Wrapper-Klassen
• Performance
C++ in Visual Studio 2005 (Whidbey)
• CLI
• Generische Typen, STL und …
• OpenMP
Zusammenfassung
20032003
20052005
Einführung
C und C++ sind wichtige Programmiersprachen unter Windows
• Bis 1992 in „reinem“ C und SDK
• Danach mit C++ und MFC
Windows „begann“ mit C
• VB kann erst später
Bei Microsoft wird auch heute noch FAST alles mit C++ codiert
• Das soll aber in Zukunft anders werden
Einführung
Vorteile von C++:
• Performant
• Volle Kontrolle, man kann alles machen
• Wenig zu tippen
• Es geht immer alles, was möglich ist
Nachteile von C++:
• Schwer zu lernen
• Viele Fallstricke und „Pumpen, vor die man laufen kann“
Einführung
Die „Pumpen“ von C und C++
• Zeiger
• Makros – das „Klammerproblem“
• new / delete
• switch / break
• Globale Variablen und Funktionen
• Variablen-Initialisierung
• …
C++ und .NET: Heute
C++ Managed Extensions
• Zugriff auf das .NET-Framework
Aufruf von unmanaged Code Wrapper-Klassen
• Wrappen von MFC-Klassen
C++ Man. Ext. für .NET
C++ Managed Extensions (VS 2002 und 2003):
• Code sieht nicht sehr schön aus
• Code ist schwer zu lesen
• Unterscheidung von „managed“ und „unmanaged“ Objekten ist schwierig
• Die _-Taste geht sehr schnell kaputt
• Managed Extensions sind dem C++ „aufgedrückt“ worden
• VS 2002: Kein Designer für Windows Forms mit man. C++ enthalten
IL und nativer Code
C:>CL.EXE /LD /clr cpptest.cpp
void ManagedFunc() {}
#pragma unmanagedvoid NativeFunc() {}#pragma managed
void AnotherManagedFunc() {}
cpptest.cpp
C:>ILDASM.EXE cpptest.dll
IL und nativer Code#pragma unmanagedvoid NativeFunc() {}#pragma managed
void ManagedFunc(){ NativeFunc(); }
Definition von .NET Typen
__gc class ManagedClass {};__gc struct ManagedClass2 {};__gc __interface ManagedInterface {};__delegate void ManagedDelegate();
referenzierende Typen
Wertetypen__value class ManagedValueType {};__value struct ManagedValueType2 {};__value enum ManagedEnum {};
Referenzierende Typen
Instanzierung durch expliziten __gc new Aufruf
Speicher wird auf dem "Managed Heap" angelegt
Garbage Collector gibt Speicher für Instanzen wieder frei
Variablen grundsätzlich Zeigertypen (__gc*) oder Referenztypen (__gc&)
• GC kontrolliert __gc* und __gc&
Wertetypen
Sind grundsätzlich immer in "etwas" enthalten…
• …als globale Variable in der Anwendungsdomäne
• …als lokale Variable im Stackframe
• …als Feld eines Typs in einer Instanz dieses Typs
Instanziierung und Lebenszeit an enthaltende Entität gebunden
• Die Lebenszeit also ist inkompatibel zur Lebenszeit von .NET-Objekten
Schnittstellen
__gc __interface I1 { void M1(); void M2();};
__gc class ManagedClass : public I1{public: void M1 {} void I1::M2() {}};
implizite Implementierungexplizite Implementierung
Enumeratoren
// C++ Managed Extensions
[System::Flags]
__value public enum ManagedEnum : short{ red = 1 << 0, // 1 yellow = 1 << 1, // 2 blue = 1 << 2 // 4};
Delegates
public __delegate void ADelegate();
ADelegate* pD1 = new ADelegate(pRefToClassXInstance, &ClassX::NonStaticMethod);pD1->Invoke();
ADelegate* pD2 = new ADelegate(0, &ClassX::StaticMethod);pD2->Invoke();
Methoden
using namespace System;using namespace System::Runtime::InteropServices;
public __gc __interface ITest{ void M1(Int32 n, String* ps); void M2(Int32* pn, String** ppstr); void M3([Out]Int32* pn, [Out] String** ppstr);};
using Systen;
public interface ITest{ void M1(Int32 n, String ps); void M2(ref Int32 pn, ref String ppstr); void M3(out Int32 pn, out Int32 ppstr);}
C++
C#
Eigenschaften
public __gc class Test{ int _age;public: __property int get_Age() { return _age; } __property void set_Age(int age) { _age = age; }}
public class Test{ private int _age;
public int Age { get {return _age;} set {_age = value;} }}
C++
C#
pTest->Age = pTest->Age + 1;
test.Age = test.Age + 1;
Indexer
using namespace System;using namespace System::Reflection;
public __gc __interface INameList{ __property String* get_Name(int i); __property void set_Name(int i, String* psNewVal);};
using System;
public interface INameList{ String this[int i] { get; set; }}
C++
C#
INameList nl = ...;string str = nl[0];
INameList* pNL = ...;string str = pNL->Name[0];
Exception Handling Syntax ist ähnlich wie im klassischen C++ Managed Exceptions sind Referenzen auf
beliebige .NET-Objekte• Basisklasse System::Exception
Verschiedene catch-Blöcke eines try-Blocks können sowohl C++-Exceptions als auch .NET- Exceptions behandeln• C++-Exceptions müssen vor .NET-Exceptions
behandelt werden Auslösen und Abfangen von C++ und .NET-
Exceptions in einer try-Anweisung ist zulässig
Win32 Structured Exception Handling (__try, __except) ist in Managed Code unzulässig
Exceptions
void ManagedFunc(int i) { try { ... } // C++ Exception catch (int i) { System::Console::WriteLine(i); } // nicht CLS kompatible .NET Exception catch (System::Exception* pE) { System::Console::WriteLine(pE->Message); } // CLS kompatible .NET Exception catch (System::Object* pE) { System::Console::WriteLine(pE); } __finally { ... Ressourcen hier freigeben ... }}
Determin. Finalisierung
C++-Klassen werden als lokale Variablen automatisch deterministisch finalisiert• Der Destruktor wird beim Verlassen des
Scope aufgerufen…
• …auch wenn der Scope durch eine Exception verlassen wird
Instanzen von .NET Klassen werden nicht automatisch deterministisch finalisiert• Die deterministische Finalisierung muss
manuell durch try/__finally-Blöcke realisiert werden
Determin. Finalisierung
In GC-Klasse kann ein Destruktor implementiert werden
• Überschreibt Object::Finalize und implementiert Methode __dtor
• Finalize wird von Garbage Collector aufgerufen, bevor Objekt zerstört wird
• __dtor wird vom delete-Operator aufgerufen
• __dtor ruft zuerst GC::SuppressFinalize und dann Finalize auf
Aufruf von unman. Code
Es gibt sehr viel Code in C und C++ Vieles davon kann man weiter verwenden Aufruf von unmanaged Code:
• [DllImportAttribute(…)] (geht mit allen .NET-Sprachen)• Daten werden automatisch konvertiert
• Achtung: Anwendung von Zeigern
• „It just works“-Methode (geht nur mit C++)• Einfach die Header-Dateien einfügen und API‘s
aufrufen
• Daten müssen konvertiert werden
C++ als .NET Sprache
Vorteile
• Ermöglicht das Mischen von MSIL-Code und nativem Code
• Aufruf nativer Funktionen im MSIL-Code ist:…viel einfacher
…viel schneller
…ohne Einschränkungen möglich
Nachteile
• „Kranke“ Syntax
Wrapper-Klassen Managed Wrapper-Klassen
umhüllen eine normale unmanaged C++-Klasse
Die Hüllklasse funktioniert wie ein Proxy
Die Hüllklasse hat die gleiche Funktionalität wie die C++-Klasse
Es wird immer ein „Klassenpaar“ erzeugt, bzw. zerstört
Beide Klassen können in einer Datei angelegt werden• Einfache Verwaltung
Wrapper-Klassen
Ein Objekt der Wrapper-Klasse kann unter .NET wie ein normales .NET-Objekt benutzt werden
Die Daten-Konvertierung wird ggf. in der Wrapper-Klasse implementiert
• Byte, int, long, short, float, double keine Konvertierung nötig
• String muss konvertiert werden• Achtung: ANSI oder UNICODE beachten
• Struct‘s müssen meistens angepasst werden• Es gibt dafür spezielle Attribute (z.B. FieldOffset)
Wrapper-Klassen
class CppClass { public: // Konstruktor CppClass() { …}
// Destruktor ~CppClass() { …}
// Methoden void native_f() { …} };
__gc class ManClass { public: // Konstruktor ManClass() { m_pC = new CppClass(); } // Freigabe ~ManClass() { delete m_pC; } // Methoden void managed_f() { m_pC->native_f(); } private: CppClass * m_pC; };
Wrapper-Klassen
Erzeugung einer man. C++-Klasse• Data Member in der Wrapper-Klasse: Zeiger vom
Typ der C++-Klasse
In der managed Klasse müssen die Konstruktoren nachgebildet werden
In der Dispose-Methode der managed Klasse die Instanz der unmanaged Klasse zerstören
ACHTUNG: Wrapper-Objekt steht unter der Kontrolle des Garbage Collectors
Alle public-Methoden der unmanaged Klasse in der managed Klasse implementieren
Wrapper-Klassen Destruktoren
• Sowohl den Destruktor als auch die Dispose-Methode implementieren• Wrapper-Klasse von IDisposable ableiten
• „Selbst-gesteuertes“ Zerstören des Objektes durch Dispose-Aufruf
• Dort Finalize() aufrufen
• GC::Supress::Finalize wird automatisch vor dem Finalize()-Aufruf getätigt
• Dispose-Aufruf vergessen: Garbage Collector schlägt mit dem Destruktor zu
Probleme mit Wrappern
Variable Parameteranzahl Daten-Marshaling Default Argumente Destruktoren (Garbage Collector) Properties Überladen von Operatoren• Wenn der Wrapper z.B. mit VB oder C#
genutzt werden soll, müssen die überladenen Methoden auch als “echte” Methode implementiert werden • C#: Operator-Overloading erlaubt
• VB: nicht erlaubt
Wrapper-Klassen
Wrapper sind eine einfache Möglichkeit, um existierende C++-Klassen weiter zu benutzen
• Innerhalb der unmanaged C++-Klassen ist alles erlaubt (z.B.: Multiple Inheritance)
Wertet die C++-Klassen auf, da sie nun aus allen .NET-Sprachen aufgerufen werden können
Performance beachten
• Kontext-Wechsel, Konvertierungen
MFC-Dialoge wrappen
Anwendung von Wrapper-Klassen
Frage: Kann man von alten monolitischen
MFC-Applikationen irgendetwas weiter verwenden (mit Hilfe von Wrappern)?
Analyse
In Dialogen steckt oft ähnlich viel Code wie im Hauptfenster
• Ausnahme: Applikationen mit vielen mathematischen Rechenalgorithmen
Dialoge sind aufwändig zu erstellen
• Platzierung der Controls (zeitaufwändig: Design)
• Programmierung (zeitaufwändig: Tests)
Es wäre gut, wenn man die Dialoge weiter verwenden könnte Wrapper-Klassen!!!
Der Migrationsweg (1)
Alle Dialoge in einer MFC-DLL ablegen
• CPP- und H-Dateien ins DLL-Projekt einfügen
• Resource.h hinzufügen (kopieren)
• RC-Datei aus Applikation mit Notepad editieren
• Nur Dialoge übernehmen
• Drag&Drop in der IDE klappt (manchmal) irgendwie nicht so ganz
Der Migrationsweg (2)
Für jeden Dialog eine Wrapper-Klasse generieren
• Automatische Erzeugung mit einem kleinen Tool (ist möglich)
• Unicode / ANSI auswählen
• Wrapper kann auch von Hand erzeugt werden
Manchmal muss die Typ-Konvertierung „von Hand“ implementiert werden
„#pragma managed“ und „#pragma unmanaged“ korrekt verwenden
Der Migrationsweg (3)
DLL Kompilieren
• „Use managed extensions“ auf „YES“ setzen
• MFC-Library STATISCH linken (WICHTIG)
Hauptfenster mit .NET erzeugen
• Referenz auf DLL anlegen
• Menü, Toolbar und Statuszeile (usw.) implemetieren
• Entsprechende Wrapper-Objekte aufrufen
• Übersetzen und testen
Der Migrationsweg (4)
Deutliche Zeiteinsparung beim Umstieg auf .NET
• Kein Programmieren und Testen der Dialoge
• Kein Neu-Design der Dialoge (das kann auch ein Nachteil sein! Design)
Wrapper evtl. mit Tool generieren
Performance
Ein Hauptgrund für C und C++:
• Performance
Auch unter .NET ist C++ sehr schnell
• Im Moment: Die schnellste .NET-Sprache
• Wichtig bei mathematischen Berechnungen (Algorithmen)
• Weniger wichtig bei User Interfaces, mehrschichtigen Datenbank-Applikationen• Flaschenhals hier: Datenbank und/oder
Netzwerk
Arithmetik (einfach)
((double) i + (double) j) * 2.5
VB 6.0 50.610 sek VC++ 6.0 5.860 sek
VC .NET unmng. 5.703 sek
VC .NET mng. 7.235 sek C# 8.563 sek VB .NET 9.250 sek
VS 6.0VS 6.0
VS .NETVS .NET
Asm.Asm.
CLRCLR
Arithmetik (kompliziert!)
(((double) i + (double) j) * 2.5) / (i + j + 1)
VB 6.0 80.313 sek VC++ 6.0 24.891 sek
VC .NET unmng. 24.890 sek
VC .NET mng. 24.850 sek C# 24.891 sek VB .NET 24.990 sek
VS 6.0VS 6.0
VS .NETVS .NET
Asm.Asm.
CLRCLR
Arithmetik (esotherisch!)
Fast Fourier Transformation• Sägezahn aus 65.536 Einzelwerten
• Daten-Array als lokale Variable
VC++ unmng. (lok. Array) 63 msek
VC++ mng. (lok. Array) 63 msek
Mathematische Algorithmen sind sehr schnell – Rechnenoperationen ohne Einschränkungen
Arithmetik (esotherisch!)
Fast Fourier Transformation• Sägezahn aus 1.048.576 Einzelwerten
• Daten-Array auf dem Heap (mit VC.NET unter Kontrolle des Garbage Collectors)
VC++ unmng. (nat. Heap) 2.250 sek VC++ managed (GC) 2.609 sek
Auch mit GC sind (fast so) schnelle Berechnungen möglich
String-Operationen
Anhängen von 100.000 Strings zu je 10 Zeichen (Unicode)
VB6, normaler String: 44.231 sek Einfacher MFC-String: 17.340 sek MFC-String mit Allokation: 0.046 sek C#, einfacher String: 87.820 sek C#, StringBuilder: 0.047 sek C++, char-Array, memcpy: 0.010 sek
Aufruf von unman. API‘s
Eine herkömmliche Windows-DLL kann von einer Applikation mit managed Code aufgerufen werden
Die Funktion erhält double-Wert und gibt einen int-Wert zurück
Die Funktion wird 10.000.000 mal aufgerufen
aus VC++ 6.0 1.500 sek aus C# 4.453 sek
Weitere Ergebnisse
Compilier-Geschwindigkeit des JIT-Compilers
Frage: Wieviel Zeit geht bei der „Laufzeit-Übersetzung“ des IL-Codes verloren?
JIT kompiliert ca. 5000 Zeilen IL-Code pro Sekunde (500 MHz Pentium III)
• Geschwindigkeit ist natürlich abhängig vom Code
Optimierung des Codes
Es gibt zwei „Stellen“, denen optimiert werden kann
• Im Sprach-Compiler
• Im JIT-Compiler• Zur Analyse des Maschinencodes Benutzung
von:
• DebugBreak();
Allgemeine Ergebnisse: Manches optimiert der Sprach-Compiler,
manches wird vom JIT-Compiler optimiert
Optimierung des Codes
d += (double)i1 + 7.5 * 11.2 / 2.5;
• Sprach-Compiler fasst zusammen
for-Schleifen mit wenigen Durchgängen
• JIT macht Loop-Unrolling for(i = 5; i < 5; i++)
• JIT beachtet die Schleife nicht d += 3 + a – a;
• JIT erzeugt keinen Code für „+ a - a“
....
Warum C++ unter .NET?
1. Performance 2. Volle Kontrolle 3. Es geht alles 4. Einfacher Zugriff auf „alten“
unmanaged Code
Compiler für 64-bit-Prozessoren verfügbar
C++ und .NET: Morgen
C++ in Visual Studio 2005 (Whidbey)
• Neue Features mit C++• Optimierungen
• C++/CLI – Common Language Infrastructure
• Generische Typen und Templates
• Multithreading mit OpenMP
C++: Neues in VS 2005
Neue Syntax • Elegant und einfach
• Natürlich
• Verifiable Code
• Keine __keywords
• Context-sensitive Keywords• Wirksam in einem bestimmten Kontext
• Spaced Keywords• Werden zusammen mit anderen Keywords
benutzt
Neue Syntax
Nachlesen in: C++/CLI Specification http://download.microsoft.com/download
/9/9/c/99c65bcd-ac66-482e-8dc1-0e14cd1670cd/C++%20CLI%20Candidate%20Base%20Draft.pdf
…schöne URL…
C++ Managed Extensionspublic __gc __sealed class Student{ private: double m_grade; String* m_name;
public: // Property implementation
__property double get_Grade() { return m_grade; } __property void set_Grade(double newGrade) { m_grade = newGrade); }
__property String* get_Name() { return m_name; } __property void set_Name(String* newName) { m_name = newName; }};
C++ / CLI morgenpublic ref class Student sealed{ private: double m_grade;
public: // Standard property syntax
property double Grade { double get() { return m_grade; } void set(double newGrade) { m_grade = newGrade; } }
// Trivial property syntax
property String^ Name;};
Klassen mit „Adjektiven“
Die Klassen erhalten Eigenschaften
class N { /**/ }; // Nativer Typ
ref class R { /**/ }; // CLR Referenz-Typ
value class V { /**/ }; // CLR Werte-Typ
interface class I { /**/ }; // CLR Interface-Klasse
enum class E { /**/ }; // CLR Aufzählungs-Typ
Instanzierung
Auf dem native Heap: new T• Früher: __nogc
Auf dem managed Heap: gcnew T• Früher: __gc
Auf dem Stack: T t
Objektzerstörung
Objekte im Garbage Collector• Nicht deterministische Auflösung
• Mit „gcnew“
• Man bekommt ein „Handle“ Objekte auf dem normalen Heap• Deterministische Auflösung (delete)
• Mit „new“
• Man bekommt einen Zeiger Objekte auf dem Stack• Deterministische Auflösung (Scope)
• Nur Deklaration
Zeiger und Referenzen
Zeiger bleiben Zeiger
• Mit ihren Vor- und Nachteilen
In VS 2005 gibt gcnew ein „Handle“ zurück
• Darstellung durch ein „^“ ( “hat”)
• Handles sind die Verbindung zu fertigen Objekten im managed Heap
• Keine Pointer-Arithmetik
• Keine Konvertierung nach void
• Tracking reference operator „%“
• Pinning Pointer: pin_ptr
Roadmap C++/CLI
C++/CLI soll standardisiert werden Oktober 2003: Task Group TG5
• ISO C++: WG21
Standardisierung: Ende 2004
Update nach C++/CLI
__gc class ref class __gc struct ref struct __value class value class __value struct value struct Default-Konstruktoren aus value classes
entfernen __interface class interface
class __interface struct interface
struct
Update nach C++/CLI
__abstract abstract (nach hinten) __sealed sealed (nach hinten) __property property __event event __value enum enum class __gc* ^ __pin pin_ptr new gcnew 0 oder null nullptr
Update nach C++/CLI
__gc[ ] array Alle Instanzen von __box entfernen „S“ vor den String-Konstanten
entfernen Explizite Deklaration von überladenen
Operatoren entfernen __typeof typeid< > __try_cast safe_cast• Namensraum stdcli::language
hinzufügen
Generische Typen
C++-Templates• Werden zur Übersetzungszeit expandiert
• Zur Laufzeit können keine neuen Spezialisierungen aufgebaut werden
• Die CLR weiss nichts über Templates
• Ein generischer Typ kann nicht Typ-Parameter eines Templates sein Compile-Time-Spezialisierung der Templates
• Explizite Spezialisierung erlaubt• Verhalten für einen speziellen Typ
• Partielle Spezialisierung erlaubt• Verhalten für spezielle Argumente
Generische Typen Generics• Werden zur Laufzeit vom JIT-Compiler
expandiert
• Generische Typen können von allen .NET-Sprachen benutzt werden, egal in welcher Sprache sie erstellt wurden
• In mehreren Assemblies möglich
• Der Typ-Parameter darf nicht als Basisklasse für den generischen Datentyp verwendet werden
• Default-Werte sind nicht erlaubt
• JITter kann zur Laufzeit in Abhängigkeit vom Typ-Parameter optimieren
Generische Typen
generic <typename T> // template <typename T>ref class GenType // ...{ // T entsprechend benutzen // ... };
void _tmain(){ GenType<typ>^ xxx = gcnew GenType<typ>;
// ...}
STL
STL kann nun auch mit dem .NET-Framework benutzt werden
• Ist optimiert, um mit managed Code und managed Daten zu arbeiten
Die gleichen Technologien, die bisher verwendet wurden, können nun mit der CLR benutzt werden
Interop
DLL-Aufrufe (P/Invoke) COM-Aufrufe (RCW und CCW) „It just works“ „Interop
Technologies“ Das gab es alles auch schon in VS 2003! Übrigens: .NET-Komponenten können auch aus
unmanaged Code aufgerufen werden
• Bestehende Applikation kann einfach erweitert werden
• Attribut: ClassInterface verwenden
Optimierungen
WPO
• Whole Program Optimization
Bessere Pentium 4-Unterstützung Bessere Optimierung beim Linken Profile Guided Optimization
• Ablauf-Szenarien werden beim Linken berücksichtigt
Optimierungen
Profile Guided Optimization (POGO)
Source Compilieren Object-Files
Object-Files
Link InstrumentedImage
Scenarios InstrumentedImage
OutputProfileData
Object-Files
ProfileData Link Optimized
Image
Optimierungen
POGO ermöglicht…
• Bessere Entscheidungen zum „Inlinen“ von Code
• Reorganisation von switch- und if-else-Konstrukten
• Codeblöcke können besser angeordnet werden• Weniger Sprünge, weniger Paging
• Codeteile können mit unterschiedlichen Optimierungsoptionen übersetzt werden
Security
In VS 2002: /GS-Schalter
• Überprüfung auf „Buffer Overrun“
In VS 2005:
• /GS ist standardmäßig eingeschaltet
• Check-Funktion wurde erweitert• Kopie der „angreifbaren“ Variablen wird
angelegt und ggf. benutzt
• Über 400 sichere neue Runtime-Funktionen• Unsichere Funktionen werden ersetzt
• Siehe „strsafe.h“
OpenMP
OpenMP ist eine einfache Möglichkeit für Multithreading
• Für Fortran (Intel)
• Für C++ (Intel, VS 2005)
Normales Multithreading:
• Klasse mit Methode
• ThreadStart-Objekt anlegen
• Thread-Objekt anlegen
• Thread-Methode starten
• Synchronisierung mit Join()
OpenMP
Normales Multithreading beinhaltet einen relativ großen Overhead
Insbesondere wenn Algorithmen parallelisiert werden sollen
In OpenMP:• Steuerung der Parallelisierung durch C++-
Pragma im Code
• Z.B.: #pragma omp parallel• Steueranweisung stehen direkt im Code
Mit nativem und mit managed Code Compiler-Schalter: /OPENMP
OpenMP
Es gibt unterschiedliche Arten der Parallelisierung:
• Parallelisierung von Schleifen
• Parallelisierung von Code-Regionen
Nicht zu vergessen:
• Synchronisierung
Und wie steht‘s mit der Performance?
Schleifen mit OpenMP
Schleifen werden auf mehrere Threads automatisch aufgeteilt
Anzahl kann angegeben werden oder ist vom System vorgegeben oder wird dynamisch ausgewählt
void saxpy(double z[], double a, double x[], double y, int n){#pragma omp parallel for for(int i = 0; i < n; i++) { z[i] = a * x[i] + y; }}
Schleifen mit OpenMP
Serielle Ausführung im Master-Thread
Serielle Ausführung im Master-Thread
Parallele Ausführung
Automatische Synchronisierung
Schleifen mit OpenMP
Das Verfahren kann auch zu Problemen führen:
void test(double x[], double z[], int n){#pragma omp parallel for for(int i = 1; i < n; i++) { z[i] = x[i] + z[i – 1]; // Fehler!!! }}
Schleifen mit OpenMP
Häufig braucht man „Reduktionen“
• Es gibt mehrere Threads mit eigenen z-Variablen, die dann zum Schluss zum Endergebnis addiert werden
double test(double x[], int n){ double z = 0.0;
#pragma omp parallel for reduction(+:z) for(int i = 1; i < n; i++) { z += x[i]; }
return z;}
Variablen und Scope
Wenn mehrere Threads erzeugt werden, gibt es zwei Variablen-Arten:
• private: Jeder Thread hat eine eigene Instanz
• shared: Es gibt nur eine Instanz für alle Threads
Laufvariablen von Schleifen sind automatisch „private“
Kann man steuern:
#pragma omp parallel for shared(a, b) private(i, j)
Code-Regionen
Codeteile können ebenfalls parallel laufen
Anzahl der Threads kann angegeben werden oder ist vom System vorgegeben
void test(){ #pragma omp parallel num_threads(4) { Console::WriteLine(„Hallo, TechTalk!“); }}
Synchronisierung
Ist fast immer irgendwo erforderlich, wenn mehrere Threads laufen
• barrier
• critical
• critical(name)
• atomic• Operatoren: + - ++ -- * / & ^ | << >>
• master
• flush
• Runtime-Lock
Synchronisierung kostet Zeit!!!
OpenMP-Library
Es gibt diverse Runtime-Methoden in der OpenMP-Bibliothek:
• Max. Anzahl der Threads setzen oder abfragen
• Anzahl der vorhandenen Prozessoren abfragen
• Rückgabe einer eindeutigen Thread-Nummer
• …
OpenMP
Das hört sich ja sehr einfach an… …es kann aber auch sehr kompliziert
werden• Das sprengt aber den Rahmen hier!
Vorsicht beim Programmieren mit mehreren Threads ist IMMERIMMER wichtig• Immer die Performance prüfen
• Immer die Ergebnisse prüfen OpenMP ist gut für Algorithmen OpenMP ist nicht gut für die
Parallelisierung von User Interfaces
OpenMP-Performance
ACHTUNG: Performance-Tests sind mit Alpha- oder Beta-Versionen immer etwas kritisch!!!
Trotzdem:
• Einige Versuche…
• …auf Single-Prozessor-Maschine (P4, 2.4 GHz, ohne HyperThreading)
• …auf Dual-Prozessor-Maschine (P3, 600 MHz)
OpenMP-Performance
Schleifen-Parallelisierung (Demo16)Innere Schleife Threads ZeitSingleZeitDual
20,000 4 2.844 sek 9.937 sek10,000 4 2.284 sek 6.047 sek 5,000 4 2.083 sek 4.047 sek 2,500 4 1.973 sek 3.010 sek
20,000 4 2.844 sek 9.937 sek20,000 3 2.583 sek 8.791 sek20,000 2 2.393 sek 5.953 sek20,000 1 0.751 sek 9.812 sek
20,000 Ohne 0.631 sek 9.988 sek
OpenMP-Performance
Schleife mit Reduktion (Demo17)Schleife Threads ZeitSingleZeitDual
10,000,000 10 2.494 sek 9.922 sek10,000,000 6 2.484 sek 9.906 sek10,000,000 4 2.493 sek 9.937 sek10,000,000 3 2.473 sek 9.921 sek10,000,000 2 2.463 sek 9.890 sek10,000,000 1 2.524 sek 16.219 sek
10,000,000 Ohne 2.444 sek 15.853 sek
OpenMP-Performance
Synchronisierung mit „atomic“ oder „critical“ (Demo18 und Demo19)
Sync.-Typ Threads ZeitSingleZeitDual
Atomic 4 7.210 sek 27.501 sekAtomic 2 7.200 sek 27.438 sekAtomic 1 7.130 sek 15.609 sek
Atomic Ohne 1.242 sek 7.828 sek
Critical 4 9.245 sek 77.047 sekCritical 2 9.998 sek 76.344 sekCritical 1 8.482 sek 18.422 sek
Critical Ohne 1.242 sek 7.828 sek
Zusammenfassung
C++ Managed Extensions sind HEUTEHEUTE mit Visual Studio 2003 NICHTNICHT das Teil der Wahl• Umständlich
• Schwer zu lesen Aber C++ UNDUND .NET kommen wieder• C++/CLI
• Einfachere Syntax
• Gut lesbar, weniger “__” • Das gesamte .NET-Framework wird unterstützt
In Visual Studio 2005• Viele neue Features• Optimierungen, OpenMP,…
Wichtig im 64-bit-Umfeld
Buch über OpenMP
Parallel Programming in OpenMP
• R. Chandra, L. Dagum, D. Kohr, D. Maydan, J. McDonald, R. Menon
• Morgen Kaufmann Publishers
• ISBN: 1-55860-671-8
• Ca. 35 $
• Bei Amazon.de oder Amazon.com
Demos und Slides
Download unter:
Fragen?
Uff...Uff...