Re: Threads vs Process

Le 15/08/2024 à 15:30, Francois LE COAT a écrit :

>
Tout dépend le type de calcul, cette méthode rustique peut dans certains cas convenir. Mais c'est bien ce qu'elle est : rustique.

 Oui rustique

 Mais ça marche partout,

Une charrue tirée par un cheval ça marche aussi. C'est juste plus facile avec un tracteur.

et c'est totalement portable d'un Unix à un
autre, puisque j'utilise le même code sur freeMiNT, Solaris, macOS et
GNU/Linux.

Tous les compilateurs C/C++ modernes implémentent OpenMP, c'est utilisable absolument partout.

Il n'y a pas de bibliothèque dédiée à utiliser,

Les bibliothèques dédiées ont pour but d'éviter que chacun ait à inventer l'eau tiède dans son coin.

et c'est
le système qui s'occupe de répartir la charge de calcul, sur le ou les
processeurs présents sur la machine.

Pareil pour les threads, c'est le système qui les distribue sur les différents coeurs. Avec même quelques avantages, par exemple OpenMP a des directives permettant de locker chaque thread sur un coeur donné, ce qui améliore la gestion des caches. Quand tu lances des process séparés "à la main" tu n'as aucun moyen de t'assurer que chaque process restera sur le même coeur pendant toute son exécution.

C'est un fondement de Unix avec
le multitâche préhemptif, qui permet de gérer un nombre arbitraire de
processeurs.

Merci Captain Obvious.

On atteint jamais strictement la charge maximale de ou des
processeurs, mais la commande système `time` permet de vérifier que l'on
approche les 100% de charge avec un CPU, les 200% avec deux etc. Je
ne suis pas sûr que l'on aie une méthode aussi portable et universelle
en utilisant des threads.

Tu n'es pas sûr ? En fait tu n'en sais rien du tout parce que tu ne connais pas le sujet.
Autre avantage d'OpenMP : on peut répartir dynamiquement la charge de travail entre les différents threads, et très simplement. Ca assure que l'occupation des coeurs reste optimale même quand on ne peut pas découper les calculs à effectuer en parts vraiment égales à priori. Et c'est beaucoup plus compliqué à faire en lançant des process complètement séparés.

C'est très simple à mettre en oeuvre,
indépendamment du nombre de processeurs. Pourquoi se compliquer la vie,
à écrire un code explicitement parallèle ? C'est complètement intuitif !

OpenMP est d'une simplicité biblique, justement. Et comme ce sont des directives et non pas du code en tant que tel, le même code peut être compilé avec ou sans OpenMP et donc tourner en parallèle ou en séquentiel, sans qu'il y ait rien à modifier. Quand on compile sans OpenMP les directives sont simplement ignorées.