Re: Threads vs Process

Le 14/08/2024 à 18:55, Francois LE COAT a écrit :

Salut,
 OL écrit :

Et moi je te répond que dans le monde moderne sur une machine de bureau actuel le parallèlisme pour faire du calcul (on parlait bien de cela il me semble) se fait par thread pas par process, faudrait te mettre à jours.

 Bien pour faire du traitement d'images, et de la vision artificielle,
qui sont des calculs assez complexes, principalement sur des entiers,
j'utilise les ressources parallèles des machines multi-coeurs, en
lançant des processus concurrents. Il suffit souvent de découper les
images, et de lancer des calculs identiques, sur des morceaux d'images,
et de regrouper les calculs sur les différents morceaux indépendants.

Effectivement tu peux faire comme cela, est-ce pour autant le plus efficace ?
Non et de très loin. Dans ce cas le thread est plus recommandé mais c'est plus compliqué à programmer.

 Avec ce principe il est très facile de charger au maximum, une machine
avec de très nombreux coeurs, comme le fait Persistence Of Vision, mais
lui avec de nombreux threads, ce qui est paramétrable avec POV-Ray.
 On peut lancer des processus avec l'appel système fork() dans un
programme, ou même utiliser un script shell, en lançant plusieurs
instances d'un même programme, sur des données d'images différentes,
en tâche d'arrière plan, avec un rendez-vous de fin, avec la commande
système `wait` qui attend la fin de processus lancés en "background".
 C'est le système Unix (GNU/Linux ou macOS) qui s'occupe de la
répartition équitable de charge de calcul des processus. Ce principe
existe depuis toujours, et même avec freeMiNT, sauf qu'à l'origine,
la répartition de charge ne se faisait que sur un seul CPU, sur ATARI.
C'est un bon moyen sur un seul CPU de le charger au maximum à 100%.

Encore une erreur, dans le cas de figure énoncé tu iras moins vite qu'en faisant un seul process, tu ne peux gagner que si cela te permet d'enlever une tâche répétitive inutile, comme c'est le cas pour gérer l'AES. Dans ton cas tu ne gagneras rien sauf si le système sait gérer l'hyperthreading, l'hyperthreading a été concu sur le principe qu'un processeur peut traiter plusieurs instructions à la fois, seulement c'est assez peu le cas souvent les codes sont souvent très séquentiel, l'idée est de pouvoir traiter plusieurs routines indépendantes et optimiser l'utilisation du CPU.

Très souvent sur un ordinateur, le(s) processeur(s) sont sous-utilisé(s)

Sauf que dès que tu fais un calcul qui n'appelle pas le système ton CPU est chargé par principe, donc à ce moment là créer plusieurs process n'a plus aucun intérêt.