Re: [Caml-list] Case study in optimization: porting a compiler from OCaml to F#

[Roberto Di Cosmo <roberto@dicosmo.org>]

Dear Jean-Marc,
     we are quite happy that Parmap is useful in your applications,
and would love to know more about your use cases.

Btw, I uploaded to HAL an author version of the article published in Procedia
Computer Science, so that everybody can access the paper ... it is
available at 

 http://hal.archives-ouvertes.fr/docs/00/69/25/15/PDF/parmap-author-file.pdf

all the best

--
Roberto and Marco

On Tue, Mar 19, 2013 at 01:47:51PM +0100, Jean-Marc Alliot wrote:
> We have been using Parmap and are quite happy with it (we use it as
> an alternative to the Ocaml/MPI implementation when MPI is not
> strictly required), with excellent scalability on our applications
> (even if we had to change from time to time a little bit or our
> code, regarding the fact that Parmap does not allow "in place"
> modifications).
> 
> Le 17/03/2013 13:06, Jon Harrop a écrit :
> >What happens if the inner function returns results via mutation? I
> >assume you must rearrange the code to return all results
> >explicitly and they will then be deep copied (which destroys
> >scalability due to limited shared memory bandwidth on multicores).
> As fas as I can tell there is no "copy" of any form. Parmap only
> collects results. If you do "in place" modifications, they are lost.
> Parmap is, in a way, "functional"...
> >Does it do load balancing? I assume not given that ncores is
> >hardcoded.
> There is an optional argument (chunksize) to manually control load
> balancing.
> >Does a parmap with ncores=4 inside a parmap with ncores=4 create
> >16 processes? Does it deep copy inputs and/or outputs?
> Regarding outputs, Parmap uses a shared memory area and
> Marshal/Unmarshal to collect outputs. There is an optimization done
> when array of floats are returned, as marshalling is not used, thus
> reducing the overhead.
> >I assume so, at least for outputs, because you cannot write
> >results in-place without a shared mutable heap. Does parmap have a
> >large constant overhead? I assume so if it is forking processes.
> Well, it depends on what you call "large constant overhead". Forking
> is not a so expensive primitive on modern Unix systems, because
> pages are only copied when written-to (copy-on-write).
> >Another solution is to prefork and explicitly communicate all
> >inputs using message passing but this is equally problematic. You
> >have to rearrange the code. Deep copying inputs also destroys
> >scalability. Cheers, Jon.
> 
> There is an article describing the implementation (I think it is
> also available online):
> 
> A “minimal disruption” skeleton experiment: seamless map & reduce
> embedding in OCaml
> M. Danelutto, R. Di Cosmo
> Procedia Computer Science 9 ( 2012 ) 1837 – 1846
> 
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-- 
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
FRANCE.                  Twitter: http://twitter.com/rdicosmo
------------------------------------------------------------------
Attachments:
MIME accepted, Word deprecated
      http://www.gnu.org/philosophy/no-word-attachments.html
------------------------------------------------------------------
Office location:
 
Bureau 320 (3rd floor)
Batiment Sophie Germain
Avenue de France
Metro Bibliotheque Francois Mitterrand, ligne 14/RER C
-----------------------------------------------------------------
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3