Parallelisierung

@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?

drakon

Ist wahrscheinlich auch noch zu Low-Level für dich, aber POCO bietet auch Threads an:
http://pocoproject.org/slides/130-Threads.pdf

Ich 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?

l'abra d'or

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.

Drehleiter

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).