PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Parallel Programming


pest
2009-12-11, 18:07:46
Habe gerade einen oben genannten Workshop hinter mir,
und nun hat es mich ein wenig gepackt mal daheim mit MPI (http://en.wikipedia.org/wiki/Message_Passing_Interface) und OpenMP (http://en.wikipedia.org/wiki/OpenMP) rumzuspielen, wobei MPI für Spielereien Overkill ist.

bisher dachte ich ja, man benutzt eine Bibliothek wie pthreads (http://en.wikipedia.org/wiki/POSIX_Threads), startet seine eigenen Threads und die Rechnen dann munter nebeneinander her.

Mit OpenMP ist dieses Vorhaben, imo viel einfacher und ziemlich elegant.

Wer benutzt das auf Win32 wie sind so eure Erfahrungen mit den oben genannten Standards und Bibliotheken?

Gruss

samm
2009-12-11, 20:21:06
Jo, hatte in einer Vorlesung über Systems Software von OpenMP gehört. Sah wirklich interessant aus. In den kommenden Monaten *könnte* ich in der Praxis damit zu tun haben & würde mich an dieser Stelle melden. *abonnier*

Mit pthreads habe ich schon gearbeitet, habe da aber nur zwei drei Spielzeug-Beispiele gemacht à la: quicksort mit Intervallaufteilung in eigene Threads falls lohnenswert. Ob lohnenswert oder nicht war abhängig von der Anzahl Prozessoren / Kerne und der Länge des zu sortierenden Arrays. Das ist inzwischen auch schon eine Weile her.

Trap
2009-12-11, 22:26:17
OpenMP ist sehr praktisch, wenn man Algorithmen mit Schleifen über unabhängige Daten hat, da ist man in wenigen Minuten fertig. Schön ist vor allem, dass man den Code nicht ändern muss, sondern nur Attribute hinzufügt. Damit hat man einen Code der überall läuft und wenn der Compiler OpenMP kann auch direkt mit Multithreading, ohne dass man sich um irgendwas weiter kümmern muss.

OpenMP funktioniert aber auf sehr niedriger logischer Ebene, wenn der Algorithmus nicht ins Schema passt, hilft es einem nicht mehr so viel.

http://www.threadingbuildingblocks.org/ hat etwas mehr Abstraktionen, dafür muss man mehr an der Anwendung ändern um es zu integrieren. Benutzt hab ich TBB aber noch nicht (außerdem ist es nur für Open-Source kostenlos).

Nasenbaer
2009-12-11, 23:11:09
OpenMP ist sehr praktisch, wenn man Algorithmen mit Schleifen über unabhängige Daten hat, da ist man in wenigen Minuten fertig. Schön ist vor allem, dass man den Code nicht ändern muss, sondern nur Attribute hinzufügt. Damit hat man einen Code der überall läuft und wenn der Compiler OpenMP kann auch direkt mit Multithreading, ohne dass man sich um irgendwas weiter kümmern muss.

OpenMP funktioniert aber auf sehr niedriger logischer Ebene, wenn der Algorithmus nicht ins Schema passt, hilft es einem nicht mehr so viel.

http://www.threadingbuildingblocks.org/ hat etwas mehr Abstraktionen, dafür muss man mehr an der Anwendung ändern um es zu integrieren. Benutzt hab ich TBB aber noch nicht (außerdem ist es nur für Open-Source kostenlos).
Ich habe mal irgendwo gelesen, dass OpenMP wesentlich mehr kann als nur dieses "#pragma for" oder wie das ging um For-Schleifen auf einzelne erne zu verteilen. Man soll damit wohl auch weit komplexere Probleme lösen können. Leider hab ich aber den Link nicht zu Hand. :/

Demirug
2009-12-12, 12:39:22
Wie wäre es mit http://openmp.org . Da gibt es auch die Beschreibung aller pragmas. OpenMP ist gut wenn man ein einzelnes Problem parallelisieren will. Man muss sich Allerdingdings bewusst sein das Overhead natürlich höher als bei einer guten nativen Lösung ist. Entsprechend kann eine Lösung die direkt mit Threads programmiert wurde schneller sein.

Für Problemstellungen bei denen viele kleine aber dennoch voneinander abhängige Probleme gelöst werden müssen (Spiele sind hier ein gutes Beispiel) funktioniert OpenMP eher schlecht. Das kommt daher das man mit OpenMP eher die kleinen Probleme in sich parallelisieren kann als die gesamten Problemblöcke miteinander. Entsprechend setzt man dann hier eher auf Job Manager. Die einfachste Form eines solchen Managers ist ein Threadpool wie er zum Beispiel durch die Win32 oder das .Net Framework angeboten wird.

Nasenbaer
2009-12-12, 16:34:46
Ich finde Qt bietet ne gute Abstraktion für die sonst eher hakelige WinAPI. Arbeitet praktisch genauso wie man das von Java her kennt, was ich persönlich recht komfortabel finde.
Boost soll wohl auch in Richtung Threads einiges bieten aber das hab ich mir noch net angeguckt.

Gast
2009-12-13, 15:06:11
ich mach mal wieder werbung für boost!
ab C++09 ist boost::thread teil des C++ Standards. Sehr einfach handhabbar, sehr mächtig.

mfg,
Alex

The_Invisible
2009-12-13, 16:35:21
ich mach mal wieder werbung für boost!
ab C++09 ist boost::thread teil des C++ Standards. Sehr einfach handhabbar, sehr mächtig.

mfg,
Alex

das könnten die aber so langsam auch auf c++10 umbenennen, bei c++0x wars ja noch einfach :D

mfg

robobimbo
2009-12-13, 20:48:51
x >= 9 && x <=99 stimmt c++0x immer noch - also habens noch ein wenig zeit

Gast
2009-12-14, 08:43:34
Inzwischen gibt der gute Herr sich bis 2015 Zeit :D

The standard is expected to be ready for national votes in 2010. After that there will be more work -- and most most likely a further 18 month of various delays -- before the comments have been addressed and the ISO bureaucracy satisfied. No features (even very minor ones) are expected to be added or removed after March 2010. The name "C++0x" is a relict of the days where I and others, hoped for a C++08 or C++09. However, to minimize confusion, I'll keep referring to the upcoming C++ standard with the feature set defined here as C++0x. Think of 'x' as hexadecimal.