Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!pasdenom.info!from-devjntp
Message-ID: <tmZo9z_t2P7MnbCMjo-_fEXbP70@jntp>
JNTP-Route: news2.nemoweb.net
JNTP-DataType: Article
Subject: Re: Threads vs Process
References: <v71gat$aj8p$1@dont-email.me> <v9fv26$2nd94$1@paganini.bofh.team> <QHmHcgZ1wpB0WQGUWir7UJkc0BU@jntp>
 <v9inhr$30tgg$1@paganini.bofh.team> <LPj-LG68xkkv2S1Cv5zPLRuBONE@jntp> <3kFmA5w1Ga-hCPXht5gTT6S-Amw@jntp>
 <6sERMUni4sfwXdzWb8aTSFjGgPs@jntp> <v9kvud$39jll$1@paganini.bofh.team> <dZ4ulMH--zZhztjBb2gnZJCF8oc@jntp>
 <v9nd8q$3ii7r$1@paganini.bofh.team>
Newsgroups: fr.comp.sys.atari
JNTP-HashClient: NFxtMGCvTHPzAd-aifdxVr6BXv4
JNTP-ThreadID: v71gat$aj8p$1@dont-email.me
JNTP-Uri: http://news2.nemoweb.net/?DataID=tmZo9z_t2P7MnbCMjo-_fEXbP70@jntp
User-Agent: Nemo/0.999a
JNTP-OriginServer: news2.nemoweb.net
Date: Fri, 16 Aug 24 18:52:33 +0000
Organization: Nemoweb
JNTP-Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0
Injection-Info: news2.nemoweb.net; posting-host="70e9fdebe516d61ad04c84cddf7db6c6243dd2c5"; logging-data="2024-08-16T18:52:33Z/8989396"; posting-account="69@news2.nemoweb.net"; mail-complaints-to="julien.arlandis@gmail.com"
JNTP-ProtocolVersion: 0.21.1
JNTP-Server: PhpNemoServer/0.94.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-JNTP-JsonNewsGateway: 0.96
From: OL <ol.google@lutece.net>
Bytes: 6826
Lines: 107

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