caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jonathandeanharrop@googlemail.com>
To: "'Wolfgang Draxinger'" <wdraxinger.maillist@draxit.de>,
	<caml-list@yquem.inria.fr>
Subject: RE: [Caml-list] SMP multithreading
Date: Wed, 17 Nov 2010 03:41:46 -0000	[thread overview]
Message-ID: <02bd01cb8609$5d67ea30$1837be90$@com> (raw)
In-Reply-To: <20101117005215.5dc5ebcd@narfi.yggdrasil.draxit.de>

Wolfgang wrote:
> I'd like to point out how the big competitor to OCaml deals with it.
> The GHC Haskell system has SMP parallization built in for some time,
> and it does it quite well.

I beg to differ. Upon trying to reproduce many of the Haskell community's
results, I found that even their own parallel Haskell programs often exhibit
huge slowdowns. This is because Haskell's unpredictable performance leads to
unpredictable granularity and, consequently, more time can be spent
administering the tiny parallel computations than is gained by doing so.

The results I found here are typical:

 
http://flyingfrogblog.blogspot.com/2010/01/naive-parallelism-with-hlvm.html

Note that the absolute performance peaks at an unpredictable number of cores
only in the case of Haskell. This is because the GC does not scale beyond
about 4 cores for any Haskell programs doing significant amounts of
allocation, which is basically all Haskell programs because allocations are
everywhere in Haskell.

Ultimately, running on all cores attains no speedup at all with Haskell in
that case. This was branded "the last core slowdown" but the slowdown
clearly started well before all 8 cores. There was a significant development
towards improving this situation but it won't fix the granularity problem:

  http://hackage.haskell.org/trac/ghc/blog/new-gc-preview

The paper "Regular, shape-polymorphic, parallel arrays in Haskell" cites
2.5x speedups when existing techniques were not only already getting 7x
speedups but better absolute performance as well. Cache complexity is the
problem, as I explained here:

 
http://flyingfrogblog.blogspot.com/2010/06/regular-shape-polymorphic-paralle
l.html

Probably the best solution for multicore programming is Cilk. This technique
has already been adopted both in Intel's TBB and Microsoft's .NET 4 but,
AFAIK, the only functional language with access to it is F#. There are some
great papers on multicore-friendly cache oblivious algorithms written in
Cilk:

  http://www.fftw.org/~athena/papers/tocs08.pdf

Note, in particular, that Cilk is not only much faster but also much easier
to use than explicit message passing.

To do something like this, threads need to be able to run in parallel and
mutate the same shared heap. Although that is objectively easy (I did it in
HLVM), OCaml's reliance upon very high allocation rates, efficient
collection of young garbage and a ridiculous density of pointers in the heap
make it a *lot* harder.

Cheers,
Jon.



  parent reply	other threads:[~2010-11-17  3:42 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-15 17:27 Wolfgang Draxinger
2010-11-16  6:46 ` [Caml-list] " Edgar Friendly
2010-11-16 17:04   ` Gerd Stolpmann
2010-11-16 20:35     ` Eray Ozkural
2010-11-16 22:13       ` Gerd Stolpmann
2010-11-16 23:04         ` Eray Ozkural
2010-11-16 23:52           ` Wolfgang Draxinger
2010-11-17  1:55             ` Eray Ozkural
2010-11-17  3:41             ` Jon Harrop [this message]
2010-11-17  3:47           ` Jon Harrop
2010-11-17  4:27             ` Eray Ozkural
2010-11-17  6:50               ` Gabriel Kerneis
2010-11-17 13:41                 ` Eray Ozkural
2010-11-17 21:15                   ` Jon Harrop
2010-11-18  0:28                     ` Eray Ozkural
2010-11-18  1:00                       ` Eray Ozkural
2010-11-16 19:07   ` Norman Hardy
2010-11-17 16:34   ` David Allsopp
2010-11-19 13:57     ` Eray Ozkural
2010-11-16 12:47 ` Sylvain Le Gall
2010-11-17 11:12   ` [Caml-list] " Goswin von Brederlow
2010-11-17 11:34     ` Sylvain Le Gall
2010-11-17 23:08       ` [Caml-list] " Christophe Raffalli
2010-11-19  9:01         ` Christophe TROESTLER
2010-11-19 15:58           ` Goswin von Brederlow
2010-11-20 11:55             ` Jon Harrop
2010-11-20 20:57               ` Goswin von Brederlow
     [not found] ` <AANLkTinyN2hHxm6ha2Yq4nx6NxY3So=BhFN_-EHKYfyc@mail.gmail.com>
2010-11-16 14:11   ` Wolfgang Draxinger

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='02bd01cb8609$5d67ea30$1837be90$@com' \
    --to=jonathandeanharrop@googlemail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=wdraxinger.maillist@draxit.de \
    /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;
as well as URLs for NNTP newsgroup(s).