Discussion :

[moldavi]

Bonjour.

C'est l'éternel dilemme. Tu changes l'éléctronique (double/quadri processeurs), mais tu dois rester compatible avec les couches logicielles au-dessus...

[boulo]

un programme a beau lancer 1 ou 100 theads, il utilisera toujours un seul CPU.
pour utiliser le multicoeur il faut lancer plusieurs process et non plusieurs threads.

En framework 3.5, nos essais sur un dual core montrent que l'on arrive à plus de 50% des ressources CPU (60% a 90% suivant les actions effectuées dans les threads), ce qui implique qu'un process avec plusieurs threads utilise les 2 cores.

[hegros]

oui c'est exact mais peut-être que pour optimiser les choses il faut passer par des API natives win32.

Beh non ce n'est pas exact. Ce ne sont pas les processus qui sont parallélisables ce sont les threads qui le sont.

[mickyoun]

En framework 3.5, nos essais sur un dual core montrent que l'on arrive à plus de 50% des ressources CPU (60% a 90% suivant les actions effectuées dans les threads), ce qui implique qu'un process avec plusieurs threads utilise les 2 cores.

Je fais un test là en .net 3.5 je reviens vers vous

[mickyoun]

Je viens de faire un test en mode console avec le framework 2 et 3.5
Le résultat est le même et contraire à mon idée, les deux core bosse à 100%.

Je serai curieux de voir ce que ça donne en C++.

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
 
using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
 
namespace MultiThreadCons
{
    class Program
    {
        static bool Actif = true;
        static void Main(string[] args)
        {
 
            ThreadStart ts = new ThreadStart(Program.thread);
            Thread t = new Thread(ts);
            t.Start();
 
            ts = new ThreadStart(Program.thread);
            t = new Thread(ts);
            t.Start();
 
            ts = new ThreadStart(Program.thread);
            t = new Thread(ts);
            t.Start();
 
            ts = new ThreadStart(Program.thread);
            t = new Thread(ts);
            t.Start();
 
            ts = new ThreadStart(Program.thread);
            t = new Thread(ts);
            t.Start();
 
            while(Console.ReadLine() != "exit");
 
            Actif = false;
        }
 
        static void thread()
        {
            while (Actif) ;
        }
 
    }
}

[Jerede]

Dès l'instant ou il y'a plusieurs threads, le système peut décider de les répartir sur les cores à sont goût, ce qui n'est pas possible avec un seul thread évidemment. C'est pour ça que le développement d'une application multithreaded c'est d'abord une façon de coder.
Après la PFX et la TPL sont là pour permettre de mieux paralléliser et organiser tout ça, d'éviter que le système en fasse un peu à sa tête, et donc d'accroître les perfs.

[cinemania]

la PFX et la TPL n'oblige pas le système à ne pas en faire à sa tête...

l'ordonnanceur des tâches du noyau système reste le maître absolu et en fera toujours à sa tête et pas à la tienne... les deux seules options possibles pour influer sur son comportement vis à vis de tes threads et de changer leur priorité et éventuellement leur affinité à un coeur/processeur.

effectivement dire que les threads ne sont pas gérés convenablement, est un peu abusé... aucun test réellement efficace ne permet de le déterminer, bien au contraire, des tests bien sentis auront plutot tendance à démontrer le contraire.

hors si dans dotnet 3.5 on arrive à démontrer qu'en développant en multithread on arrive à saturé tous les coeurs du processeur, il est indéniable que cet état de fait est également vrai pour dotnet 2, car entre dotnet 2 et dotnet 3.5SP1, il n'y a eu absolument aucune modification apportée à la CLR...
de toute façon la CLR recompile tout en natif, et une bonne partie des rouages que l'on prend pour acquis sont convertis en appels win32 implicites... par conséquent il aurait été assez ubuesque que les threads ne soient pas convenablement gérés.

Si l'expérience a été faite sur XP.. elle ne vaut rien, XP aillant une fâcheuse tendance à gérer les 2 cœurs (et pas 4 contrairement aux apparences... limitation d'XP oblige) n'importe comment.

quand à la division processus/thread pour la gestion de l'ordonnancement, dire que l'unité d'ordonnancement est le process et non le thread revient à se référer à quelque chose qui n'a été vrai que dans les toutes premières version de windows NT et jusque windows 95 pour le tout publique.

Croire que windows fait comme linux, (et encore linux en kernel antérieur au 2.6), est une idiotie sans nom, vu que rien que le modèle mémoire était, et est d'ailleurs toujours radicalement différent. Effectivement avant le kernel 2.6 et même encore après d'ailleurs, linux n'a jamais géré les threads... la lib pthread était une rustine, une surcouche, visant à faire croire au système que les threads étaient des processus.
L'unité atomique est bien le thread sous windows et donc dotnet, et sous de nombreux systèmes d'exploitations.

Donc effectivement, tu va te dire, oui mais il ordonne des processus, oui, quand les processus n'ont que le main thread à ordonnancer... et c'est encore assez souvent le cas dans les applications écrites en code natif.
En effet, dès lors que l'on travail en dotnet il est impossible de programmer en monothread... rien que dotnet travail lui même en multithread et utilise la threadpool, ce n'est pas pour rien qu'elle a été inventé.
toutes les tâches asynchrones se font en arrière plan dans des threads de la pool.
De plus à l'inverse d'une application standard winforms basique, où 1 main thread est utilisé pour pomper la file des messages, il faut savoir que tout applicatif en WPF utilise au minimum 2 threads.

Je doute que microsoft ait pris soin de multithreadé la plateforme, si la plateforme faisait un peu comme linux et gérait les threads elle même à la vas y que je te pousse... je sais que parfois ils ont des façons de faire étrange, mais tout de même... pas à ce point.

[hegros]

Je serai curieux de voir ce que ça donne en C++.

Cela ne va rien changer. Que se soit en C# ou en C++ ou autre chose c'est toujours le noyau du système d'exploitation qui ordonnance les threads selon son algorithme. Donc à partir du moment où ton thread ou ton processus à consommer son quantum de temps il est endormi et un autre devient éligible.

Il n'y a de vrai parallélisation qu'avec des machines qui possèdent plusieurs processeurs. Avec un seul processeur dual ou quatri coeur la parallélisation n'est qu'un artifice. En .NET 4 ce qu'il y a en plus(en gros) c'est une meilleure distribution des threads sur les processeurs (lorsqu'il y en a plusieurs biensûr..)

Pour revenir sur le problème, tu n'utilises peut-être pas 100% du CPU parce que ton programme n'a pas besoin de toute la puissance de ton processeur. Tu atteins par contre 100% (lorsque tu libères les objets) parce que justement la libération des objets consomme de la CPU en plus. Donc bravo tu as optimisé ton algorithme, l'objectif n'est pas d'utiliser 100% du CPU mais d'effectuer ses calculs et traitements dans les temps voulus.