Discussion :

[altozinzin]

Salut tout le monde!

Voila, j'ai 4 tableaux qui chacun doivent passer par une longue boucle de calculs (environ 15 min par tableau).
Afin de gagner du temps, je pensais utiliser le couple async/await et Task pour faire travailler mon code sur plusieurs processeurs, mais le seul avantage que j'ai c'est de ne pas bloquer mon interface graphique, mon premier coeur de processeur tourne à fond de balle pendant que les autre se la coulent douce.


Voici le schéma de mon code:

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
  private async void button1_Click(object sender, EventArgs e)
        {
 
            double[,] Tableau_1 = new double[100, 3000];
            double[,] Tableau_2 = new double[100, 3000];
            double[,] Tableau_3 = new double[100, 3000];
            double[,] Tableau_4 = new double[100, 3000];
 
 
            // j'initialise mes tableaux
 
 
             // je lance mes Task
 
 
                 var t1 = Task.Run(() => Code(Tableau_1));
                 var t2 = Task.Run(() => Code(Tableau_2));
                 var t3 = Task.Run(() => Code(Tableau_3));
                 var t4 = Task.Run(() => Code(Tableau_4));
 
 
 
                await Task.WhenAll(t1, t2, t3, t4);
 
 
 
public async Task<double> Code(double[,] Tableau_de_travail)
{
// ma longue boucle de calculs
 
return resultat; 
 
}
 
 
        }

Comment faire SVP pour assigner chaque Task à un processeur (ou quelle autre méthode utiliser)?

(Comme vous l'avez vu, je suis en c#)

Merci d'avance!!

[youtpout978]

Si tu utilises linq il y a les méthodes Parrallel
https://docs.microsoft.com/fr-fr/dot...ction-to-plinq

[altozinzin]

Merci, cela couplé avec un passage à un framework plus récent me permet d'avoir de bien meilleurs performances.

Merci

[StringBuilder]

Merci, cela couplé avec un passage à un framework plus récent me permet d'avoir de bien meilleurs performances.

Merci

Pour le coup, j'ai pondu un long bousin sur le sujet du multi-coeur (logique/physique) vs multi-thread/process sur un autre forum qui n'a rien à voir et pour faire simple :
- d'un point de vue architecture, rien n'est simple, évident : sur certaines architecture, 1 coeur à 100% et 3 autres IDLE peut indiquer un travail plus rapide et plus efficace que si les 4 coeurs sont 100% (cas de la technologie hyperthreading)
- en programmation, les outils sont soit trop simplistes (async / await qui ne permettent pas de choisir une affinité CPU, et donc on se trouve comme toi avec tous les threads sur un même coeur, ce qui n'est absolument pas ce que tu voulais), soit trop complexes/merdiques/et toujours incomplets (gestion manuelle des threads, avec toujours l'inconnue de la nature réelle des coeurs sur lesquels vont tourner les threads)
- l'OS et autres outils externes (carte mère CPU lui-même, etc.) sont là pour ne rien arranger, en changeant nos thread de coeurs en cours de traitement (extrêmement coûteux), OC/DC à la volée en fonction de la charge des coeurs physiques (genre si les coeurs logiques 1 et 2 sont sur le même coeur physique, les lancer ne même temps à 100% va faire chauffer le coeur et provoquer son downclockage, alors que si on avait lancé sur 1 et 3 où 3 est sur un second coeur physique, les deux traitements auraient pu tourner à 100% sans surchauffe)

Bref, un bordel sans nom.

Le but premier du multi-thread, c'est, comme tu l'as remarqué, d'obtenir une GUI réactive y compris prendant un traitement. Dans l'informatique d'aujourd'hui, ça s'arrête là.

Si tu veux faire du multi-thread à vocation de vitesse d'exécution, je te déconseille de passer par les simplifications syntaxiques, et gère "manuellement" la priorité des processeur, voir le clustering (hé oui, rien n'est plus rapide pour faire tourner un programme sur un PC que de le faire tourner sur 2 PC !).

A ce moment, pas d'autre solution que de déclarer les Threads à la main, en indiquant notamment un maque d'affinité différent pour chaque (pour en mettre manuellement 1 sur chaque coeur).
C'est bien plus lourd, par contre tu auras l'assurance que tous les coeurs sont bien mis à contribution, et surtout, qu'aucun coeur ne se coltine plusieurs threads en parallèle.

[altozinzin]

Merci pour cette réponse pointue.

J'ai peur que tout cela ne dépasse mes simples compétences d'amateur. Le GUI est réactif et avec le Parrallel, j'ai quand même gagné un peu en performance, à mon niveau je pense que ce sera suffisant.

Merci pour ces conseils!