[Thread] TBB vs Qt Concurrent

Version imprimable

06/05/2008, 09h42
epsilon68

[Thread] TBB vs Qt Concurrent

Bonjour,

Faut-il utiliser TBB ou Qt Concurrent ?
sachant que j'utilise deja Qt pour l'interface graphique...

deja sont-ils compatible dans le sens que l'un ne fait pas crasher l'autre ?
sinon avec TBB peut-on surveiller la progression et si oui comment ? avec Qt ce sont les futures ... mais Qt Concurrent est-il vraiment bien du point de vue performance comparé à TBB?
06/05/2008, 10h13
loufoque

Ils fournissent pas vraiment la même chose
06/05/2008, 10h26
epsilon68

ils fournissent tous les deux le moyen de paralleliser...
06/05/2008, 11h41
yan

Citation:

Envoyé par epsilon68

Qt Concurrent est-il vraiment bien du point de vue performance comparé à TBB?

A mon avis il n'y as pas de raison que Qt concurrent soit plus lent que tbb ou OpenMP..
tbb sera peut être globalement un peu plus rapide sur les proc intel.
06/05/2008, 13h49
epsilon68

tu as déjà testé l'une ou l'autre lib?
06/05/2008, 13h54
yan

Citation:

Envoyé par epsilon68

tu as déjà testé l'une ou l'autre lib?

J'avais regardé un peu sans faire trop de test.
Ce n'est qu'un avis bien sur.
Faire deux trois test ne devrait pas prendre trop de temps.
Aprés faut savoir quoi tester
06/05/2008, 14h07
yan

Dans la version de Qt 4.4 (sortie ce matin) il y as des exemple utilisant Qt concurent.
Tu devrais pouvoir les refaire avec tbb pour comparer
06/05/2008, 16h45
epsilon68

oki je vais le faire mais je posais justement cette question :mouarf:
06/05/2008, 23h48
epsilon68

j'ai la forte impression en regardant Qt Concurrent que cela ne fonctionne que sur les conteneurs de Qt ? c'est ca ? si oui tres tres mauvais :-/
06/05/2008, 23h51
yan

Citation:

Envoyé par epsilon68

j'ai la forte impression en regardant Qt Concurrent que cela ne fonctionne que sur les conteneurs de Qt ? c'est ca ? si oui tres tres mauvais :-/

Pourquoi?
On peut utiliser des iterator :koi: :
http://qt.developpez.com/doc/latest/...#blockingMap-2
http://qt.developpez.com/doc/latest/...kingFiltered-2
http://qt.developpez.com/doc/latest/...tml#filtered-2
http://qt.developpez.com/doc/latest/...map.html#map-2
...
07/05/2008, 12h11
loufoque

C'est pas parce que la fonction prend un type nommé Iterator que ça veut dire que c'est compatible avec le concept d'itérateur standard.
Déjà il faudrait que ce soit des templates, pas des fonctions. (mais bon ça, c'est peut-être un problème avec leur doc)
07/05/2008, 12h28
epsilon68

moi je n'en suis pas du tout sur que ca marche avec les iterateurs standards, je n'arrive plus a retrouver ou j'avais lu "sur les conteneurs Qt".

ensuite si ca marche, ce n'est pas du tout sur qu'il soit optimal dans ce cas, par example QT_FOREACH marche tres bien pour les conteneurs Qt mais faire une copie pour les conteneurs standards.

Ils utilisent beaucoup le fait qu'ils utilisent partout le COW.

voila a tester donc.

a+

Citation:

Envoyé par loufoque

Déjà il faudrait que ce soit des templates, pas des fonctions. (mais bon ça, c'est peut-être un problème avec leur doc)

ce sont des template ;)

Citation:

Envoyé par epsilon68

moi je n'en suis pas du tout sur que ca marche avec les iterateurs standards, je n'arrive plus a retrouver ou j'avais lu "sur les conteneurs Qt".

ca marche
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 #include <QtGui> #include <vector> #include <cmath> void scale(double & d) { qDebug() << "sqrt "<<d<<"dans le thread : "<<QThread::currentThread(); d= sqrt(d); } int main(int argc, char *argv[]) { Q_UNUSED(argc); Q_UNUSED(argv); const int imageCount = 20; std::vector<double> myVect; for (int i = 0; i < imageCount; ++i) myVect.push_back(i); QFutureWatcher<void> futureWatcher; futureWatcher.setFuture(QtConcurrent::map(myVect.begin(),myVect.end(), scale)); futureWatcher.waitForFinished(); QtConcurrent::blockingMap (myVect, scale); return 0; }
Citation:

Envoyé par epsilon68

ensuite si ca marche, ce n'est pas du tout sur qu'il soit optimal dans ce cas, par example QT_FOREACH marche tres bien pour les conteneurs Qt mais faire une copie pour les conteneurs standards.

Tout dépend ce que tu fait. Mais tu aura le même problème avec tbb.
Tu as OpenMP aussi (plus proche du C). C'est ce qu'utilise les algo stl parallèle de gcc 4.? si je ne me trompe pas

07/05/2008, 15h44
epsilon68

un truc interessant, regarde si ta collection est copiée?
parce qu'avec QT_FOREACH c'est le cas, pas avec BOOST_FOREACH
07/05/2008, 15h58
yan

Citation:

Envoyé par epsilon68

un truc interessant, regarde si ta collection est copiée?
parce qu'avec QT_FOREACH c'est le cas, pas avec BOOST_FOREACH

C'est a dire?
si lors de l'appel a map il copie le vector? non il ne me semble pas et pourquoi il le ferait?

Pour QT_FOREACH je suis étonné

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
struct A
{
    A(const double & d =0.):m_d(d) {qDebug() << "create "<<d;};
    A(const A & a):m_d(a.m_d) {qDebug() << "copie "<<m_d;};
double m_d;
};
 
int main(int argc, char *argv[])
{
    Q_UNUSED(argc);
    Q_UNUSED(argv);
 
    const int imageCount = 1000;
 
    std::vector<A> myVect;
    for (int i = 0; i < imageCount; ++i)
        myVect.push_back(i);
 
    foreach (const A &str, myVect)
        qDebug() << str.m_d;
    return 0;
}

Si tu met la variable en const ref tu n'as plus de copie ;)

07/05/2008, 16h23
yan

TU est sur que BOOST_FOREACH ne fait pas la même chose??
07/05/2008, 16h40
epsilon68

j'avais ouvert un post ca fait assez longtemps,
http://www.developpez.net/forums/sho...d.php?t=345926

oui je suis sur que BOOST_FOREACH le faisait correctement.
maintenant peut-etre ca a changé dans Qt depuis ...
07/05/2008, 16h46
yan

q_foreach semble ne donné qu'un accés non éditable. D'où la copie quand tu n'utilise pas un const ref

Tu as aussi l'algo std::for_each
07/05/2008, 16h50
epsilon68

mais BOOST_FOREACH marche vraiment bien.
07/05/2008, 16h54
yan

Citation:

Envoyé par epsilon68

mais BOOST_FOREACH marche vraiment bien.

Alors utilise plustôt celui la. Le mélange boost et qt ne pose pas de problème normalement.
07/05/2008, 16h57
epsilon68

... mais ce n'etait pas le probleme
07/05/2008, 17h07
yan

je viens de tester donc non il n'y as pas de copie copie tant que ton fonctor utilise des references
08/05/2008, 09h16
epsilon68

c'est cool merci.

avec TBB c'est dur aussi de trouver des examples simple, en tout les cas aussi simple que Qt (une seule fonction)....

quelqu'un en aurait-il ?
29/07/2008, 09h03
epsilon68

voila, je viens juste de retrouver l'exact post qui confirme mon test sur Q_FOREACH

http://lists.trolltech.com/qt-intere.../msg00999.html

Citation:

Ian Reinhart Geiser wrote:
> Greetings,
> I want to make my container work with foreach.
> Is it documented the minimum set of methods I need
> to implement to make this happen? I can read the
> source if I have to, but I wanted to avoid that ;)

Be careful. Qt's foreach implementation (which I found pretty cool
actually because the interface 'just feels right') invokes the
container's copy constructor. So depending on your compilers
ability to optimize and the nature of your container this could
be quite expensive.

Qt's own container work rather well because they are shared, but
that's not necessarily true for your own stuff.

I once had quite some code written with 'foreach', but in the
end was forced to replace most of the uses with more traditional
constructs.

Andre'
29/07/2008, 09h12
yan

Salut.
C'est bien ce que l'on avais conclu, non?
As tu avancé sur ta comparaison tbb et QtConcurrent?
29/07/2008, 09h19
epsilon68

non, tu avais conclu qu'il ne faisait pas de copie si tu utilisais des references.

mais moi j'avais trouvé qu'il faisait des copies de la collection, et pas toi.
peut-etre il a changé depuis, ou bien ton compilo l'optimisait et pas le mien.

et sinon non je n'ai pas avancé sur la comparaison TBB vs Qt
je suis sur autre chose maintenant :-)
29/07/2008, 09h23
epsilon68

arg en plus c'est écrit dans la doc, je viens juste de le retrouver:

Citation:

Qt automatically takes a copy of the container when it enters a foreach loop. If you modify the container as you are iterating, that won't affect the loop. (If you don't modify the container, the copy still takes place, but thanks to implicit sharing copying a container is very fast.) Similarly, declaring the variable to be a non-const reference, in order to modify the current item in the list will not work either.
29/07/2008, 09h36
yan

Citation:

Envoyé par epsilon68

non, tu avais conclu qu'il ne faisait pas de copie si tu utilisais des references.

je viens de retester... et tu as bien raison :cry:.
Et j'ai compris ce que tu disait :aie:. Tu parlais de la recopie du contenaire, et mois de la recopie de l'élément dans la boucle(mais c'est aprés la recopie du contenaire que je n'avais pas vue avant).