Forum Programmation.c pthread : multi-processeur/multi-cœur ?

Posté par  .
Étiquettes : aucune
1
12
jan.
2010
Salut,


Mon programme est codé en C, utilise les thread POSIX de la lib pthread.
Il créer plusieurs thread, un thread par client connecté en TCP/IP.

Ma question : dois-je faire quelques choses pour que chaque thread s'exécute sur un processeur / cœur différent ? si oui, comment optimiser ?

Merci.

  • # Non

    Posté par  (site web personnel) . Évalué à 1.

    Sauf erreur de ma part c'est le noyau qui décide de ce qui tourne et où cela tourne. Sous certains unix il était(est) possible d'accéder facilement aux informations sur le cœur d'execution et d'attacher un processus à un CPU. Mais je ne sais pas si cela se fait sous linux. À priori, sauf pour des calculs très lourds et des architectures/charges particulières, il n'est pas vraiment utile de chercher à gérer ce genre de choses.

    La seule optimisation facile et efficace que je puisse suggérer est la suivante : pour des calculs très lourds, éviter de faire tourner plus de filaments que l'on n'a de processeurs.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Non

      Posté par  . Évalué à 1.

      Merci.

      Je conclus que le noyau décide où affecter tel ou tel thread, si calculs lourd : un thread max par processeur.

      • [^] # Re: Non

        Posté par  (site web personnel) . Évalué à 1.

        Ça dépend de ce qu'on appel lourd, mais en général ce sera un filament par processeur logique, voire seulement un par cœur. Ceci n'est vrai que pour les processus lourds en calcul. Par exemple, si les processus sont lourds en lectures/écritures sur disque, il peut être préférable d'avoir beaucoup moins de processus ou au moins de gérer la cohérence de leurs accès au disque.

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Non

      Posté par  (site web personnel) . Évalué à 6.

      Pour nuancer un petit peu, on peut donner des indices au noyau, mais c'est spécifique au noyau (donc pas portable, des sémantiques différentes, tout ça...). Pour Linux, regarde du côté de sched_setaffinity(2), pour FreeBSD regarde du côté de cpuset(2), pour `uname` du côté de `apropos affinity`.

      Ceci dit, sauf si tu as des besoins très spécifiques, c'est probablement beaucoup plus simple, plus portable de laisser le noyau gérer tout ça. On a eu assez de guerres sur les ordonnanceurs, il faudrait peut-être espérer qu'ils sont maintenant au point et lui laisser faire le boulot...

      • [^] # Re: Non

        Posté par  (site web personnel) . Évalué à 3.

        Ou plus simplement utiliser hwloc, qui est portable :)

        Mais dans ce cas-ci, autant laisser le noyau se débrouiller, il y a
        arrivera très bien.

  • # user-level vs kernel-level

    Posté par  . Évalué à -1.

    Si l'implémentation utilise des threads en user-level (par exemple OpenBSD), alors les threads ne pourront pas tourner en parallèle sur différents processeurs.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.