Closed william3 closed 9 years ago
another question related to this : what is the purpose of Parmap.pariter, if one can not use a function with a side effect ?
Parmap does not implement shared memory: the reference i is "copied" to the process space of each of the subprocesses, and then each copie evolves independently.
You can think of this as 'each worked get a copy of the data of the parent process, and any side effect is local to its own copy'; this is a consequence of the underlying unix fork.
The result you see is perfectly logical once this notion is well understood: on 2 cores, you get two processes, and each of them works on 2 elements, so i is incremented twice in each subprocess.
Notice that the ideal application for Parmap is when you do not have side effects in the workers, or only "local" side effects, that do not escape to global structures.
On Tue, Jun 03, 2014 at 10:19:29AM -0700, william3 wrote:
The following program :
let i = ref 0 let _ = Parmap.pariter ~ncores:2 (~chunksize:1 ) (fun k -> incr i; Printf.printf "loop %i : i:%i\n%!" k !i; ) (Parmap.L [1;2;3;4]); Printf.printf "end : i:%i\n%!" !i;
returns : ./pb_parmap.native loop 1 : i:1 loop 2 : i:2 loop 3 : i:1 loop 4 : i:2 end : i:0
which is not so straightforward when I read the presentation... The paragraph : "By forking the parent process on a sigle machine, the children get access, for free, to all the data structures already built, even the imperative ones, and as far as your computation inside the map/fold does not produce side effects that need to be preserved, the final result will be the same as performing the sequential operation, the only difference is that you might get it faster" miss some warning that updates of imperative values accessed out of the parmap.par* will not be updated for other processes...
Thanks for this interesting library
— Reply to this email directly or view it on GitHub.*
Roberto Di Cosmo
Professeur En delegation a l'INRIA
PPS E-mail: roberto@dicosmo.org
Universite Paris Diderot WWW : http://www.dicosmo.org
Case 7014 Tel : ++33-(0)1-57 27 92 20
5, Rue Thomas Mann
F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo
Attachments: MIME accepted, Word deprecated
Office location:
Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
there are many kinds of side effects... for example, each worker may launch a complex simulation on data stored in different files, and write the result in some other different files.
On Tue, Jun 03, 2014 at 10:32:27AM -0700, william3 wrote:
another question related to this : what is the purpose of Parmap.pariter, if one can not use a function with a side effect ?
— Reply to this email directly or view it on GitHub.*
Roberto Di Cosmo
Professeur En delegation a l'INRIA
PPS E-mail: roberto@dicosmo.org
Universite Paris Diderot WWW : http://www.dicosmo.org
Case 7014 Tel : ++33-(0)1-57 27 92 20
5, Rue Thomas Mann
F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo
Attachments: MIME accepted, Word deprecated
Office location:
Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
ok thanks.
The following program :
let i = ref 0 let _ = Parmap.pariter ~ncores:2 (fun k -> incr i; Printf.printf "loop %i : i:%i\n%!" k !i; ) (Parmap.L [1;2;3;4]); Printf.printf "end : i:%i\n%!" !i;
returns : ./pb_parmap.native loop 1 : i:1 loop 2 : i:2 loop 3 : i:1 loop 4 : i:2 end : i:0
which is not so straightforward when I read the presentation...
The paragraph : "By forking the parent process on a sigle machine, the children get access, for free, to all the data structures already built, even the imperative ones, and as far as your computation inside the map/fold does not produce side effects that need to be preserved, the final result will be the same as performing the sequential operation, the only difference is that you might get it faster" miss some warning that updates of imperative values accessed out of the parmap.par* will not be updated for other processes...
Thanks for this interesting library