Parallelisierung
-
Hi,
was gibt es eigentlich für Möglichkeiten (libraries etc) Programme für heutige Multicores optimiert zu schreiben?
Ich suche etwas das nicht ganz so low-level ist wie pure threads und futures. Gefunden habe ich einerseits z.B. die TBB von Intel, welche allerdings kommerziell sind.
Dann ist da z.B. noch boost.task (ehemals boost.threadpool?), da hab ich wiederum Angst dass das in der Versenkung verschwindet wie so manche libs die für boost gemacht wurden und nicht gereviewed/aufgenommen werden. Wär doof wenn ich jetzt etwas verwende was bald schon nicht mehr existiert bzw. gewartet wird. Und der letzte commit im boost-svn war vor 5 MonatenWas verwendet ihr so bzw. was ist zu empfehlen?
-
Ich benutze OpenMP für einfache Dinge und boost::thread wenn es komplexer wird.
-
Z.B. Posix-Threads mit eigenen C++ Wrapper, aber die willst du ja nicht. Boost::thread ist auch okay.
-
concurrencier schrieb:
Gefunden habe ich einerseits z.B. die TBB von Intel, welche allerdings kommerziell sind.
Das stimmt so nicht. Auszug aus der TBB fAQ:
How is TBB licensed?
TBB is dual-licensed, with a commercial (COM) license and a GPL v2-based open source (OSS) license. Please pay close attention to the usage restrictions each license uses to make sure you are using the proper version.
...
What is the OSS license and what does it offer?
TBB is available under the common OSS license GPL v2 with the libstdC++ Runtime Exception. This is the same license used for a variety of well-known OSS applications including MySQL, NetBeans, and the Linux kernel.
Lars
-
@knivil/brotbernd
Also boost.thread kenn ich natürlich, aber das ist auch nur ein etwas besserer Wrapper. Ich dachte eher an etwas das auch Work-Stealing, Sub-Tasking (am besten automatisch), evtl. verschiedene scheduling-Methoden usw. unterstützt.TBB is available under the common OSS license GPL v2 with the libstdC++ Runtime Exception.
Das mit der Runtime Exception hatte ich übersehen. Hab ich das richtig in Erinnerung dass ich das auch in kommerziellen Applikationen verwenden kann und nur die GPL nehmen muss wenn ich etwas ändere, oder wie war das?
-
Ist wahrscheinlich auch noch zu Low-Level für dich, aber POCO bietet auch Threads an:
http://pocoproject.org/slides/130-Threads.pdfIch habe sie nie benutzt, aber die Bibliothek sieht (auch sonst) im grossen und ganzen recht interessant aus.
-
Dann gäbe es nch QThread aus den QT Bibliotheken. Ist aber nicht wesentlich einfacher als boost oder c++0x threads. Ich finde die allerdings eigentlich recht handlich. Was willst Du denn damit machen, was sie Dir unhandlich erscheinen läßt?
-
Wenn schon Qt erwähnt wird, sollte nicht (nur) QThread gesagt werden, sondern vor allem QtConcurrent! Das verwaltet selber die Threads, in Abhängigkeit der verfügbaren Prozessoren. Das ist glaub ich eher in die Richtung, was der OP wollte.
-
concurrencier schrieb:
Das mit der Runtime Exception hatte ich übersehen. Hab ich das richtig in Erinnerung dass ich das auch in kommerziellen Applikationen verwenden kann und nur die GPL nehmen muss wenn ich etwas ändere, oder wie war das?
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01s02.html:
As a special exception, you may use this file as part of a free software
library without restriction. Specifically, if other files instantiate
templates or use macros or inline functions from this file, or you compile
this file and link it with other files to produce an executable, this
file does not by itself cause the resulting executable to be covered by
the GNU General Public License. This exception does not however
invalidate any other reasons why the executable file might be covered by
the GNU General Public License.Hopefully that text is self-explanatory. If it isn't, you need to speak to your lawyer, or the Free Software Foundation.
Lars
-
Intel TBB (als Open source verfügbar), Boost.Task (mit dem von dir angesprochenen Risiko), Microsoft PPL, sind m.E. die interessantesten Möglichkeiten. Die Intel lib unterstützt auch viele Patterns, wie Pipelines, und bietet auch Algorithmen für die einfachen Sachen, wie parallel_for.
Ansonsten ist ein std::async geplant, aber ich bin nicht auf dem Laufenden, ob man da zum Beispiel angeben kann, welcher Threadpool für den Task verwendet werden soll. Man kann afaik auch nicht subtasken. Und ich kenne keine Implementierung bisher.
Also wenn ich es mir recht überlege, siehe erster Absatz.Ist noch ein bisschen wenig Auswahl, aber ich hoffe ja eh auf das Boost-Zeug und dann braucht man in 99% der Fälle nichts mehr anderes.
-
Hier gibt werden einige Bibliotheken besprochen:
http://www.multicoreinfo.com/2009/08/parprog-part-9/Gruß
Drehleiter
-
@Optimizer: Ok, das ist die Info die ich gesucht habe... dann hoff ich mal auch dass das mit boost was wird. Wegen std::async: TBB wurde ja an das Standardkomitee eingereicht, ist das das? Wie auch immer, bis zum Standard wird das wohl noch dauern..
Qt.concurrency kann ich mir auch mal ankucken, ansonsten werd ich wohl echt bei boost bleiben und im schlimmsten fall muss ich halt doch alles refactoren..
-
Nein, die TBB sind wesentlich ausgefeilter und umfangreicher, als das async, was momentan diskutiert wird. Aber theoretisch kann daraus mal was vergleichbares werden. Wie gesagt, ich hab die Diskussion aber nicht genau verfolgt.
-
Ich hab mir nochmal kurz std::async angeschaut. Das ist wirklich extrem simpel gehalten, funktioniert aber z.B. schon in meinem gcc 4.5.1 2010050 prerelease.
Allerdings kann man da, so wie ich das gesehen habe, wirklich nur a) in ganz neuem Thread, b) synchron in einem Thread oder c) so wie es sich die Implementierung denkt gestartet werden.boost.task scheint mir wirklich der beste Kompromiss zu sein wenn man Komfort haben möchte und trotzdem sinnvolle Kontrollmöglichkeiten vorhanden sein sollen (z.B. verschiedene Scheduler).