Discussion :

[olidau]

Bonjour à tous,

Je développe une appli qui effectue un certain nombre de traitement sur un certain nombre de fichiers texte.
Mon problème est que le temps de traitement est très, très long.
Je me demandais si je pouvais forcer Windows à utiliser les 2 voir 4 coeurs.
J'ai regardé sur un double coeur, le processeur n'est effectivement utilisé qu'à 50% avec seulement mon appli qui tourne.

Quelqu'un aurait-il des éléments de réponse ?

Merci d'avance.

[Paul TOTH]

Bonjour à tous,

Je développe une appli qui effectue un certain nombre de traitement sur un certain nombre de fichiers texte.
Mon problème est que le temps de traitement est très, très long.
Je me demandais si je pouvais forcer Windows à utiliser les 2 voir 4 coeurs.
J'ai regardé sur un double coeur, le processeur n'est effectivement utilisé qu'à 50% avec seulement mon appli qui tourne.

Quelqu'un aurait-il des éléments de réponse ?

Merci d'avance.

pour 2 coeurs il faut 2 thread

[olidau]

Ah ben merci, c'est pas plus compliqué.
Je vais m'y essayer ce WE.
Je suppose que le système va adresser de lui-même le 2e thread au 2e coeur ? (c'est c.. comme question ?)

[ShaiLeTroll]

La Gestion des Multi Coeurs\Proc est assez complexe, normalement, il va passer ton thread si l'autre processeur si le 1er est déjà très occupé, ... bon après, il peut passer du temps à vouloir changer les threads de coeur selon son humeur ...

[Franck SORIANO]

Oui enfin qu'en même. Il ne va pas faire ping pong d'un coeur à l'autre sans raisons.
Windows va utiliser tous les CPU disponibles pour exécuter un maximum de thread activables possibles.
Si un thread exécute une entrée/sortie, il va être suspendu lorsqu'il sera en attente du résultat. Lorsqu'il redeviendra activable, Windows va utiliser le premier coeur disponible pour l'exécuter, donc l'exécution pourra se poursuivre sur un autre coeur.
Si le thread ne fait pas d'E/S et monopolise le CPU de façon continue, il pourra se faire préempter à la fin de sa fenêtre d'exécution (en gros toutes les 10-15 ms). A ce moment là, un autre thread activable pourra lui chipper le coeur sur lequel il se trouvait.

Mais dans la pratique, en général le coeur qui execute le thread on s'en fiche (mis à par pour les caches mémoires, mais je doute qu'on en soit là)... ce qui compte c'est que les threads s'exécutent.

Maintenant avant de multi-threader, il faut peut-être commencer par regarder les traitements que tu fais. Si c'est si long que ça, il y a certainement matière à optimisation.

[Mac LAK]

Je rejoins Franck sur le chapitre de l'optimisation : faudrait peut-être aussi voir à vérifier que tu n'as pas un algo poussif... Et cela peut aller assez vite : utiliser un TStringList (au lieu d'un THashedStringList) dans des fonctions lourdes de manipulation de chaînes te fait exploser le temps CPU, par exemple !

Ensuite, il faut séparer ton traitement en plusieurs threads : s'ils demandent de gros accès mémoire, il te faudra souvent N+1 threads (N étant le nombre de cœurs) pour arriver au maximum de performances. S'ils n'ont que de très faibles accès mémoire, il ne faut alors jamais dépasser N threads.

L'idéal est quand même de les répartir manuellement sur les cœurs, de façon à s'assurer qu'un processus en tâche de fond ne "bouffe" pas un cœur, le rendant inaccessible à ton programme... Augmenter les priorités, en plus de la répartition manuelle, est souvent la solution permettant de s'affranchir des processus tournant sur la machine. N'oublie pas de prévenir l'utilisateur que ça va sûrement "geler" en partie les processus derrière, quand même.

Un petit bout de code pour t'aider à gérer ça, via la modification manuelle des affinités CPU de chaque thread :

Code Delphi (Interface) :

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
Uses Windows, SysUtils ;
 
    // Objet de gestion des affinités processeur.
    TCPU = Class
 
    Protected
      FCPUMask  : Array[0..31] Of Boolean ;    // Mapping physique des processeurs autorisés pour le processus courant.
      FCPUMap   : Array[0..31] Of Cardinal ;   // Mapping logique des processeurs, contient un masque d'affinité.
      FCPUCount : Cardinal ;                   // Nombre de processeurs utilisables, conditionne la limite supérieure de CPUMap.
 
      // Accesseur "Count".
      Function GetCPUCount : Cardinal ;
 
    Public
      // Constructeur
      Constructor Create ;
 
      // Récupération du nombre de CPU / coeurs du système.
      // Les processeurs sont ensuite numérotés de 0 à (Count-1).
      Property Count : Cardinal Read GetCPUCount ;
 
      // Force le thread courant à basculer sur le processeur passé en paramètre.
      // Lève une exception en cas d'erreur.
      // Ne lève PAS d'erreur (mais ne fait rien non plus) en cas de numéro de CPU invalide.
      Procedure SwitchTo ( Const CPUIndex : Cardinal ) ;
 
    End Platform ;

Code Delphi (Implémentation) :

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
{ TCPU }
 
constructor TCPU.Create;
begin
     // Initialisation des structures d'affinité processeur.
     FCPUCount:=0;
     FillChar(FCPUMask,SizeOf(FCPUMask),0);
     FillChar(FCPUMap,SizeOf(FCPUMap),0);
     // Calcul direct du nombre de CPU.
     GetCPUCount;
end;
 
Function TCPU.GetCPUCount : Cardinal ;
Var
   I, ProcessMask, SystemMask : Cardinal ;
Begin
     // Inutile de tout déclencher si on a déjà le nombre de CPU...
     If (FCPUCount=0) Then
        Begin
        // On va récupérer le nombre de CPU.
        FCPUCount:=0 ;
        // On compte les bits d'affinité.
        Win32Check(GetProcessAffinityMask(GetCurrentProcess,ProcessMask,SystemMask));
        // Bon, on a le masque : on va calculer sa taille.
        For I:=0 To 31 Do
            Begin
            // Explosage du masque binaire vers un tableau de booléens.
            FCPUMask[I]:=(ProcessMask And (1 Shl I))<>0 ;
            // On compte les CPU utilisables, et on crée la map d'assignation.
            // Le contenu de CPUMap, à l'indice donné, est donc le masque d'affinité à utiliser.
            If FCPUMask[I] Then
               Begin
               FCPUMap[FCPUCount]:=(1 Shl I) ;
               Inc(FCPUCount);
               End;
            End;
        End;
     // Le nombre de CPU est correct quel que soit le cas, on renvoie donc le résultat.
     Result:=FCPUCount ;
End;
 
Procedure TCPU.SwitchTo ( Const CPUIndex : Cardinal ) ;
Begin
     If (CPUIndex<FCPUCount) Then
        If (SetThreadAffinityMask(GetCurrentThread,FCPUMap[CPUIndex])=0) Then
           RaiseLastOSError ;
End ;

Il te suffit de créer un singleton "TCPU" dans ton code, d'appeler au moins une fois Create pour l'initialiser, et ensuite tu bascules n'importe quel thread sur n'importe quel coeur via la méthode "SwitchTo".
Pour ma part, je mets un TCPU public dans l'unité, puis je l'initialise dans la section INITIALIZATION de mon unité.

[Franck SORIANO]

L'idéal est quand même de les répartir manuellement sur les cœurs, de façon à s'assurer qu'un processus en tâche de fond ne "bouffe" pas un cœur, le rendant inaccessible à ton programme... Augmenter les priorités, en plus de la répartition manuelle, est souvent la solution permettant de s'affranchir des processus tournant sur la machine.

Augmenter les priorités : Okay. Ca permettra de passer majoritairement avant un processus en tâche de fond.
En revanche jouer avec les affinités pour affecter manuellement les threads aux coeurs, je ne vois pas en quoi ça va améliorer les perfs !
Tu risques surtout de te retrouver dans un cas ou au moment d'activer ton thread définit pour le coeur 1, ce dernier ne puisse pas être activé parce que le coeur 1 est déjà occupé par un autre traitement, alors que le coeur 2 se tourne les pouces car ton thread 2 est bloqué sur une E/S.

Le seul gain potentiel que je vois c'est si en changeant de coeur il faut recharger le cache mémoire. Mais je doute qu'on en soit là.

[Mac LAK]

En revanche jouer avec les affinités pour affecter manuellement les threads aux coeurs, je ne vois pas en quoi ça va améliorer les perfs !

Tout simplement en interdisant aux threads d'être déplacés de cœur en cœur, et d'être certain de ne pas être réduit à n'en utiliser qu'un seul le temps que le scheduler se rende compte que ça serait une bonne idée de les déplacer.

Tu risques surtout de te retrouver dans un cas ou au moment d'activer ton thread définit pour le coeur 1, ce dernier ne puisse pas être activé parce que le coeur 1 est déjà occupé par un autre traitement, alors que le coeur 2 se tourne les pouces car ton thread 2 est bloqué sur une E/S.

C'est pour ça que je parle de N+1 threads s'ils utilisent beaucoup d'accès mémoire, afin justement de répartir ces accès... En règle générale, après le premier accès, les threads se synchronisent tout seuls sur les divers coeurs, le "+1" n'est là que pour boucher les trous.

Le seul gain potentiel que je vois c'est si en changeant de coeur il faut recharger le cache mémoire. Mais je doute qu'on en soit là.

En calcul massif, vaut mieux éviter de présupposer quoi que ce soit : on arrive souvent à des choses pas tout à fait "logiques" dans pas mal de cas.

[olidau]

Merci à tous pour ces précieuses info.
Je vais pouvoir commencer à m'essayer au multi-threading...

J'ai encore une question à poser avant de commencer :
Comment tester le nombre de coeurs du proc ?
Il me serait très utile de savoir si je dois scinder la charge de travail en 2 ou en 4 s'il s'agît d'un quad, sans être obligé de re-coder.

Merci d'avance.

[FullSpeed]

En relire ton probleme n'est passoluble par multitreading ou multi processe.

Il nécessite l'usage de plusieurs disque et a ce moment la on peux envisager
d'utiliser des cœurs differents

Ton problème est ton nombre de lectures et d'écritures on peut diviser ce nombre autant de fois que l'on veut le total restera le même et c'est lui qui 'plombe' les performances
Ton application ne pourra jamais ecrire (ou lire) a deux endroits differents
Par contre si tu a plusieurs disques le pilote saura les gerer .

Attention a une grosse erreur souvent faite avec le multitreading que l'on utilise comme un simple multitube
On dit que le multitreading, et c'est vrai, utilise les ressources inocupées. Oui mais on se trompe de ressource. Celles qui interesse le multitreadfing se ne sont pas le HD ou la vidéo mais les ressources du PROCESSEUR et c'est en cela qu'il se differencie des process, multi tache ou multicoeur

Rapidement le plus gros travail quand un appli se deroule est de fournir un flux continu au processeiur: memoire cache, etages, predicateur tout le monde bosse pour le pipeline
On ne peut guere influer dessus. Par comodité on dira que c'est impossible


Bon maintenant notre proc il a du boulot un max mais il a des assistant: le shiffteur, le mmX, le multiplicateur ...

Donc il recoit par exemple un SHR alors il; appelle le shifter et en interdit l'usage le temps qu'il en a besoin et le libère ensuite

Mais cela intéresse qui de savoir que le shifter est occupé? Ie: ll n'y a que le pros qui s'en sert?
Le multithreader: grossomodo il sait faire le même boulot que processeur mai il est logique pas physique
Donc le multiT il voit que le shifter est occupe mais lui il a besoin du SSE alors il le met occupé et s'en sert
Si tu as deux treads qui utilisent l'UAL aucun gain a espéré par contre une image et un teste tres cool: une sur le MMX et l'autre le SSE2 le gain est clair
Pour gerer ton disque dur ce n'est pas le processeur qui s'en occupe s'est le pilote. Alors si tu as de gros besoin disque la solution est de multiplier les disques pour soulager le pilote et éventuellement des buffers à la place des acces répétés(des blockRead ou Blockwrite redoutablement efficace).
Le multitreadert s'occupe du taux de charge pas du temps
C'est la base pour bien comprendre la distribution
Je pense que les spécialistes sont de mon avis(mais ils peuvent bien sur ,ne pas l'etre).
Mais sueur et transpiration au programme...
Boris

[Franck SORIANO]

Comment tester le nombre de coeurs du proc ?

C'est très simple, il suffit d'appeler la fonction GetSystemInfo. Le champ dwNumberOfProcessors de la structure retournée t'indiquera le nombre de CPU (Processeurs ou coeurs) de la machine.

Pour répondre à FullSpeed, comme on l'a dit, avant de multi-threader, il faudrait d'abord regarder s'il n'y a pas moyen d'optimiser...

Le multi-threading peut de permettre d'améliorer les perfs, dans les cas suivants :
- Si tu mélanges calculs CPU lourds et accès disques : Dans ce cas, un thread pourra faire des calculs pendant qu'un autre réalisent des accès disques. Pour celà, pas besoin d'avoir plusieurs coeur.
- Si tes traitements consomment beaucoup de CPU, et que tu peux demander à plusieurs threads de faire chacun une partie de travail.

D'après ce que je comprends, tu es sur un traitement du genre traitement batch, qui brasse plusieurs fichiers, probablement plus ou moins indépendants les uns des autres.
Donc tu dois pouvoir multi-threader facilement le tout en mettant un thread par fichiers à traiter (enfin à rapporter au nombre de CPU).

Tu dis qu'actuellement, tu es déjà à 50% de consommation CPU, donc ça veut dire que c'est bien le CPU qui sature et pas les accès disques. Tu ne trouves donc pas dans le premier casde figure que je citais.

FullSpeed: Tu confonds l'Out-of-Order execution obtenue avec l'architecture en pipeline, qui permet à un seul CPU d'exécuter plusieurs instructions à la fois si elles sont suffisamment indépendante, et multi-threading qui permet à deux programmes indépendants de s'exécuter chacun dans son coin sur un processeur complet indépendant de son voisin (ou presque...).
Dans le cas du multi-coeur, chaque coeur est un processeur complet, avec tous les circuits (UAL, Shiffter, ....) dupliqués !
La principale différence entre multi-coeur et multi-processeur, c'est que dans le multi-coeur, les processeurs sont intégrés sur la même puce !

[FullSpeed]

- Si tu mélanges calculs CPU lourds et accès disques : Dans ce cas, un thread pourra faire des calculs pendant qu'un autre réalisent des accès disques. Pour celà, pas besoin d'avoir plusieurs coeur.
- Si tes traitements consomment beaucoup de CPU, et que tu peux demander à plusieurs threads de faire chacun une partie de travail.

Pas d'accord

Les treads sont plus rapides uniquement si elles utilisent ders ressources processeur différentes ton pilote HD est commande par l'UAl et le fait de changer de tread ne change rien pour le pilote.

Si on parle exclusivement de mufti cœur il y a bien distribution car chaque cœur a son environnement propre et et propre ual.
Par contre le goulot d'étranglement n'est pas au niveau pros mais ilote disque or le pilote il est mono tache sur un disque comme la mémoire
Pour moi la solution est donc d'avoir plusieurs disques
Si tu prends un SCSI par exemple le pilote reçoit un ordre pour le periph 4 il le pose sur le bus. Le perif 4 le voit ,le prends et le traite en signalant qu'il est indisponible. Si un autre ordre arrive pour le perif 4 il est mis sur le bus mais ne sera prit que quand le 4 aura fini alors que si l'ordre est pour le perif 5 il est pris immédiatement et traité

Que l'ordre arrive d'un cœur précis,d'un processus ou d'un tread il sera traité identiquement

Comme un HD cela doit aller 1000 fois, minimum, plus lentement qu'un processeur il est beaucoup plus efficace de se pencher sur les disues:
Deux disques et tu vas déjà deux fois plus vite.
Avec le code difficile d'arriver la

Tu confonds l'Out-of-Order

Je ne sais pas ce que c'est mais j'ai la chance d'avoir payé des études a un architecte processeur qui vit a la maison: il faut bien que cela serve!

Merci de ta repopnse argumentee

[FullSpeed]

Tu doies avoir commis une erreure frappe (je sais venant de moi..)
quand tu dis

multi-threading
qui permet à deux programmes indépendants de s'exécuter chacun dans son coin sur un processeur complet indépendant de son voisin (ou presque...).

Les treads existaient bien avant les mufti cœur

Toi qui aime bien les treads(c"est pas u n reproche)tes utilisateurs de vieux 32 bits comment ils font tourne tes logiciels multitreadés?
Demande a Shai si Son P IV n'est pas multitread?
Les mufti cœurs sont conçus pour la distribution de traitement
et éventuellement ils améliorent d'autres technos

Précision: les multicoeurs sont bien des pros séparés mais ils ont uin circuit en commun: le cache data Sans doute a cause du prix

Boris

[Franck SORIANO]

Tu doies avoir commis une erreure frappe (je sais venant de moi..)
quand tu dis

Les treads existaient bien avant les mufti cœur

Tu as pris la moitié de ma phrase, tu l'as sortie de son contexte, et tu essaies de me faire dire autre chose...
Je parlais du multi-threading qui permet à deux programmes de s'exécuter en parallèle par opposition à l'out-of-order execution qui permet, dans certains cas (que tu as très bien expliqués d'ailleurs) à plusieurs instructions d'un même programme de s'exécuter simultanéments !

Citation:
Par contre le goulot d'étranglement n'est pas au niveau pros mais ilote disque or le pilote il est mono tache sur un disque comme la mémoire
Pour moi la solution est donc d'avoir plusieurs disques
Si tu prends un SCSI par exemple le pilote reçoit un ordre pour le periph 4 il le pose sur le bus. Le perif 4 le voit ,le prends et le traite en signalant qu'il est indisponible. Si un autre ordre arrive pour le perif 4 il est mis sur le bus mais ne sera prit que quand le 4 aura fini alors que si l'ordre est pour le perif 5 il est pris immédiatement et traité

Que l'ordre arrive d'un cœur précis,d'un processus ou d'un tread il sera traité identiquement

Comme un HD cela doit aller 1000 fois, minimum, plus lentement qu'un processeur il est beaucoup plus efficace de se pencher sur les disues:
Deux disques et tu vas déjà deux fois plus vite.

Les disques pourraient être un goulo d'étranglement, mais tu oublies une chose : La consomation CPU est déjà à 50 %, ce qui indique qu'il y a saturation d'un des coeurs !
Si la saturation venait des disques, le CPU ne recevrait pas les données dont il a besoin pour travailler. Il serait bloqué en attente des accès disques et le CPU ne serait pas à saturation !
Dans le cas qui nous intéresse, c'est bien un problème de saturation CPU !
Le multi-threading permettra au PO d'utiliser le deuxième coeur disponible afin d'utiliser toutes les ressources CPU, et donc augmenter la consomation CPU au delà de 50%.

- Si tu mélanges calculs CPU lourds et accès disques : Dans ce cas, un thread pourra faire des calculs pendant qu'un autre réalisent des accès disques. Pour celà, pas besoin d'avoir plusieurs coeur.
- Si tes traitements consomment beaucoup de CPU, et que tu peux demander à plusieurs threads de faire chacun une partie de travail.

Pas d'accord

Les treads sont plus rapides uniquement si elles utilisent ders ressources processeur différentes ton pilote HD est commande par l'UAl et le fait de changer de tread ne change rien pour le pilote.

Si on parle exclusivement de mufti cœur il y a bien distribution car chaque cœur a son environnement propre et et propre ual.

Désolé, mais c'est que tu n'as rien compris aux threads et au multi-threadings en général.

Les threads ont deux usages :
- Lorsque ton programme fait un accès disque, (ou une E/S d'une façon générale), c'est le périphérique qui va travailler. Et ce dernier n'a pas besoin du processeur pour fonctionner. Ton programme est bloqué et attend que le périphérique ait fini son travail.
Dans ce cas de figure, le multi-threading va permettre de donner la main à un autre thread, et permettre à une autre tâche d'utiliser le processeur pour s'exécuter. Cet usage est le seul qui soit utilisable dans une configuration avec un seul CPU (mono coeur, mono processeur).

- Lorsque ton programme fait réellement de gros calculs, et que tu veux exécuter plusieurs traitements en même temps : Dans ce cas, il te faut plusieurs unités d'exécution, donc plusieurs CPU.
Chaque thread vivant sa vie sur un CPU.

Tu confonds l'Out-of-Order execution ... et multi-threading

En fait, je suis en train de me dire que tu mélanges peut-être avec l'hyper-threading également.

[FullSpeed]

Les mutli cœur

Il s'agit de processeurs possédant plusieurs UAL les coeurs.
Tum'as apris que chaque coeur poissedait l'integralité des ressources
en X exemplaires

Le pipe line:
Ce n'est ni un circuit, ni une architecture ,ni u,ne salle d'attente pour instructions en mal de CPU
Il s'agit en fait des différentes étapes dans lesquelles passent les instructions depuis ton code jusqu'au traitement du resultat. Avant d'arriver au CPU on appelle cela les 'etages' Les etages ne font qu'un dans le sens quie si il y a une erreuir dans n'importe lequel des étages il faut le vider completement et repartir. Pas de résultat intermédiaire
Toutes les instructions sur tous les ordinateurs du monde passent par différentes étapes et ont donc 'pipeline'

Les traitements multiples

Le multiitache: tu as plusieurs traitement qui résident en mémoire et a tour e rôle (les interruptions) le processeur leur consacre l'intégralité de ses ressources

Le mufti processeur : deux ordinateurs avec un seul clavier,ecran, chacuin travaille dans son coin avec ses propres ressources et données.

Le multitraitement : se n'est pas un partage de tempos mais de ressouirces
qui rebouche sur un gain de temps
Comme je l'ai dit ton processeurs utilise X % de ses possibilités: le treading essaye d'améliorer le nombre de ressources

A prés tu as les périphériques que dirigés par leur pilote et leur bus.A chaque perchlorique son pilote et le pilote est donc monotache: on affiche qu'une image à la fois, on ne lit qu'un fichier à la fois

Pour notre cas il faut séparer deux choses: les calculs et l'acces au disque
Je pense que notre ami se trompe sur les50% de CPU en toute bonne fos
Mais il a du utiliser le gestionnaire de tache et prendre le nombre. Avec Delphi tu as toujours 50! et si tu relances l'application il prends un nouveau coeur e de nouveau 50 (sur un Core Duo)
on depasse largement les 100
tu sais comme moi le travail que reprente 50% de la CPU pour unappareiolmlmage de fichiers c'est enormes.
Non moi je rete convaincu que proportionnellement le CPU ne fait rien ou peu. Etbque de toutes façons tu attendra ton disuqe . Meme un multiplicativement de celui ci ne changera rien: le micro contrôleur du disque ne fait qu'une chose a la fois. Point de salut hormis des disques multiples.

Comme promis j'ai interroge ma bible person qui m''a explmiqué se qu'est le Out of Order. Je n'ai pas bien compris pourquyoi tu en parles 'excuses moi): il s'agit semble t il de l'ordre dans lequel le micro code des instructions est exécutes. Tous les pros en on un t on ne sait pas lequel(Order)
De ce que j'ai compris c'est le deroulement de l'instruction elle même: le processeur sait mieux que nous comment il doit s'y prendre.


Alors maintenant tu prends un énorme livre tout blanc et on va attaquer se que je ne sais pas

Ma grande interrogation etant il faut 2 cycles pour faire une multiplication sur un processeur moderne. Pourquoi lui en faut-il 60 pour une division. Concrètement on a une suite d 'addition ou de soustraction pourquoi cette différence?(et sur un RISC a-t-bn les mémés diofferenvces)

Boris

[Franck SORIANO]

Bon on s'éloigne du sujet là...

Je ne pense pas que olidau soit venu pour qu'on lui fasse un cours sur l'architecture des processeurs.

Alors je me contenterais de répondre à ça :

Je pense que notre ami se trompe sur les50% de CPU en toute bonne fos
Mais il a du utiliser le gestionnaire de tache et prendre le nombre. Avec Delphi tu as toujours 50! et si tu relances l'application il prends un nouveau coeur e de nouveau 50 (sur un Core Duo)
on depasse largement les 100

Je ne vois pas pourquoi. C'est bien le gestionnaire de tâche qui te dit la charge CPU de la machine.
Et non, une appli Delphi correctement écrite ne consomme pas 50% de CPU parce que tu l'as lancée. Si le gestionnaire de tâche te dis que tu es à 50% (avec un 2-CPU) c'est que ton appli fait une boucle ou quelque chose et monopolise ne processeur, sans réaliser d'E/S !

tu sais comme moi le travail que reprente 50% de la CPU pour unappareiolmlmage de fichiers c'est enormes.

C'est énorme en effet, mais tout dépend des traitements réalisés. Et ici le PO ne nous a rien dit !
C'est bien pour ça que je disais qu'il y a certainement matière à optimisation avant de passer à du multi-threading.

[FullSpeed]

si tu fais une boucle infinie et que tu lances tui as 50%
si tu en lance une deuxième elle te dt 50
De fait chaque tache occupe pleinement son coeur
il divise donc la les 100 part le nombre de coeur

Mais cela ne signifie pas que le pros travaille mais qu'il est occupe: et oui il attends le pilote de disque et il sature
Essaye tu fais un block resad de deux gigas:
le code lance le rewrite et n'en sort pas avent 30 secondes: le pros ne bossait pas mais il attendait que l'instruction soit finie
Donc pour aller plus vite il faut aller dans un autre cœur et lancer une I/0 DIFFERENTES. Il faut se mettre en situation de deux ou trois machine avec une cpu commune oui pas mais surtout des disques différents. Je n'en demorre pas: tu satures déjà ton HD Iml a pas besoin d'ordre supplemlentaires au contraire

C'est assez simple a voir : tu lances deux fois l'application sur la meme machine tu notes le temps et tu recommences en te servant de deux disques
pas des partitions Je te parie que la deuxième ira deux fois plus vite

Pour notre ami je pense que si son appli est gourmande en I/O il faut mettre les choses au clair très vite: usage de disques durs rapide et données reparties sur plusieurs disques

Si les serveurs de fichiers cherchent a voir un maximum de bus en I/0 pas de puissance cpu! Et pourquoi ?

Boris

[olidau]

C'est très simple, il suffit d'appeler la fonction GetSystemInfo. Le champ dwNumberOfProcessors de la structure retournée t'indiquera le nombre de CPU (Processeurs ou coeurs) de la machine.

Merci Franck, c'est l'info dont j'avais besoin.

Je ne comprends pas bien la remarque de FullSpeed.
Le multi-threading est bien la solution à mon problème :

Si je lance l'appli bêtement, ma machine (double-coeur) ne tourne qu'à 50%.
Si je lance 2 instances de mon appli, la machine tourne à 100%.

Par conséquent, il faut bien que je développe une appli multi-threading, de façon à ne lancer qu'une seule instance de mon appli.

[Mac LAK]

Merci Franck, c'est l'info dont j'avais besoin.

Attention : ça, ça te retourne le nombre de processeurs sur la machine... Et non pas le nombre de processeurs utilisables par ton application !!
Pour ce dernier, tu regardes la classe que j'ai donnée en première page, la propriété "Count" te renverra le chiffre réel... Et la méthode "SwitchTo" te permettra de changer de coeur.

Par conséquent, il faut bien que je développe une appli multi-threading, de façon à ne lancer qu'une seule instance de mon appli.

Il a raison sur un point de détail, en fait : multi-threader sur une ressource critique / unique n'apporte pas toujours de gain, car un seul thread peut l'exploiter à un instant T.
Or, le disque EST une ressource critique... Sauf si tu as un pilote de disque correct qui gère les files d'attente afin de satisfaire au plus vite les demandes (ce que fait par exemple mon contrôleur RAID chez moi).

D'où la nécessité, peut-être, de déployer un thread de plus que le nombre de cœurs, afin d'occuper certains "temps morts" que pourrait provoquer cet accès "critique". Mais ça, c'est à vérifier au cas par cas, cela dépend beaucoup trop de l'algo utilisé et du type de traitement que tu vas effectuer.

[olidau]

D'où la nécessité, peut-être, de déployer un thread de plus que le nombre de cœurs, afin d'occuper certains "temps morts" que pourrait provoquer cet accès "critique". Mais ça, c'est à vérifier au cas par cas, cela dépend beaucoup trop de l'algo utilisé et du type de traitement que tu vas effectuer.

Oui, tout à fait, c'était bien mon intention : créer 2 threads par coeur, pour être sûr du coup, en leur affectant la priorité la plus haute.
Pour le reste... on verra le résultat.