Discussion :

[epsilon68]

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?

[loufoque]

Ils fournissent pas vraiment la même chose

[epsilon68]

ils fournissent tous les deux le moyen de paralleliser...

[yan]

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.

[epsilon68]

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

[yan]

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

[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

[epsilon68]

oki je vais le faire mais je posais justement cette question

[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 :-/

[yan]

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

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

[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+

[yan]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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;
}

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

[epsilon68]

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

[yan]

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é

[yan]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[yan]

TU est sur que BOOST_FOREACH ne fait pas la même chose??

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

[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

[epsilon68]

mais BOOST_FOREACH marche vraiment bien.