Discussion :

[kaitlyn]

Dans le code que tu montres à aucun moment tu ne simules une addition d'échantillons. Il y a juste une boucle qui ne fait rien et pour rappel le compilateur ne prendra pas la peine de la traduire. Essaye de fournir un code simple qui soit plus représentatif des opérations à accomplir et sans les threads pour justement voir ce qu'on peut en faire.

[ABD-Z]

Il y a juste une boucle qui ne fait rien .

Si, j'avais dé-commenté les affichages (bien plus coûteux qu'une addition).
Résultat : toujours plus lent en multi-threading que ce soit avec OpenMP ou les thread de la stl.

Une des solutions à tester est de choisir une structure de données de la STL, autre que les tableaux C, supportant for_each et changer la politique d'exécution en std:ecution::par_unseq.

J'ai pris cet exemple de Microsoft :
https://devblogs.microsoft.com/cppbl...r-performance/

Je l'avais testé avec g++ , les résultats de l'exemple sont décevant.
C'est bien dit dans le blog, faut utiliser cl, le compilateur d'optimisations de Microsoft : les performances sont réelles!

J'ai testé pour mon exemple et le séquentiel est bien meilleur... Même avec les std::cout qui sont assez lents pourtant..

Voici le code parallélisable avec for_each :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
std::array<Seq_Chan, CHANS> seq_chan_std_array;
 
 
    std::chrono::steady_clock::time_point begin2 = std::chrono::steady_clock::now();
	for(unsigned int j = 0; j < COUNT; ++j){
		std::cout << "*******************************"<<j<<"*******************************"<<std::endl;
		std::for_each(std::execution::par_unseq, seq_chan_std_array.begin(), seq_chan_std_array.end(), [](Seq_Chan &sc){ sc.play(); });
	}
 
 
	std::chrono::steady_clock::time_point end2 = std::chrono::steady_clock::now();

Je crois qu'une approche multi-threadé pour des tâches qui durent environ 200µs ou moins et qui doivent être synchronisées n'est pas optimale...
À vérifier.

[kaitlyn]

L’idéal est quand même d'avoir un modèle concret, complet et de faire le test.
En plus il faut un bon chronographe car suivant les implémentations et les sources de temps la résolution de std::chrono laisse parfois à désirer. Elle peut être de 5 ou 10 millisecondes, donc ça aussi il faut le mesurer et comparer avec, ou privilégier, ce qui se fait de mieux sur la plateforme: QueryPerformanceCounter(), clock_gettime(), mach_absolute_time(), etc(). Voir aussi du coté de boost s'il apporte une solution à ce problème.
Donc voilà, sans une bonne préparation du terrain tout n'est que spéculation.

[Astraya]

Et j'ajouterais que si tu veux simple, garde les boucles, si tu veux du multithread performant sur ton cas spécifique, oublies la STL.

[Astraya]

Je crois qu'une approche multi-threadé pour des tâches qui durent environ 200µs ou moins et qui doivent être synchronisées n'est pas optimale...
À vérifier.

Peut-être que la solution est de redéfinir tes tâches, une tâche peut-etre le temps T, une autre le temps T+1.. Mais c'est sur que faire juste 3-4 additions multiplication c'est pas plus rapide en thread de par la nature même des processeurs et de leur cycle d'instruction

[Mat.M]

@ABD-Z comme il a été très bien expliqué rien ne prouve que faire du multithreading améliore les performances d'un programme.

[ABD-Z]

Et j'ajouterais que si tu veux simple, garde les boucles, si tu veux du multithread performant sur ton cas spécifique, oublies la STL.

donc tout ce qui est std::thread et std::execution::par_unseq/for_each je laisse tomber c'est pas le plus top? OpenMP est-ce meilleur?
Sinon, quelle librairie de thread vraiment chouette conseillerez-vous? Celle de Windows? Posix?