Discussion :

[corentin59]

Bonjour à tous,

C'est encore moi mais avec une autre question !!

Toujours dans l'idée d'optimiser mon temps d’exécution, je me suis lancé dans le multi-threading.
J'ai copié quasi point par point l'exemple qu'Emmanuel Delahaye avait publié sur ce forum (http://www.developpez.net/forums/d47.../posix-thread/).

Tout compile bien et s’exécute sans problème. Les résultats sont bons. Mon seul problème c'est qu'avec et sans multi-threading, j'ai le même temps d’exécution !

Auriez-vous quelques conseils à me donner pour trouver comment diminuer le temps de calcul ?

Merci

[ternel]

Tu gagneras du temps si les threads se répartissent sur plusieurs cœurs et/ou processeurs.

[jabbounet]

Si tu travaille sur une matrice 3x3 tu ne verra pas grand chose, le cout de répartition sur les différents coeurs te coutera probablement à peu pres autant que le gain de calcul en parallélisation, sans compter que la charge généré par ton application étant faible il est probable que l'OS choisisse de tout faire sur un seul coeurs (donc de faire les traitement plus ou moins en série).

Les gains s'observerons quand tes thread commenceront a travailer sérieursement et que le système les repartira sur les différents coeurs de ton processeur (que tu peux aussi choisir la répartition des thread sur les coeurs avec pthread_set_affinity si je me souviens)

En gros sur un programme monothread ton appli ne pourra travailler que sur un seul coeur, alors qu'en multi-thread cela pourra se répartir sur les coeur et donc paralléliser les traitements. Si les traitement sont leger tu ne verra pas de gain (parfois même une perte), si les traitement sont lourd (beaucoup de calcul) alors tu commencera a voir une différence.

[corentin59]

Merci de ces réponses.

Je me suis inspiré du code d'Emmanuel mais en l'appliquant sur des matrices 1400x1900 et en faisant des traitements plus compliqués qu'une multiplication matricielle !

Comme pour le code d'origine, je décompose la matrice en autant de blocs de lignes que de threads. Mais j'ai l'impression que les threads sont exécutés séquentiellement. En effet, quand je fais un printf du numéro de ligne dans la fonction exécutée par le thread, je retrouve mes blocs de lignes, alors que s'il y avait exécution simultanée, il devrait y avoir des mélanges (par exemple, une ligne du bloc 1, puis une ligne du bloc 2, ...)

Du coup, j'ai deux questions :
1) comment puis-je vérifier si plusieurs cœurs ou processeurs sont utilisés ?
2) comment puis-je forcer la répartition des threads sur les cœurs/processeurs ?

Merci

[Obsidian]

Tu travailles :

• Sur quelle machine, équipée de quel microprocesseur ?
• Avec quel système d'exploitation ?

[corentin59]

Ben oui, ça peu aider :
OS : Linux 2.6.17-5mdv (mandriva 2007 official)
Machine : 2 processeurs AMD Athlon 64 X2 Dual Core Processor 4400+
donc 4 cœurs en tout

[jabbounet]

Ton kernel est-il compilé en SMP?

[corentin59]

Ton kernel est-il compilé en SMP?

Je n'en sais rien et je ne sais pas comment le savoir.

Ceci dit, il s'agit de mon poste au bureau, je n'ai donc pas la main haute pour le recompiler comme je veux, quant à mon administrateur réseau ... il me demandera comment on fait ça depuis son poste winDaub !

[dahtah]

Salut,

Je n'en sais rien et je ne sais pas comment le savoir.

Code :

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

1
2
3
grep SMP /proc/sys/kernel/version
et
grep SMP /boot/config-*

te diras si ton kernel a ete compile avec les options SMP et lesquels.

Apres un kernel SMP peut tourner sur une machine avec un seul proc, donc tu dois savoir si ton proc supporte SMP aussi.

[corentin59]

Code :

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

grep SMP /proc/sys/kernel/version

donne

Code :

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

#1 SMP Wed Sep 13 14:28:02 EDT 2006

et

Code :

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

grep SMP /boot/config-*

donne

Code :

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

1
2
3
# CONFIG_X86_VSMP is not set
CONFIG_SMP=y
CONFIG_SUSPEND_SMP=y

Comment dois-je interpréter ces résultats ?
Ca sert à quoi "SMP" ? C'est une obligation pour faire du multithreading ?

[Bktero]

http://www.blaess.fr/christophe/2011...par-des-mutex/
Dans ce code, C.Blaess montre comment forcer les threads à s’exécuter sur un seul cœur. Tu dois pouvoir explorer les fonctions qu'il utilise pour voir comment forcer la répartition sur plusieurs cœurs.

[jabbounet]

http://www.blaess.fr/christophe/2011...par-des-mutex/
Dans ce code, C.Blaess montre comment forcer les threads à s’exécuter sur un seul cœur. Tu dois pouvoir explorer les fonctions qu'il utilise pour voir comment forcer la répartition sur plusieurs cœurs.

pthread_setaffinity_np

en general le mot clé dans google pour ça est CPU affinity...

[Obsidian]

Hello,

Comme pour le code d'origine, je décompose la matrice en autant de blocs de lignes que de threads. Mais j'ai l'impression que les threads sont exécutés séquentiellement. En effet, quand je fais un printf du numéro de ligne dans la fonction exécutée par le thread, je retrouve mes blocs de lignes, alors que s'il y avait exécution simultanée, il devrait y avoir des mélanges (par exemple, une ligne du bloc 1, puis une ligne du bloc 2, ...)

Oui, mais ce test n'est pas fiable. Il est tout-à-fait possible que la bibliothèque qui gère les tampons de la sortie standard accorde une concession d'un temps donné à un thread et/ou utilise un second buffer après celui visible par setbuf() justement pour gérer au mieux ces accès concurrents. C'est encore plus vrai si tes threads ne sont pas des processus légers partageant le même espace mémoire mais, en réalité, de véritables processus produits avec fork().

Mais surtout : même si tu crées exactement le même nombre de threads que de cœurs, il n'est pas du tout certain que tes deux threads soient planifiés en même temps ! Chaque cœur peut se voir chargé, tout simplement, d'exécuter l'un des nombreux autres processus éligibles à l'exécution dans la liste, à commencer par le terminal censé afficher tes résultats.

Code :

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

grep SMP /proc/sys/kernel/version

donne

Code :

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

#1 SMP Wed Sep 13 14:28:02 EDT 2006

et

Code :

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

grep SMP /boot/config-*

donne

Code :

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

1
2
3
# CONFIG_X86_VSMP is not set
CONFIG_SMP=y
CONFIG_SUSPEND_SMP=y

Comment dois-je interpréter ces résultats ?
Ca sert à quoi "SMP" ? C'est une obligation pour faire du multithreading ?

SMP signifie « Symmetric Multiprocessing » et se réfère au modèle d'architecture multi-processeur utilisé entre autres sur les architectures Intel et qui, dans les faits, consiste à former des paires de processeurs identiques et accédant au même matériel.

Dans « CONFIG_SMP=y », « y » signifie « yes ». Le fichier en question n'est rien d'autre que le fichier des options de compilation du noyau (celui-là même que tu modifies avec make gconfig ou make xconfig). Le fait de le voir dans uname indique que ton noyau a été compilé pour prendre le SMP en charge.

Jusqu'à une époque relativement récente, disons jusqu'au Pentium 4, tous les ordinateurs grand public étaient mono-cœur et ça fonctionnait très bien comme ça. Linux a très vite entamé la prise en charge des architectures multi-processeurs (et pas seulement les PC), mais y parvenir entièrement était un vrai chantier, pas une formalité. Donc, pendant très longtemps, cette option n'était pas activée par défaut et n'avait pas de raison de l'être.

Quand c'eût été parfaitement au point, notamment parce qu'entretemps, le noyau a été considérablement réécrit, pour d'autres raisons mais en tenant compte de ce point, donc, le message d'aide de l'outil de configuration spécifiait qu'il était parfaitement safe de lancer un noyau SMP sur un mono-cœur, le seul impact étant une très légère latence, en principe imperceptible. Les distributions ont alors commencé à proposer en standard les deux noyaux compilés puis, très vite, à passer au SMP systématique.

Aujourd'hui, tous les ordinateurs ou presque sont multi-cœurs. Il n'y a plus de raison de compiler encore le kernel en mono-cœur sauf cas très particulier, par exemple, lorsque tu fais une « vraie » machine virtuelle en partitionnant les ressources de ta machine et en faisant tourner les deux systèmes à la fois. C'est donc tout naturellement que le noyau de ta machine pourtant pas toute jeune est compilé en SMP.

Enfin, pour répondre à ta question, il n'est pas nécessaire d'avoir un noyau SMP pour utiliser les threads, pas plus qu'il ne l'est pour créer plusieurs processus. Ils fonctionneront donc à tour de rôle sur le même cœur mais de façon transparente pour l'utilisateur et le développeur. Il l'est en revanche pour que le système exploite tous les cœurs à sa disposition.

[corentin59]

Merci beaucoup de toutes ces réponses.

En fait, je sens que je vais me faire tapé dessus car le "problème" venait de la manière de mesurer le temps écoulé.

Jusqu'à maintenant, j'utilisais la fonction clock qui mesure le temps CPU ! Mais, qu'on utilise un ou plusieurs cœurs, la charge CPU reste la même, c'est pourquoi j'avais toujours la même durée.

Maintenant, en utilisant la fonction time, qui mesure bien le temps écoulé indépendamment de l'utilisation des cœurs, je passe bien de 12s à 7s avec le multithreading !

Par contre, je subis les ralentissement liés autres applications qui tournent ! C'est pas facile de bien mesurer le temps !!!

[Obsidian]

Maintenant, en utilisant la fonction time, qui mesure bien le temps écoulé indépendamment de l'utilisation des cœurs, je passe bien de 12s à 7s avec le multithreading !

Il y a aussi quelque chose dont il faut tenir compte : l'échelonnement de la fréquence des CPU : aujourd'hui, pour éviter de trop chauffer et consommer, les micro-processeurs fonctionnent généralement à basse fréquence et le système les fait progressivement monter en fonction de la charge.

Par contre, je subis les ralentissement liés autres applications qui tournent ! C'est pas facile de bien mesurer le temps !!!

Ça non, et c'est un problème récurrent. :-)

[corentin59]

http://www.blaess.fr/christophe/2011...par-des-mutex/
Dans ce code, C.Blaess montre comment forcer les threads à s’exécuter sur un seul cœur. Tu dois pouvoir explorer les fonctions qu'il utilise pour voir comment forcer la répartition sur plusieurs cœurs.

J'ai testé ces fonctions. Ca marche bien, sauf que ça permet de forcer l'utilisation de tel ou tel processeur mais pas de tel ou tel cœur.
Ainsi, j'ai pu vérifier que les deux processeurs étaient bien utilisés mais impossible d'en savoir plus sur la répartition sur les cœurs.