Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Eray Ozkural <examachine@gmail.com>
Cc: Goswin von Brederlow <goswin-v-b@web.de>,
	Rich Neswold <rich.neswold@gmail.com>,
	"caml-list@yquem.inria.fr" <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Smart ways to implement worker threads
Date: Sat, 17 Jul 2010 21:35:24 +0200	[thread overview]
Message-ID: <87tynxc35v.fsf@frosties.localdomain> (raw)
In-Reply-To: <942FD9F6-601C-4F02-83E8-84CD280A04FF@gmail.com> (Eray Ozkural's message of "Sat, 17 Jul 2010 21:34:12 +0300")

Eray Ozkural <examachine@gmail.com> writes:

> When I'm implementing a parallel/dist algorithm I take care of making
> the communication code abstract enough to be re-used. Since
> abstraction in C derivative languages (function pointers, templates
> etc) are a joke; one need not bother with this as expected future code
> re-use isn't much.
>
> On the other hand in ocaml we have the best module system which can be
> used to create advanced parallel data structures and algorithms. A
> shared mem queue would be among the most trivial of such
> constructs. If we think of world domination we have to see the whole
> picture. Parallel programming is considered difficult because common
> programmers don't understand enough algebra to see that most problems
> could be solved by substituting an operator in a generic parallel
> algorithm template. Or that optimal algorithms could be re-used
> combinatorially (consider the relation of a mesh topology to a linear
> topology with s/f routing)

Yeah. I would love to have all the basic ocaml modules also as a thread
safe flavour.

> The fact is that an efficient parallel algorithm need not be long
> (theory suggests that fastest is shortest). It is our collective lack
> of creativity that usually makes it long.
>
> Cheers,
>
> Eray
>
> Ps: parallelism is not tangential here. I believe it is unnecessary to
> implement asynchronous processes just for the sake of handling
> overlapping I/O and computation. That's like parallelism for high
> school programming class.

I'm a big fan of doing IO asynchronously in a single thread. Given that
ocaml can only run one thread at a time anyway there is usualy no speed
gain in using multiple threads. The overhead of making the code thread
save is big in complexity (if only we hade thread save modules :) and
all you end up doing is waiting on more cores.

The exception is when you offload work to C code that can run within
enter_blocking_section() / leave_blocking_section() and you have enough
work to keep multiple cores busy. For example doing blockwise sha256
sums with 4 cores is 3-3.8 times as fast as single threaded depending on
blocksize.

MfG
        Goswin


  reply	other threads:[~2010-07-17 19:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-14 16:09 Goswin von Brederlow
2010-07-15 15:58 ` [Caml-list] " Rich Neswold
2010-07-15 16:19   ` David McClain
2010-07-15 17:16   ` Ashish Agarwal
2010-07-15 18:24   ` Goswin von Brederlow
2010-07-15 18:37     ` David McClain
2010-07-15 18:40     ` David McClain
2010-07-15 19:56     ` Rich Neswold
2010-07-16  4:02       ` Goswin von Brederlow
2010-07-16  4:23         ` Rich Neswold
2010-07-16 13:02           ` Goswin von Brederlow
2010-07-16 14:40             ` Dawid Toton
2010-07-16 16:18             ` [Caml-list] " Rich Neswold
2010-07-17 17:53               ` Eray Ozkural
2010-07-20  4:54             ` Satoshi Ogasawara
2010-07-17 18:34         ` Eray Ozkural
2010-07-17 19:35           ` Goswin von Brederlow [this message]
2010-07-17 22:00             ` Eray Ozkural
2010-07-15 16:32 ` Romain Beauxis
2010-07-15 17:46   ` Goswin von Brederlow
2010-07-15 18:44     ` Romain Beauxis
2010-07-16  3:52       ` Goswin von Brederlow
2010-07-16  4:19         ` Romain Beauxis
2010-07-16 13:05           ` Goswin von Brederlow
2010-07-16 13:20             ` Romain Beauxis
2010-07-17  9:07               ` Goswin von Brederlow
2010-07-17 13:51                 ` Romain Beauxis
2010-07-17 14:08                   ` Goswin von Brederlow
2010-07-17  9:52 ` Goswin von Brederlow
2010-07-17 14:20   ` Romain Beauxis
2010-07-17 15:52     ` Goswin von Brederlow

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=87tynxc35v.fsf@frosties.localdomain \
    --to=goswin-v-b@web.de \
    --cc=caml-list@yquem.inria.fr \
    --cc=examachine@gmail.com \
    --cc=rich.neswold@gmail.com \
    /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