Path: ...!eternal-september.org!feeder3.eternal-september.org!news.gegeweb.eu!gegeweb.org!pasdenom.info!from-devjntp
Message-ID: <4Nnx0UcrdNsO_nmj_qrrpZjM20U@jntp>
JNTP-Route: news2.nemoweb.net
JNTP-DataType: Article
Subject: Re: Threads vs Process
References: <v71gat$aj8p$1@dont-email.me> <wZ3kBCL52vnUkkvFGisuqwdZ7Mk@jntp> <v9fojn$2n22o$1@paganini.bofh.team>
 <v9fqr5$12bq$1@news.usenet.ovh> <v9fv26$2nd94$1@paganini.bofh.team> <QHmHcgZ1wpB0WQGUWir7UJkc0BU@jntp>
 <v9inhr$30tgg$1@paganini.bofh.team> <LPj-LG68xkkv2S1Cv5zPLRuBONE@jntp> <3kFmA5w1Ga-hCPXht5gTT6S-Amw@jntp>
 <6sERMUni4sfwXdzWb8aTSFjGgPs@jntp>
Newsgroups: fr.comp.sys.atari
JNTP-HashClient: n7cmhq6MgRP5vq_OcR0vRrx52Bk
JNTP-ThreadID: v71gat$aj8p$1@dont-email.me
JNTP-ReferenceUserID: 69@news2.nemoweb.net
JNTP-Uri: http://news2.nemoweb.net/?DataID=4Nnx0UcrdNsO_nmj_qrrpZjM20U@jntp
User-Agent: Nemo/0.999a
JNTP-OriginServer: news2.nemoweb.net
Date: Thu, 15 Aug 24 13:12:39 +0000
Organization: Nemoweb
JNTP-Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:109.0) Gecko/20100101 Firefox/115.0
Injection-Info: news2.nemoweb.net; posting-host="516ee13c1e79fa65aedf115a32aee346f9289ca9"; logging-data="2024-08-15T13:12:39Z/8987702"; posting-account="44@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: pehache <pehache.7@gmail.com>
Bytes: 2731
Lines: 22

Le 15/08/2024 à 13:18, OL a écrit :
>> 
>> #pragma omp parallel for
>> for (int i=0; i<n; i++) {
>>     //un calcul quelconque
>> }
>> 
>> et la boucle est automatiquement découpée et distribuée sur autant de threads 
>> qu'il y a de coeurs (physiques) sur la machine.
> 
> Je pensais à un truc tout bête en fait, pour faire la même chose que proposé 
> par François, il faut du point de vu code je suppose que le code doit être "safe 
> thread" alors qu'il n'y en a pas besoin dans son cas, mais peut-être que les 
> compilateurs savent gérer la chose avec openmp ou faut encore faire attention ?

Ca reste de la responsabilité du développeur de s'assurer de la 
thread-safitude de son code :-). OpenMP fournit des outils pour cela 
(variables privées par thread, réductions, régions critiques...) mais 
il n'en reste pas moins que certains algorithmes ne sont pas naturellement 
thread-safe et qu'il faut parfois les repenser à la base. Mais 
d'expérience, un algo qui n'est pas facilement parallélisable par 
threads ne l'est en général pas vraiment non plus par des méthodes 
rustiques.