From: Francois Berenger <berenger@riken.jp>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Case study in optimization: porting a compiler from OCaml to F#
Date: Tue, 19 Mar 2013 10:50:00 +0900 [thread overview]
Message-ID: <5147C448.5030803@riken.jp> (raw)
In-Reply-To: <037b01ce2307$d54e6130$7feb2390$@ffconsultancy.com>
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.
>
>
>
next prev parent reply other threads:[~2013-03-19 1:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 17:04 Jon Harrop
2013-03-13 17:14 ` julien verlaguet
2013-03-13 19:19 ` Jon Harrop
2013-03-13 19:28 ` oliver
2013-03-14 15:05 ` oliver
2013-03-14 15:15 ` oliver
2013-03-15 13:34 ` Pierre-Alexandre Voye
2013-03-17 12:06 ` Jon Harrop
2013-03-19 1:50 ` Francois Berenger [this message]
2013-03-20 20:54 ` Jon Harrop
2013-03-20 22:35 ` Roberto Di Cosmo
2013-03-21 4:13 ` Mike Lin
2013-03-21 7:35 ` Roberto Di Cosmo
2013-03-21 20:07 ` Roberto Di Cosmo
2013-03-19 12:47 ` Jean-Marc Alliot
2013-03-20 9:32 ` Roberto Di Cosmo
2013-03-19 1:37 ` Francois Berenger
2013-03-13 17:55 ` Alain Frisch
2013-03-13 19:44 ` Jon Harrop
2013-03-13 21:02 ` Alain Frisch
2013-03-13 18:27 ` oliver
2013-03-13 20:00 ` Jon Harrop
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5147C448.5030803@riken.jp \
--to=berenger@riken.jp \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox