From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 511827EE80 for ; Thu, 21 Mar 2013 05:13:46 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of mlin@mlin.net) identity=pra; client-ip=209.85.212.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mlin@mlin.net"; x-sender="mlin@mlin.net"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of mlin@mlin.net) identity=mailfrom; client-ip=209.85.212.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mlin@mlin.net"; x-sender="mlin@mlin.net"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-vb0-f53.google.com) identity=helo; client-ip=209.85.212.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mlin@mlin.net"; x-sender="postmaster@mail-vb0-f53.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4CAHGISlHRVdQ1iGdsb2JhbABDhUetTIlfiEqBUQgWDgEBAQoJFBQEJIIkAQEEAVUZCwUHBAsLBgQBAQENGgciEgEFAQoBCQgGEwkJCYdnAwkGBwWkJJQ5A4lljVoGgSUHBAcGgzoDiHWNa4EfikyDNRYphE2BSgkXHg X-IPAS-Result: Al4CAHGISlHRVdQ1iGdsb2JhbABDhUetTIlfiEqBUQgWDgEBAQoJFBQEJIIkAQEEAVUZCwUHBAsLBgQBAQENGgciEgEFAQoBCQgGEwkJCYdnAwkGBwWkJJQ5A4lljVoGgSUHBAcGgzoDiHWNa4EfikyDNRYphE2BSgkXHg X-IronPort-AV: E=Sophos;i="4.84,883,1355094000"; d="scan'208";a="8586447" Received: from mail-vb0-f53.google.com ([209.85.212.53]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 21 Mar 2013 05:13:43 +0100 Received: by mail-vb0-f53.google.com with SMTP id fj18so1609067vbb.40 for ; Wed, 20 Mar 2013 21:13:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=Ux0HdJjEUJAxTEHn58WnpqVL+1c3+bUk6U184fCv4D8=; b=R8NQlnQqPlAuN6LAeDOqhSfPfwj+Gc/CnJXOz+MYa2VTqzczW/Czg8YZkpo349kBs7 EPFScXRd6eCgPvQDcqBOvTmsL6TfgnOO2hG0f1R6CCDakJvX7JFyYDnvMR7I/rXX3MAk NRTHnqZ4EdzoQg6le8j0Po16aa8jmw/KKbaiMy37obF7eTkndPx1WS8LmSrLAzyHyANz tka7MxYYP/d5/pr2HPmyfJALZE5ScLcwOMuGz1D1/nIDFxhBALBDEUZ1+I3M4AgU/fdF GlGU7MjkeUYKcHlMiaVC6s9Rr5r9cCvmaG/Lz/Q1W/zSwa5gwZzshhcsplgRONvKdg+q UJUg== X-Received: by 10.220.109.210 with SMTP id k18mr11471258vcp.72.1363839222311; Wed, 20 Mar 2013 21:13:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.231.41 with HTTP; Wed, 20 Mar 2013 21:13:22 -0700 (PDT) X-Originating-IP: [96.24.78.140] In-Reply-To: <20130320223501.GA28114@voyager> References: <00ba01ce200c$d23f1910$76bd4b30$@ffconsultancy.com> <010801ce201f$afd6ad80$0f840880$@ffconsultancy.com> <037b01ce2307$d54e6130$7feb2390$@ffconsultancy.com> <5147C448.5030803@riken.jp> <069d01ce25ad$30bd3800$9237a800$@ffconsultancy.com> <20130320223501.GA28114@voyager> From: Mike Lin Date: Wed, 20 Mar 2013 21:13:22 -0700 Message-ID: To: Roberto Di Cosmo Cc: Jon Harrop , Francois Berenger , "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=047d7b3a98e660811c04d867904b X-Gm-Message-State: ALoCoQn/C0uSlCmI6RVIGMoKXN23SOeCDYIzYez9r0J+YLYl728Z49hosRF+K5f6wH2lb0sgCCSw X-Validation-by: mlin@mlin.net Subject: Re: [Caml-list] Case study in optimization: porting a compiler from OCaml to F# --047d7b3a98e660811c04d867904b Content-Type: text/plain; charset=ISO-8859-1 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 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 > --047d7b3a98e660811c04d867904b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Just a comment FWIW, I personally moved away from Parmap b= ecause it doesn't deal well with exceptions raised in the child process= es. I know the brokenness of exception marshalling (PR#0001961) complicates= this, but I came up with something I felt was pretty reasonable in my iter= ation of the same concept:
Of course I didn't reimplement some of Parmap'= s fancier features, but this solution has been "just right" for m= y applications. I hope this can inspire a future improvement to exception h= andling in Parmap.
Mike




On Wed, Mar 20, 2013 at 3:35 PM, Roberto Di Cosmo <roberto@dicos= mo.org> wrote:
Hi Jon,
=A0 =A0a 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 communi= cation involved in scatter and gather phases. That differs a lot more betwe= en OCaml and F#. Fork does copy-on-write but (IIRC) the GC can incur unnece= ssary copying but, more importantly, requires the gather phase to deep copy= results back to the original process. In contrast, data can be passed by r= eference in F#.
>
> Would be very interesting to benchmark this...
>
> Cheers,
> Jon.
>
> -----Original Message-----
> From: caml-list-request@= inria.fr [mailto:caml-lis= t-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 compile= r 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 t= hey will then be deep copied (which destroys scalability due to limited sha= red memory bandwidth on multicores).
> >
> > Does it do load balancing? I assume not given that ncores is hard= coded.
> >
> > Does a parmap with ncores=3D4 inside a parmap with ncores=3D4 cre= ate 16 processes?
> >
> > Does it deep copy inputs and/or outputs? I assume so, at least fo= r outputs, because you cannot write results in-place without a shared mutab= le 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 inp= uts using message passing but this is equally problematic. You have to rear= range the code. Deep copying inputs also destroys scalability.
> >
> > Cheers,
> > Jon.
> >
> >
> >
>
>
> --
> Caml-list mailing list. =A0Subscription 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. =A0Subscription 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 En delegation a l'INRIA
PPS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E-mail: roberto@dicosmo.org
Universite Paris Diderot WWW =A0: http://www.dicosmo.org
Case 7014 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tel =A0: ++33-(0)1-57 27 92 20=
5, Rue Thomas Mann
F-75205 Paris Cedex 13 =A0 Identica: http://identi.ca/rdicosmo
FRANCE. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Twitter: http://twitter.com/rdicosmo
------------------------------------------------------------------
Attachments:
MIME accepted, Word deprecated
=A0 =A0 =A0 http://www.gnu.org/philosophy/no-word-attachments.htm= l
------------------------------------------------------------------
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. =A0Subscription management and archives:
ht= tps://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

--047d7b3a98e660811c04d867904b--