Sujet : Re: Threads vs Process
De : lecoat (at) *nospam* atari.org (Francois LE COAT)
Groupes : fr.comp.sys.atariDate : 16. Aug 2024, 12:30:34
Autres entêtes
Organisation : To protect and to server
Message-ID : <v9nd8q$3ii7r$1@paganini.bofh.team>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Firefox/91.0
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.
>
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, et c'est totalement portable d'un Unix à un
autre, puisque j'utilise le même code sur freeMiNT, Solaris, macOS et
GNU/Linux. Il n'y a pas de bibliothèque dédiée à utiliser, 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. C'est un fondement de Unix avec
le multitâche préhemptif, qui permet de gérer un nombre arbitraire de
processeurs. 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. 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 !
Dans ton fork tu fais quoi au juste dans ce cas ? Un exec quelque chose où tu fais tourner le doublon du père?
Bien sur cela fonctionne mais est ce pour autant très efficace ? Enfin pas bien grave, l'optimisation est un concept très abstrait il me semble pour toi.
J'ai déjà publié ici un exemple d'utilisation de fork(), que tu n'as pas
compris. On ne va pas recommencer à en discuter. Tu ne connais pas cette
fonctionnalité parallèle d'Unix. C'est pourtant complètement fondamental
Je vais te donner un exemple d'utilisation avec un script shell ...
"
#!/bin/csh -f
while(!(-e endtprop))
(./simutpro $1\.ppm ima1h.ppm v tpro >& out_v) >& processv &
(./simutpro $1\.ppm ima1h.ppm h tpro >& out_h) >& processh &
wait
cat processh processv >>process
./center $1 ima1h tpro >>process
end
"
Je lance deux instances de `simutpro` avec des images différentes, en
redirigeant les sorties, en "background" ce qui est fait par le "&"
final. J'attends que les deux programmes se finissent par `wait`.
Je regroupe les résultats sur les deux images avec le programme `center`
Puis j'itère tant que le fichier "endtpro" n'est pas existant.
Tu dis que les processus ne sont pas efficace, parce que ça te passe
nettement au dessus de la tête ... C'est pourtant le B.A.BA de Unix.
Ça marche avec freeMiNT, et sans thread !
-- François LE COATAuteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)https://eureka.atari.org/