threadpool multi-coeurs, une utopie ?

Version imprimable

19/01/2010, 22h23
gorgonite

threadpool multi-coeurs, une utopie ?

Bonsoir,

Ma question est très simple... quelles sont les contraintes dans la création d'un threadpool afin que les threads soient "automatiquement répartis" sur les différents coeurs ?

j'ai commencé un prototype où j'ai banni toutes écritures concurrentes et toutes sections critiques... mais à part impossible d'avoir une répartition correcte sur les quatre coeurs du serveur (muni d'un Intel Core i7 960 si mes souvenirs sont bons, mais ce n'est pas encore le problème :?)

le fait de limiter le nombre de threads en fonctionnement grâce à une sémaphore implique de rester dans le même espace mémoire... est-ce le point bloquant ?

sinon, il me reste la possibilité de créer N processus, et d'envoyer explicitement les threads s'exécuter sur un coeur, mais j'aimerais éviter si possible de refaire le boulot de l'OS :aie:
19/01/2010, 23h49
The_badger_man

Tu as les Parallel Extensions dans le Framework 4.

Un article dessus: http://vincentlaine.developpez.com/t...el-extensions/

Plus d'infos
http://msdn.microsoft.com/fr-be/conc...lt(en-us).aspx
http://code.msdn.microsoft.com/ParExtSamples
19/01/2010, 23h53
gorgonite

Citation:

Envoyé par The_badger_man

Tu as les Parallel Extensions dans le Framework 4.

j'avais vu mais je tourne sur du 3.5 (et encore, je compte bien me limiter au 2 sur la plupart du code)

:merci:

edit : au passage, le lien pour télécharger parallel pour le framework 3.5 ne marche plus, il faudrait mettre à jour ;)
20/01/2010, 12h20
The_badger_man

C'est parceque ça n'existe plus :aie:

C'est seulement dispo pour le 4.0...
20/01/2010, 13h27
gorgonite

Citation:

Envoyé par The_badger_man

C'est parceque ça n'existe plus :aie:

C'est seulement dispo pour le 4.0...

j'ai remarqué... mais disons que Parallel a également quelques problèmes pour l'usage que je souhaite en faire (je ne serais sûrement pas le seul à utiliser la machine à un instant donné, et je ne saurais pas forcemment quand j'aurais droit de tout utiliser... un seul serveur de calcul réellement puissant pour un labo constituée de multiples équipes. et la communication n'est pas notre point fort ^^)
20/01/2010, 21h44
gorgonite

le problème vient de l'utilisation d'une sémaphore pour limiter le nombre de threads en fonctionnement, et ainsi espérer avoir une consommation mémoire un peu raisonnable... dès qu'on s'affranchit de cela (ie qu'on refait du truc bourrin à la Parallel.For :aie:), on n'a plus le problème :?
27/01/2010, 14h31
teddyalbina

Une bonne solution serait de créer une file de threads globale de taille N (n étant le nombre de cpu), et une file de threads pour chaque cpu.

Puis d'écrire un algo pour s'assurer que les threads soient le plus équitablement dans les piles.
27/01/2010, 15h18
zoubidaman

Question con: Le threadpool intégré à .Net ne prend pas déjà ce genre de problématique en charge?

Dans dotnet 3.5 ce sont des threads au sens Win32 du terme, le problème étant que le threadpool en soit ne fournit pas de mécanisme de partitionnement.

Un bout de code la dessus :

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
        public static void ParallelForEach<T>(IEnumerable<T> source, Action<T> action)
        {
            // Get the number of processors, initialize the number of remaining
            // threads, and set the starting point for the iteration.
            int numProcs = Environment.ProcessorCount;
            int remainingWorkItems = numProcs;
            int nextIteration = 0;
            int exclusiveUpperBound = source.Count();
            const int batchSize = 3;
            using (ManualResetEvent mre = new ManualResetEvent(false))
            {
                // Create each of the work items.
                for (int p = 0; p < numProcs; p++)
                {
                    ThreadPool.QueueUserWorkItem(delegate
                    {
                        int index;
                        while ((index = Interlocked.Add(ref nextIteration, batchSize) - batchSize) < exclusiveUpperBound)
                        {
                            // In a real implementation, we’d need to handle
                            // overflow on this arithmetic.
                            int end = index + batchSize;
                            if (end > 0)
                            {
                                if (end >= exclusiveUpperBound)
                                {
                                    end = exclusiveUpperBound;
                                }
                                for (int i = index; i < end; i++)
                                {
                                    action(source.ElementAt(i));
                                }
                            }
                        }
                        if (Interlocked.Decrement(ref remainingWorkItems) == 0)
                            mre.Set();
                    });
                }
                // Wait for all threads to complete
                mre.WaitOne();
            }
            // return
        }

27/01/2010, 16h02
zoubidaman

Il y a un exemple de partitionnement CPU dans les samples de la TPL:

http://blogs.msdn.com/pfxteam/archiv...9/9934811.aspx
29/01/2010, 09h48
gorgonite

Citation:

Envoyé par zoubidaman

Question con: Le threadpool intégré à .Net ne prend pas déjà ce genre de problématique en charge?

ben non... c'était moins bon que ma première version avec semaphore pour limiter le nombre de threads :?
29/01/2010, 09h49
gorgonite

Citation:

Envoyé par zoubidaman

Il y a un exemple de partitionnement CPU dans les samples de la TPL:

http://blogs.msdn.com/pfxteam/archiv...9/9934811.aspx

ça revient à utiliser Parallel... comme dit plus haut :aie: