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

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

Hi Mike, that is something that one could add rather easily... just
open an issue here: https://github.com/rdicosmo/parmap

2013/3/21 Mike Lin <mlin@mlin.net>:
> Just a comment FWIW, I personally moved away from Parmap because it doesn't
> deal well with exceptions raised in the child processes. I know the
> brokenness of exception marshalling (PR#0001961) complicates this, but I
> came up with something I felt was pretty reasonable in my iteration of the
> same concept:
> https://github.com/mlin/forkwork
> Of course I didn't reimplement some of Parmap's fancier features, but this
> solution has been "just right" for my applications. I hope this can inspire
> a future improvement to exception handling in Parmap.
> Mike
>
>
>
>
> On Wed, Mar 20, 2013 at 3:35 PM, Roberto Di Cosmo <roberto@dicosmo.org>
> wrote:
>>
>> Hi Jon,
>>    a concrete set of well justified benchmarks could serve
>> the cause more than any abstract discussion; please feel
>> free to set it up, run it, and analyze the results.
>>
>> Having spent quite a bit of energy on Parmap, after it
>> started as a sort of a one-afternoon project, and with
>> the experience of the now very old OCamlP3l library that
>> started much of this at the end of the '90s (including a
>> detour through an experimental reimplementation in Haskell),
>> I definitely took the St Thomas stance with this kind of issues :-)
>>
>> --
>> Roberto
>>
>> On Wed, Mar 20, 2013 at 08:54:59PM -0000, Jon Harrop wrote:
>> >
>> > Not just the granularity. Also the communication including any
>> > communication involved in scatter and gather phases. That differs a lot more
>> > between OCaml and F#. Fork does copy-on-write but (IIRC) the GC can incur
>> > unnecessary copying but, more importantly, requires the gather phase to deep
>> > copy results back to the original process. In contrast, data can be passed
>> > by reference in F#.
>> >
>> > Would be very interesting to benchmark this...
>> >
>> > Cheers,
>> > Jon.
>> >
>> > -----Original Message-----
>> > From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On
>> > Behalf Of Francois Berenger
>> > Sent: 19 March 2013 01:50
>> > To: caml-list@inria.fr
>> > Subject: Re: [Caml-list] Case study in optimization: porting a compiler
>> > from OCaml to F#
>> >
>> > I have observed and measured perfect scalability with up to 4 cores of
>> > an OCaml program using Parmap.
>> > With more than 4 cores, the scalability was degrading.
>> >
>> > I think the scalability of the program depends only on the granularity
>> > of the tasks. The tasks were coarse in my case.
>> >
>> > F.
>> >
>> > On 03/17/2013 09:06 PM, Jon Harrop wrote:
>> > > Pierre-Alexandre Voye wrote:
>> > >> So you could maybe use Parmap.map ?
>> > >> Parmap.parmap ~ncores:4 funct (Parmap.L elem_list)
>> > >
>> > > 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).
>> > >
>> > > Does it do load balancing? I assume not given that ncores is
>> > > hardcoded.
>> > >
>> > > Does a parmap with ncores=4 inside a parmap with ncores=4 create 16
>> > > processes?
>> > >
>> > > Does it deep copy inputs and/or outputs? 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.
>> > >
>> > > 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.
>> > >
>> > >
>> > >
>> >
>> >
>> > --
>> > 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
>> >
>> >
>> > --
>> > 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
>>
>> --
>> 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
FRANCE.
------------------------------------------------------------------
Attachments:
   MIME accepted
   Word deprecated, http://www.rfc1149.net/documents/whynotword
------------------------------------------------------------------
Office location:

Bureau 6C15 (6th floor)
175, rue du Chevaleret, XIII
Metro Chevaleret, ligne 6
------------------------------------------------------------------