Discussion :

[alskaar]

Salut,

pas de question pour une fois, juste pour filer un lien d'une lib qui me semble sympas

http://spc.unige.ch/mptl

[Charlemagne]

J'ai regardé 5 minutes le code (car il se fait tard), et ça me paraît effectivement intéressant.

Ca me fait penser sur le principe de la programmation générique à la librairie d'Intel: Threading Buiding Blocks (TBB). J'ai eu la version test beta, gratuite pendant plusieurs mois.
Cette dernière est beaucoup plus aboutie (même si j'aime pas complètement la syntaxe adoptée un peu lourde à mon goût), mais elle est payante...

[Charlemagne]

Finalement je révise sérieusement à la baisse ma première appréciation hâtive.
J'ai essayé vite fait la bibliothèque avec le programme livré en exemple de tri, et voici mes observations:

-Ca ne compile pas avec la STL de Visual ni avec STLport (conflits de surcharges de fonctions). Ca compile uniquement avec GCC et la STL par défaut.

-L'algorithme de tri est à vue de nez 10000 fois plus lent (si si, dix mille!) que l'algo livré avec la STL. Je vois pas l'intérêt dans ces conditions à multithreader un projet.

Edit: une faute d'orthographe!

[Alp]

Comparé à Boost.Thread, ca donne quoi?

[Charlemagne]

Aucune idée. C'est aux fans de Boost à faire l'expérience s'ils le désirent.
Y'a un algorithme de tri multithreadé dans boost? Il sait diviser les algos de la STL en threads?

[Alp]

Non, mais j'voulais dire faire une opération dans un thread pour chacun, par exemple, ce que ça donne niveau perfs.

[Charlemagne]

Je sais pas non plus.
De toute façon ça serait pas comparable.

[alskaar]

en dehors du tri je trouve la lib plutot sympas
pour effectuer des traitements identiques sur les N objets


Pour ce qui est du tri c'est pas terrible
leur algo est pas adapte au multithread
j'ai réécris une version pour 2 threads

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
 
 
 
#include <vector>
 
#include <mptl.h>
#include <mptl_algo.h>
#include <mptl_qsort.h>
#include <iterator>
#include <iostream>
 
 
#include <time.h>
using namespace std;
 
 
namespace mptl
{
 
template <typename Iterator>
class MPTLqsort
{
private:
    Iterator first, last; // Intervalle
 
public:
    // D´efinition des caract´eristiques
    typedef Iterator iterator1;
    typedef TwoIterators nIterators;
 
    // Constructeur de la classe MPTLqsort
    MPTLqsort(Iterator first_, Iterator last_): first(first_), last(last_) { }
    // Retourne les it´erateurs (pour rendre accessible
    // `a la librairie l’intervalle `a distribuer aux threads)
    Iterator getFirst1() { return first; }
    Iterator getLast1() { return last; }
    // Permet d’appliquer l’algorithme uniquement sur le sous-intervalle
    // [first , last ). Remarquons qu’il s’agit toujours du mˆeme
    // algorithme.
    void applyAlgorithm(Iterator first_, Iterator last_){ std::sort(first_,last_);}
 
};
 
 
template <typename Iterator>
MPTLqsort<Iterator> qsort(Iterator first, Iterator last)
{
    return MPTLqsort<Iterator>(first, last);
}
 
}
 
 
 
int main (int argc, char * const argv[])
{
    mptl::setNumThreads(2);
    std::vector<int> ::iterator it;
    int i=0;
    time_t deb,fin;
 
 
   std::vector<int> v1(100000000);
   std::vector<int> v2(100000000);
	for(it=v1.begin();it!=v1.end();++it)
	*it=i--;
 
 
 
    int pos=v1.size()/2;
 
    time(&deb);
	//sort mptl par defaut
	//mptl::sort(v1.begin(), v1.end());
 
	// new sort
	/*mptl::execute(mptl::qsort(v1.begin(),v1.end()));
    merge(v1.begin(),v1.begin()+pos,
          v1.begin()+pos,v1.end(),
          v2.begin());*/
 
    // sort STL
    //sort(v1.begin(), v1.end());
    time(&fin);
 
    cout<< "temps:"<<(fin-deb)<<endl;
}

[Charlemagne]

oui oui, y'a un coté sympa qui m'intéresse aussi
Dommage que ça marche pas sous Visual ou STLport. Je n'ai pas vraiment cherché à comprendre ce qui collait pas.
Dommage que l'algorithme de tri qui soit si lent.
J'ai pas testé le reste.

Sans avoir trop réfléchi au problème, j'aurais préféré une interface plus générale, un peu comme la Intel TBB mais sans sa lourdeur.

C'est le genre de chose qu'aurait dû implémenter Boost, et qui m'aurait convaincu de l'adopter. Car j'ai l'impression que le multithread de Boost se cantonne à faire des wrappers de <pthread> et d'autres librairies, mais il va peut-être "réinventer la roue"...

[alskaar]

le pb c'est qu il n y a pas de notion de mutex ou de conteneurs protégés
j'ai de tres bon resultats sur mon AMD 64 X2

niveau perfs ( Vista,Cygwin,gcc)
STL: 45s
MPTL: 155s
avec mon tri: 38s (~23s pour le trie des 2 ensembles, ~15s pour le merge des 2 resultats

c'est avant tout un pb d'algo y a certainement des tris adaptés au multithreads
style baquets enfin si quelqun en connait un performant