List Info

Thread: "ocaml_beginners"::[] OCaml and multi-core processors




"ocaml_beginners"::[] OCaml and multi-core processors
user name
2007-01-06 12:43:39

On Saturday 06 January 2007 12:01, Eric Berend wrote:
> This one problem has completely impeded adoption of OCaml as the
> development language of choice for this project. Much as I have often
>; loathed the actions of Microsoft in our industry, their "F#" variant
> *does* allow re-entrant code. What are the designers and development
> personnel at INRIA involved in the OCaml project, doing to address
> this issue? Ours cannot be the only endeavor with such considerations.

Indeed, F# has many useful features that OCaml lacks and concurrency is one of
them. However, there is a considerable cost to having a concurrent GC and,
consequently, F# is often 2x slower than OCaml for GC-intensive programs.

If you're targetting >2 cores/CPUs then F# is a definite win.

I don't believe the guys at INRIA are addressing the parallelism of OCaml,
although the source code is typically easy to parallelise thanks to
functional programming. We have had great success translating OCaml programs
into F# and making them concurrent.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

__._,_.___
.

__,_._,___
"ocaml_beginners"::[] OCaml and multi-core processors
user name
2007-01-06 14:07:50

On Sat, Jan 06, 2007 at 12:43:39PM +0000, Jon Harrop wrote:
> On Saturday 06 January 2007 12:01, Eric Berend wrote:
> > This one problem has completely impeded adoption of OCaml as the
> > development language of choice for this project. Much as I have often
>; > loathed the actions of Microsoft in our industry, their "F#" variant
> > *does* allow re-entrant code. What are the designers and development
> > personnel at INRIA involved in the OCaml project, doing to address
> > this issue? Ours cannot be the only endeavor with such considerations.
>
> Indeed, F# has many useful features that OCaml lacks and concurrency is one of
> them. However, there is a considerable cost to having a concurrent GC and,
> consequently, F# is often 2x slower than OCaml for GC-intensive programs.
[...]

Shouldn't it be easy toparallelize, when using
fork() to make seperate processes?

There is one thing that would be nice to have: IPC.

Ciao,
Oliver

__._,_.___
.

__,_._,___
"ocaml_beginners"::[] OCaml and multi-core processors
user name
2007-01-06 23:06:37

On Sat, Jan 06, 2007 at 03:07:50PM +0100, Oliver Bandel wrote:
[...]
> There is one thing that would be nice to have: IPC.
[...]

Especially SharedMem would be fine.

Thinking about it.... wouldn't it be possible
to use SharedMem with a C-layer and some
additional things that connect this C-layer with
OCaml?

At least with some restrictions, that are coming from
OCaml's specific language features this should be possible?

What kind of (OCaml-specific) problems must be thought about,
when implementing such things?

Ciao,
Oliver

__._,_.___
.

__,_._,___
"ocaml_beginners"::[] OCaml and multi-core processors
user name
2007-01-07 06:13:39

If I'm understanding http://en.wikipedia.org/wiki/Reentrant as
describing your problem, it seems like Unix.fork (ie fork()) would do
the trick. Threads made with Unix.fork cannot modify values in each
other's memory space except when done explicitly by the programmer by,
for example, marshaling data through a pipe.

I've had some fun making servers that have independent threads for
each client and using Unix.pipe to allow the clients and server to
communicate safely. Once I had some practice with fork and pipe I
found that the server and client code was quite easy to extend.

You might want to reevaluate ocaml!

Jeff

__._,_.___
.

__,_._,___
"ocaml_beginners"::[] OCaml and multi-core processors
user name
2007-01-07 10:13:51

Oliver Bandel wrote:
> [...]
>; > There is one thing that would be nice to have: IPC.
> [...]
>;
> Especially SharedMem would be fine.
>;
> Thinking about it.... wouldn't it be possible
> to use SharedMem with a C-layer and some
> additional things that connect this C-layer with
> OCaml?
>
> At least with some restrictions, that are coming from
> OCaml's specific language features this should be possible?
>
> What kind of (OCaml-specific) problems must be thought about,
> when implementing such things?

You might want to check out a recent announcement on the OCaml list
from Gerd Stolpmann on December 28 titled "ocamlnet-2.2 released".

Robert Roessler
robertr%40rftp.com">robertrrftp.com
http://www.rftp.com

__._,_.___
.

__,_._,___
[1-5]

about | contact  Other archives ( Real Estate discussion Medical topics )