Re: Threads vs Process

Le 16/08/2024 à 13:30, 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.

>
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

Ah mais si je l'ai compris et j'ai même été obligé de le corriger pour le faire marcher!
Donc ce que j'en comprend tu n'utilises fork que pour lancer des programmes en multitâche et créer le pipe dont tu as besoin, donc comme un script. C'est joli mais là où tu ne comprends pas où je veux en venir, c'est que je ne vois toujours pas comment cela pourrait t'aider dans ton programme Eureka pour l'accélérer, si c'est pour faire comme au travail je vois mal l'intérêt de réclamer un machine multicore à Atari, on parle depuis quelques messages de ton besoin d'une machine Atari moderne et à part Eureka tu peux faire ce genre d'acrobaties sur toute machine Unix ou plutôt sur tout système qui supporte le standard Posix.

 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.

Formidable tu le fais avec un script, mais comment ferais tu dans le cas concret de Eureka pour le rendre plus véloce avec ce principe et faire en sorte sur une machine bien sur adaptée (multicore donc) que tu sois plus rapide que ce que propose Guillaume sur sa page avec Forth (qui lui ne sera pas multi process)?

 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 !

Oui mais est ce que cela peut être appliqué à rendre Eureka beaucoup plus rapide si tu avais la machine adaptée? C'est cela qui m'intéresse, tes exploits dans les scripts cela ne me fait ni chaud ni froid, je n'en ai pas l'intérêt personnel et l'utilité pro. Par contre si tu me montres comment tu peux améliorer Eureka, cela devient très intéressant parce que là je reste plus que sceptique quant à la réalisation car je me doute fort que ton logiciel n'est pas adapté à ce genre de façon de faire, mais ce n'est qu'une opinion jusque preuve du contraire.
OL