Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Stephan Houben]

On 11/30/2010 12:55 PM, oliver@first.in-berlin.de wrote:
> There is one problem with this... when you have forked, then
> you obviously have separated processes and also in each process
> your own ocaml-program with it's own GC running...

...neatly sidestepping the problem that the GC needs to lock out all threads...

> .with such a mem-mapping trick (never used Bigarray, so I'm astouned it uses
> mmap) you then have independent processes, working on shared mem without
> synchronisation.

> This is a good possibility to get corrupted data, and therefore unreliable behaviour.

Well, not more possibility than inherently in any code that updates a shared data structure
in parallel. It is certainly not the case that the independently executing GCs in both
processes are causing data corruption, since the GC only operates on unshared memory.
Note that the GC doesn't move the Bigarray data around.

(I am not sure if this was in particular your worry or that it was just the lack of
  synchronisation mechanisms which you bring up next.
  Apologies if I am addressing some non-concern.)

> So, you have somehow to create a way of communicating of these processes.
>
> This already is easily done in the Threads-module, because synchronisation
> mechanisms are bound there to the OCaml API and can be used easily.
>
> In the Unix module there is not much of ths IPC stuff...

In fact there is the Unix.pipe function which can be used for message passing
communication between processes.
A pipe can also be used as a semaphore:
operation V corresponds to writing a byte to the pipe, operation P corresponds to reading a byte.
It's a bit heavy since it always makes a kernel call even for the non-contended case, but
otherwise it works perfectly.

For many purposes (e.g. something "embarrassingly parallel" like computing the Mandelbrot set)
you can just divide the work up-front and only rely on the implicit synchronization given
by waitpid.

If you allow me a final observation/rant: I personally feel that the use of fork() and
pipes as a way to exploit multiple CPUs is underrated. When appropriate (lots of computation
and not so much synchronisation/communication) it works really great and is very robust because
all data is process-private by default, as opposed to threading, where everything is shared
and you have to stand on your head to get a thread-local variable. Performance can also be better
since you don't run into cache coherency issues.

I am not sure why it is not used more; possibly because it is not supported on Windows.

Stephan

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Gerd Stolpmann]

Am Dienstag, den 30.11.2010, 15:04 +0100 schrieb Stephan Houben:
> On 11/30/2010 12:55 PM, oliver@first.in-berlin.de wrote:
> > There is one problem with this... when you have forked, then
> > you obviously have separated processes and also in each process
> > your own ocaml-program with it's own GC running...
> 
> ...neatly sidestepping the problem that the GC needs to lock out all threads...
> 
> > .with such a mem-mapping trick (never used Bigarray, so I'm astouned it uses
> > mmap) you then have independent processes, working on shared mem without
> > synchronisation.
> 
> > This is a good possibility to get corrupted data, and therefore unreliable behaviour.
> 
> Well, not more possibility than inherently in any code that updates a shared data structure
> in parallel. It is certainly not the case that the independently executing GCs in both
> processes are causing data corruption, since the GC only operates on unshared memory.
> Note that the GC doesn't move the Bigarray data around.
> 
> (I am not sure if this was in particular your worry or that it was just the lack of
>   synchronisation mechanisms which you bring up next.
>   Apologies if I am addressing some non-concern.)
> 
> > So, you have somehow to create a way of communicating of these processes.
> >
> > This already is easily done in the Threads-module, because synchronisation
> > mechanisms are bound there to the OCaml API and can be used easily.
> >
> > In the Unix module there is not much of ths IPC stuff...
> 
> In fact there is the Unix.pipe function which can be used for message passing
> communication between processes.
> A pipe can also be used as a semaphore:
> operation V corresponds to writing a byte to the pipe, operation P corresponds to reading a byte.
> It's a bit heavy since it always makes a kernel call even for the non-contended case, but
> otherwise it works perfectly.
> 
> For many purposes (e.g. something "embarrassingly parallel" like computing the Mandelbrot set)
> you can just divide the work up-front and only rely on the implicit synchronization given
> by waitpid.
> 
> If you allow me a final observation/rant: I personally feel that the use of fork() and
> pipes as a way to exploit multiple CPUs is underrated. When appropriate (lots of computation
> and not so much synchronisation/communication) it works really great and is very robust because
> all data is process-private by default, as opposed to threading, where everything is shared
> and you have to stand on your head to get a thread-local variable. Performance can also be better
> since you don't run into cache coherency issues.
> 
> I am not sure why it is not used more; possibly because it is not supported on Windows.

I don't think this is the reason. Many people can ignore Windows,
actually.

The problem is more that your whole program needs then to be
restructured - multi-processing implies a process model (which is the
master, which are the workers). With multi-threading you can start
threads at all times without having to worry about that (i.e. supports
"programming without design" if you want to take that as a negative
point).

This is what I want to fix with my Netmulticore library - it defines a
framework allowing you to start new processes at any time without having
to worry about the process hierarchy.

Also, many practical problems are only O(n log n), at most. The cost for
serialization of data through a pipe cannot be neglected here. This
makes shared memory attractive, even if it is only available in a
restricted form (like write once memory).

Gerd


> Stephan
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 


-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[oliver]

On Tue, Nov 30, 2010 at 03:04:32PM +0100, Stephan Houben wrote:
> On 11/30/2010 12:55 PM, oliver@first.in-berlin.de wrote:
> >There is one problem with this... when you have forked, then
> >you obviously have separated processes and also in each process
> >your own ocaml-program with it's own GC running...
> 
> ...neatly sidestepping the problem that the GC needs to lock out all threads...
> 
> >.with such a mem-mapping trick (never used Bigarray, so I'm astouned it uses
> >mmap) you then have independent processes, working on shared mem without
> >synchronisation.
> 
> >This is a good possibility to get corrupted data, and therefore unreliable behaviour.
> 
> Well, not more possibility than inherently in any code that updates a shared data structure
> in parallel. It is certainly not the case that the independently executing GCs in both
> processes are causing data corruption, since the GC only operates on unshared memory.
> Note that the GC doesn't move the Bigarray data around.
> 
> (I am not sure if this was in particular your worry or that it was just the lack of
>  synchronisation mechanisms which you bring up next.
>  Apologies if I am addressing some non-concern.)

You addressed a non-concern... I just meant that there are no synchronisation mechanisms
for that kind of shared menory.

But your non-concern coined a question, that should be concerned...
how does the GC's handle that shared mem?

Will it handle only a reference to the shared mem?
And if the GC frees the shared mem, will it only
stop  sharing that mem with the others?
Will the released shared mem be alsu munmap'ed by OCaml?
(Should be done by Bigarray...)



> 
> >So, you have somehow to create a way of communicating of these processes.
> >
> >This already is easily done in the Threads-module, because synchronisation
> >mechanisms are bound there to the OCaml API and can be used easily.
> >
> >In the Unix module there is not much of ths IPC stuff...
> 
> In fact there is the Unix.pipe function which can be used for message passing
> communication between processes.

OK, yes, pipe is a way to go.
But some other IPC stuff may also be very helpful.


[...]
> If you allow me a final observation/rant: I personally feel that the use of fork() and
> pipes as a way to exploit multiple CPUs is underrated.

I have no problem with fork.

But if one want's to use fork() one has toalso use the IPC stuff,
and regarding that, it seems pipe is the only available way for now in
OCaml.

And: if you want to use fork, and spread the work in that way,
why not using Camlp3 or such things? I assume it also relies on fork,
but makes such programming much easier.

As we started with threads in mind, I just followed that way.



> When appropriate (lots of computation
> and not so much synchronisation/communication) it works really great

Yes, for just spreading the work, fork()/exec() is fine.


> and is very robust because
> all data is process-private by default, as opposed to threading, where everything is shared
> and you have to stand on your head to get a thread-local variable.

Yes, but OCaml provides it's own kind of making things more robust.
In C your argument would have more weight. In OCaml variable clashes
are not a problem.

But the threaded way - because of the global lock - would be a show-stopper
regarding independent threads splitting of work is not possible.

And here I see a thread-specific GC as a solution.

It seems to me that this way was not thought about before,
and people thought about changing the GC to be able to handle multiple threads.
Instead I mean: each thread that is not the global thread, get's it's own
thread-specific GC.

Maybe that can be implemented much easier.
But I've not looked into the Ocaml internals to say: yes, this can be done
comparingly easy, or to say: oh no, that's more complex than changing the GC and make it
handle all the threads from the main thread.

I just would assume that seperate threads would be easier to handle.

But maybe there are other restrictions in the language or the compiler
that block this attempt.




> Performance can also be better
> since you don't run into cache coherency issues.
> 
> I am not sure why it is not used more; possibly because it is not supported on Windows.

;-)

Ciao,
   Oliver

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

On Tue, Nov 30, 2010 at 4:29 PM, <oliver@first.in-berlin.de> wrote:
>
> And here I see a thread-specific GC as a solution.
>
> It seems to me that this way was not thought about before,
> and people thought about changing the GC to be able to handle multiple
> threads.
> Instead I mean: each thread that is not the global thread, get's it's own
> thread-specific GC.
>
> Maybe that can be implemented much easier.
> But I've not looked into the Ocaml internals to say: yes, this can be done
> comparingly easy, or to say: oh no, that's more complex than changing the
> GC and make it
> handle all the threads from the main thread.
>
> I just would assume that seperate threads would be easier to handle.
>
> But maybe there are other restrictions in the language or the compiler
> that block this attempt.
>
>
Not anything that I have yet found but I am curious about the opinion of the
runtime designers as well. There seem to be some global variables in the
runtime, which isn't the best way to write it anyway, if all vars are local
then it becomes easier to embed, thread and fork as you like. That is to
say, such a level of virtualization allows the global lock to be substituted
with whatever locking the system alloc functions have, i.e. when many malloc
requests overlap.

Except that, the user has to explicitly sync his mem accesses so I don't
think there could be any problem. And no other part of the library is
thread-safe either (which is great for performance!). So I think each thread
can have its own GC. Perhaps there is an obstacle I have not yet noticed?

Best,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 2329 bytes --]

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Stephan Houben]

On 11/30/2010 02:22 PM, Gerd Stolpmann wrote:
> I don't think this is the reason. Many people can ignore Windows,
> actually.
>
> The problem is more that your whole program needs then to be
> restructured - multi-processing implies a process model (which is the
> master, which are the workers). With multi-threading you can start
> threads at all times without having to worry about that (i.e. supports
> "programming without design" if you want to take that as a negative
> point).
>
> This is what I want to fix with my Netmulticore library - it defines a
> framework allowing you to start new processes at any time without having
> to worry about the process hierarchy.

I have in fact read with much interest your blog at
http://blog.camlcity.org/blog/parallelmm.html .

Your approach there is to really have separate programs for
server and client. However, one nice thing about fork is that you don't
have to restructure your program; you can just call fork down somewhere
in some subroutine where you decide it is convenient, start doing some
multicore computation, finish and return, and the caller needs never know
that you did that. So you can indeed program without design using fork.

Of course, the advantage of your approach is that you can now distribute
the work over multiple machines. So I guess there is an appropriate
place for all of these techniques.

> Also, many practical problems are only O(n log n), at most. The cost for
> serialization of data through a pipe cannot be neglected here. This
> makes shared memory attractive, even if it is only available in a
> restricted form (like write once memory).

Well, the original context was one of a benchmark which had an
arbitrary rule that you can only use functions from the bundled libraries.
And my proposal was to use the pipe for synchronisation and the shared memory
for bulk communication.

If we drop the arbitrary rule there are faster options than pipes.
(e.g. POSIX semaphores in a shared memory segment).

Stephan

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Gerd Stolpmann]

Am Dienstag, den 30.11.2010, 16:30 +0100 schrieb Stephan Houben:
> On 11/30/2010 02:22 PM, Gerd Stolpmann wrote:
> > I don't think this is the reason. Many people can ignore Windows,
> > actually.
> >
> > The problem is more that your whole program needs then to be
> > restructured - multi-processing implies a process model (which is the
> > master, which are the workers). With multi-threading you can start
> > threads at all times without having to worry about that (i.e. supports
> > "programming without design" if you want to take that as a negative
> > point).
> >
> > This is what I want to fix with my Netmulticore library - it defines a
> > framework allowing you to start new processes at any time without having
> > to worry about the process hierarchy.
> 
> I have in fact read with much interest your blog at
> http://blog.camlcity.org/blog/parallelmm.html .
> 
> Your approach there is to really have separate programs for
> server and client. However, one nice thing about fork is that you don't
> have to restructure your program; you can just call fork down somewhere
> in some subroutine where you decide it is convenient, start doing some
> multicore computation, finish and return, and the caller needs never know
> that you did that. So you can indeed program without design using fork.

Well, I would not recommend that in all cases: fork duplicates all
memory, and if this is a lot, you can end up consuming a lot of RAM.
Even worse, the GC of the forked subprocess has to manage all of the
RAM, including the part that is not required for doing the computation
in the subprocess (the copy-on-write optimization of the OS gets you
nothing here).

Also, there can be subtle interactions between the parent and the child,
e.g. file descriptors are inherited, affecting whether closed
descriptors can be recognized.

So, use with care, and not without design. Forking in the middle of a
bigger program can be quite disastrous.

> Of course, the advantage of your approach is that you can now distribute
> the work over multiple machines. So I guess there is an appropriate
> place for all of these techniques.

I was recently working on an improved fork machinery, with some
indirection between the request for creating a new worker process, and
the actual fork. That's this netmulticore library I'm talking about. The
new process is not a child of the process requesting the creation, but
always a child of a common master process. This avoids all the problems
(memory issues, file descriptor issues, and a few more), at the cost of
having to transmit state to the new process.

> > Also, many practical problems are only O(n log n), at most. The cost for
> > serialization of data through a pipe cannot be neglected here. This
> > makes shared memory attractive, even if it is only available in a
> > restricted form (like write once memory).
> 
> Well, the original context was one of a benchmark which had an
> arbitrary rule that you can only use functions from the bundled libraries.
> And my proposal was to use the pipe for synchronisation and the shared memory
> for bulk communication.
> 
> If we drop the arbitrary rule there are faster options than pipes.
> (e.g. POSIX semaphores in a shared memory segment).

Yes, it's really arbitrary. All remaining solutions are very restricted
then, and don't have much to do with what you would choose for solving a
real-world problem. This makes this benchmark irrelevant.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[oliver]

On Tue, Nov 30, 2010 at 05:07:31PM +0100, Gerd Stolpmann wrote:
> Am Dienstag, den 30.11.2010, 16:30 +0100 schrieb Stephan Houben:
> > On 11/30/2010 02:22 PM, Gerd Stolpmann wrote:
> > > I don't think this is the reason. Many people can ignore Windows,
> > > actually.
> > >
> > > The problem is more that your whole program needs then to be
> > > restructured - multi-processing implies a process model (which is the
> > > master, which are the workers). With multi-threading you can start
> > > threads at all times without having to worry about that (i.e. supports
> > > "programming without design" if you want to take that as a negative
> > > point).
> > >
> > > This is what I want to fix with my Netmulticore library - it defines a
> > > framework allowing you to start new processes at any time without having
> > > to worry about the process hierarchy.
> > 
> > I have in fact read with much interest your blog at
> > http://blog.camlcity.org/blog/parallelmm.html .
> > 
> > Your approach there is to really have separate programs for
> > server and client. However, one nice thing about fork is that you don't
> > have to restructure your program; you can just call fork down somewhere
> > in some subroutine where you decide it is convenient, start doing some
> > multicore computation, finish and return, and the caller needs never know
> > that you did that. So you can indeed program without design using fork.
> 
> Well, I would not recommend that in all cases: fork duplicates all
> memory, and if this is a lot, you can end up consuming a lot of RAM.
[...]

Hence the fork-early recommendation, wich should be a known "rule".
But of course this is, what you addressed with "programming without design"
would be problematic.

But the same also holds for threaded programs, or programs in general.

Ad-hoc code is often a good way to just start something, but after a while
one should start design... and I mean... long before release. ;)
And doing the design after starting with ad-hoc code is done even better
with a language that makes refactoring easy. (And this is the reason
why we are on the Caml-list :))

Some people might even start with the design... and I think a rigid type system
like OCaml supports design, because starting with types can give a good
starting point in a design.
So I experienced that starting with types (and interface) can make things
very clear from the beginning. But of course this only helps, if you have
clear so far, what you want to achieve (a clear, distinct task).
But somehow this becomes off-topic and would be a separate discussion.



[...]
> > Of course, the advantage of your approach is that you can now distribute
> > the work over multiple machines. So I guess there is an appropriate
> > place for all of these techniques.
> 
> I was recently working on an improved fork machinery, with some
> indirection between the request for creating a new worker process, and
> the actual fork. That's this netmulticore library I'm talking about. The
> new process is not a child of the process requesting the creation, but
> always a child of a common master process.
[...]

So, you ask for new sisters and brothers....
...and the parent can be slim.



Ciao,
   Oliver

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Stephan Houben]

On 11/29/2010 04:33 PM, Oliver Bandel wrote:
> Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:
>
>> Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
>>> Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:
>>>

>>> You use shared mem(?), but you link only to *.ml files,
>>> and I see no *.c there.

>>> How can this be done?
>>>
>>> At least not via the libs that are shipped with OCaml?!

Actually it can be done using the libs that ship with OCaml
(Unix and Bigarray), although it is not 100% POSIX :

let create_shared_genarray kind layout dims =
   let fd = Unix.openfile "/dev/zero" [Unix.O_RDWR] 0
   in let ar = Bigarray.Genarray.map_file fd kind layout true dims
   in Unix.close fd; ar


The resulting bigarray object is shared among subsequent forks.
This relies on the fact that mmap-ing /dev/zero is equivalent
to an anonymous mmap.

http://en.wikipedia.org/wiki//dev/zero

Well, at least it works on Linux.

Stephan

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[oliver]

On Tue, Nov 30, 2010 at 09:10:36AM +0100, Stephan Houben wrote:
> On 11/29/2010 04:33 PM, Oliver Bandel wrote:
> >Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:
> >
> >>Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
> >>>Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:
> >>>
> 
> >>>You use shared mem(?), but you link only to *.ml files,
> >>>and I see no *.c there.
> 
> >>>How can this be done?
> >>>
> >>>At least not via the libs that are shipped with OCaml?!
> 
> Actually it can be done using the libs that ship with OCaml
> (Unix and Bigarray), although it is not 100% POSIX :
> 
> let create_shared_genarray kind layout dims =
>   let fd = Unix.openfile "/dev/zero" [Unix.O_RDWR] 0
>   in let ar = Bigarray.Genarray.map_file fd kind layout true dims
>   in Unix.close fd; ar
> 
> 
> The resulting bigarray object is shared among subsequent forks.

Hmhhh... we started talking about Threads and SharedMem.
You mean even fork.... hmhhh



> This relies on the fact that mmap-ing /dev/zero is equivalent
> to an anonymous mmap.
> 
> http://en.wikipedia.org/wiki//dev/zero
> 
> Well, at least it works on Linux.

In APUE it's mentioned that memory mapped regions are inherited
by a child, when forking it. So it should work on all Unix-systems too.

There is one problem with this... when you have forked, then
you obviously have separated processes and also in each process
your own ocaml-program with it's own GC running...

..with such a mem-mapping trick (never used Bigarray, so I'm astouned it uses
mmap) you then have independent processes, working on shared mem without
synchronisation.

This is a good possibility to get corrupted data, and therefore unreliable behaviour.

So, you have somehow to create a way of communicating of these processes.

This already is easily done in the Threads-module, because synchronisation
mechanisms are bound there to the OCaml API and can be used easily.

In the Unix module there is not much of ths IPC stuff...



(A thread-specific GC for thread-specific variables would help here,
 making global locks only necessary when accessing global used variables.
 But I don't know if such a way would be possible without changing the GC-stuff
 itself.)


Ciao,
   Oliver

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Tue, Nov 30, 2010 at 2:55 PM, <oliver@first.in-berlin.de> wrote:
>
>
> (A thread-specific GC for thread-specific variables would help here,
>  making global locks only necessary when accessing global used variables.
>  But I don't know if such a way would be possible without changing the
> GC-stuff
>  itself.)
>
>
Seconded, why is this not possible? That is to say, why cannot each thread
maintain a separate GC, if so desired?

Best,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 1087 bytes --]

RE: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Jon Harrop]

What would be responsible for collecting the shared heap?

Cheers,
Jon.

Eray wrote:
> Seconded, why is this not possible? That is to say, why cannot each thread
maintain a separate GC,
> if so desired?

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

Le 30/11/10 22:13, Jon Harrop a écrit :
> What would be responsible for collecting the shared heap?
Reference counting: if there are no pointer within the shared heap (I
mean pointer
to and from the shared heap), this should be quite easy via a finaliser ...

For more than that, reference counting via finaliser + a real GC for the
shared heap itself,
because this heap being seen as a C region from OCaml, but using the
memory representation
of OCaml, it could be managed by your own GC.

So globally, I think writing a C program that would manage an OCaml
shared heap with its own GC and reference counting for the number of
pointer from OCaml threads is quite feasible ...

There remain the following problem of
- an unexpectidely dying OCaml thread would leave its refenrece counting
increased forever ... It is not clear we have to deal with that ...
- What syntax to allocate in the Shared heap (some camlpN (N = 4 or 5)
magic ?)
- There is something to do for pointers from the shared heap to some
OCaml heap, they have to be forbidden,
but maybe you would like to disallow their apparition at compile time by
some static analysis ... Anyway, they will be detected at runtime by
page violation when an OCaml thread tries to follow a pointer to the
heap of another thread. At least this page violation should be
transformed into an OCaml exception. They will also be detected by the
GC of the Shared heap ... An here it is not clear what to do ... Just
ignore them ?

Cheers,
Christophe


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Gerd Stolpmann]

Am Dienstag, den 30.11.2010, 13:55 +0100 schrieb
oliver@first.in-berlin.de:
> On Tue, Nov 30, 2010 at 09:10:36AM +0100, Stephan Houben wrote:
> > On 11/29/2010 04:33 PM, Oliver Bandel wrote:
> > >Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:
> > >
> > >>Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
> > >>>Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:
> > >>>
> > 
> > >>>You use shared mem(?), but you link only to *.ml files,
> > >>>and I see no *.c there.
> > 
> > >>>How can this be done?
> > >>>
> > >>>At least not via the libs that are shipped with OCaml?!
> > 
> > Actually it can be done using the libs that ship with OCaml
> > (Unix and Bigarray), although it is not 100% POSIX :
> > 
> > let create_shared_genarray kind layout dims =
> >   let fd = Unix.openfile "/dev/zero" [Unix.O_RDWR] 0
> >   in let ar = Bigarray.Genarray.map_file fd kind layout true dims
> >   in Unix.close fd; ar
> > 
> > 
> > The resulting bigarray object is shared among subsequent forks.
> 
> Hmhhh... we started talking about Threads and SharedMem.
> You mean even fork.... hmhhh

Independent processes are right now the only way to use several cores.
You can organize shared memory between processes, but it is tricky.
That's what I try to ease with my Netmulticore library.

> > This relies on the fact that mmap-ing /dev/zero is equivalent
> > to an anonymous mmap.
> > 
> > http://en.wikipedia.org/wiki//dev/zero
> > 
> > Well, at least it works on Linux.
> 
> In APUE it's mentioned that memory mapped regions are inherited
> by a child, when forking it. So it should work on all Unix-systems too.

Yes, but is not defined by POSIX what mapping /dev/zero means.

> There is one problem with this... when you have forked, then
> you obviously have separated processes and also in each process
> your own ocaml-program with it's own GC running...
> 
> ..with such a mem-mapping trick (never used Bigarray, so I'm astouned it uses
> mmap) 

Bigarrays can use any memory with fixed addresses. That's the essence
here: Bigarrays are not moved around by the GC.

> you then have independent processes, working on shared mem without
> synchronisation.
> 
> This is a good possibility to get corrupted data, and therefore unreliable behaviour.
> 
> So, you have somehow to create a way of communicating of these processes.

So you need inter-process synchronization primitives, like POSIX
semaphores.

> This already is easily done in the Threads-module, because synchronisation
> mechanisms are bound there to the OCaml API and can be used easily.
> 
> In the Unix module there is not much of ths IPC stuff...

But in Ocamlnet's netsys module.

> (A thread-specific GC for thread-specific variables would help here,
>  making global locks only necessary when accessing global used variables.
>  But I don't know if such a way would be possible without changing the GC-stuff
>  itself.)

The global lock does not protect user variables, but the Ocaml runtime,
e.g. the state of the memory manager/garbage collector. Also it eases
code generation - the memory image needs not be in a consistent state
all the time (i.e. all pointers meaningful), but only when the runtime
gets a hand on it. Removing this lock has far-reaching consequences.

The oc4mc (ocaml for multicore) project used a separate minor heap per
thread, which actually eases the task a lot - memory is in most cases
allocated in the minor heap anyway. Many variables keeping the state of
the runtime are then thread-local.

Gerd

> 
> 
> Ciao,
>    Oliver
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 


-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: [Caml-list] Is OCaml fast?

[David Rajchenbach-Teller]

I can confirm that old code-snippets were removed (and that both faster solutions and environment variable tweaks were rejected).

On Nov 22, 2010, at 6:02 PM, Oliver Bandel wrote:

> Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:
> [...]
>> (I remember Ocaml was #1
>> at the shootout a few years ago, faster than C.) So maybe a good
>> opportunity to post better Ocaml solutions there?
> [...]
> 
> Yes I also remember that.
> I hope that the new OCaml compilers did not
> make OCaml lessperformance by enhancing other features.
> 
> And I don't realy think so.
> 
> But were the old code-snippets emoved, or what was going on,
> that OCaml degraded that much?
> 

Re: Is OCaml fast?

[Isaac Gouy]

David Rajchenbach-Teller <David.Teller <at> univ-orleans.fr> writes:


> I can confirm that old code-snippets were removed (and that both faster
solutions and environment
> variable tweaks were rejected).


Even back in 2001, Doug Bagley had noted all the things that were
wrong with the tasks on his "The Great Computer Language Shootout".

During autumn 2004, on Brent Fulgham's website, new tasks were added
and old Doug Bagley tasks removed.

By 2005 only 2 tasks remained from that old Doug Bagley website.

By August 2008 none of those old Doug Bagley tasks were measured for
the current benchmarks game. 

Re: [Caml-list] Re: Is OCaml fast?

[oliver]

On Tue, Nov 23, 2010 at 02:01:33AM +0000, Isaac Gouy wrote:
> David Rajchenbach-Teller <David.Teller <at> univ-orleans.fr> writes:
> 
> 
> > I can confirm that old code-snippets were removed (and that both faster
> solutions and environment
> > variable tweaks were rejected).
> 
> 
> Even back in 2001, Doug Bagley had noted all the things that were
> wrong with the tasks on his "The Great Computer Language Shootout".


And what was wrong in his eyes?


> 
> During autumn 2004, on Brent Fulgham's website, new tasks were added
> and old Doug Bagley tasks removed.
> 
> By 2005 only 2 tasks remained from that old Doug Bagley website.
> 
> By August 2008 none of those old Doug Bagley tasks were measured for
> the current benchmarks game. 

So, now the comparisions are perfect?
What problems were removed?


Ciao,
   Oliver

Re: Is OCaml fast?

[Isaac Gouy]

 <oliver <at> first.in-berlin.de> writes:
 
> > Even back in 2001, Doug Bagley had noted all the things that were
> > wrong with the tasks on his "The Great Computer Language Shootout".
> 
> And what was wrong in his eyes?

Find out for yourself:

http://web.archive.org/web/20010617014807/www.bagley.org/~doug/shootout/


> So, now the comparisions are perfect?

Has anyone said so?


> What problems were removed?

All of them.

Re: [Caml-list] Re: Is OCaml fast?

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]

Hello,

I think that this benchmark is lacking in the algorithms department. Where
is a dynamic programming problem? A graph algorithm? Anything with
non-trivial time/space complexity? Anything a little more complex than
matrix product?

Also, it's not uncommon to disallow low-level optimizations such as writing
memory allocators and async file access when comparing implementations of an
algorithm, but such restrictions should be carried out uniformly.  In such a
benchmark I would expect each entry to stick to their guns, i.e. use only
the standard libraries and programming styles for instance. Linking in
foreign libraries must most definitely be disallowed. So, if in Java, it's
necessary to call the garbage collector explicitly from time to time, and we
had to do that for a long time, so be it. Or again, if in Java, performance
will suffer unless you only use arrays of integral types, the implementer
may wish to implement as much as is possible with arrays, though I wonder if
it is not better to choose the most natural implementation style for the
particular language. In the case of Java, the claim was that object-oriented
was some kind of a programming-aid that can replace talented programmers :)
It's unfortunate of course that some kinds of optimizations always have to
be made by hand, for instance in functional languages many compilers do not
have deforestation.

Otherwise, of course, any implementation may include a compiler for the
fastest language and present a program in that language, which is not the
objective.

An alternative objective could be to compare the shortest and most
comprehensible, if possible line-to-line compatible implementation of a
given pseudocode in different languages. That would be extremely informative
for serious algorithm researchers! If a computer scientist isn't sure of the
performance of the primitives, he cannot make sure his implementation will
comply with the time-complexity of the given algorithm.

Best Regards,

On Wed, Nov 24, 2010 at 2:23 AM, Isaac Gouy <igouy2@yahoo.com> wrote:

>  <oliver <at> first.in-berlin.de> writes:
>
> > > Even back in 2001, Doug Bagley had noted all the things that were
> > > wrong with the tasks on his "The Great Computer Language Shootout".
> >
> > And what was wrong in his eyes?
>
> Find out for yourself:
>
> http://web.archive.org/web/20010617014807/www.bagley.org/~doug/shootout/<http://web.archive.org/web/20010617014807/www.bagley.org/%7Edoug/shootout/>
>
>
> > So, now the comparisions are perfect?
>
> Has anyone said so?
>
>
> > What problems were removed?
>
> All of them.
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>



-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 4168 bytes --]

Re: Is OCaml fast?

[Isaac Gouy]

Eray Ozkural <examachine <at> gmail.com> writes:


> Hello, I think that this benchmark is lacking ...

http://shootout.alioth.debian.org/help.php#why


Please make the kind of comparison you think should be done and publish it.

Re: [Caml-list] Re: Is OCaml fast?

[Jeff Meister]

Everyone in this thread is capable of reading your site and has
probably already done so. We know what your rules are for
binary-trees; repeating them does not help. Richard's objection, which
you dismissed out of hand, was that your no-GC-tuning rule is silly in
the light of actual uses of garbage collected programming languages on
modern processors. It makes your results unrealistic, and an
unrealistic benchmark is misleading, or at best merely useless. You
are free to tersely reject our constructive criticism, but the only
meaningful consequence will be that OCaml users consider the shootout
untrustworthy and completely ignore its results... what good are the
"language comparisons" your project makes if the communities behind
those languages don't support your benchmarking methods?

On Tue, Nov 23, 2010 at 6:13 PM, Isaac Gouy <igouy2@yahoo.com> wrote:
> Eray Ozkural <examachine <at> gmail.com> writes:
>
>
>> Hello, I think that this benchmark is lacking ...
>
> http://shootout.alioth.debian.org/help.php#why
>
>
> Please make the kind of comparison you think should be done and publish it.
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: Is OCaml fast?

[Stefan Monnier]

> Richard's objection, which you dismissed out of hand, was that your
> no-GC-tuning rule is silly in the light of actual uses of garbage
> collected programming languages on modern processors.  It makes your
> results unrealistic, and an unrealistic benchmark is misleading, or at
> best merely useless.

To the extent that this rule is the same for all languages and that most
languages on the shootout are also garbage collected, I think OCaml's
problem with this benchmark do point at a weakness of the current
GC code.

Of course, the shootout could be improved.  E.g. maybe it could allow
extra submissions that break the rules, along with a description of
which rules were broken and how.  Then there could be a "score according
to the rules", then a "score when all gloves are off", together with
some kind of "measure" of what was needed to go from one to the other.
This way people could maybe get a better feel for the languages's
performance and how (and how much) that performance can be affected.
Doesn't seem like an easy undertaking, tho.


        Stefan

Re: [Caml-list] Re: Is OCaml fast?

[Fabrice Le Fessant]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

On 11/25/2010 11:12 PM, Jon Harrop wrote:
> Stefan wrote:
>> I think OCaml's problem with this benchmark do point at a weakness of the current
>> GC code.

What makes you think that ?

I have contributed to some of the solutions that you can find there (and 
some other ones were rejected because caching results is not allowed too 
;-) ), and the GC was _NEVER_ a problem !

  (except for binary-trees, but for absurd reasons)

  The main problem was that other languages have bigger standard 
libraries, whereas OCaml has a very small one (just what is needed to 
compile the compiler, actually). In many problems, you could benefit 
from using a very simple shared-memory library (in mandelbrot, the ocaml 
multicore solution has to copy the image in a socket between processes, 
whereas it could just be in a shared memory segment), and in general, 
many solutions could benefit from specialised data structures that are 
provided in other languages by their standard libraries, and from some 
system calls that are currently not in the Unix library.

Anyway, I decided to stop trying to improve the solutions, and work on 
improving the compiler and its libraries instead. It might benefit to 
ocaml ranking in the shootout, but more importantely, it will benefit to 
everybody in the community also.

--Fabrice

[-- Attachment #2: fabrice_le_fessant.vcf --]
[-- Type: text/x-vcard, Size: 384 bytes --]

begin:vcard
fn:Fabrice LE FESSANT
n:LE FESSANT;Fabrice
org:INRIA Saclay -- Ile-de-France;Projet OCamlPro
adr;quoted-printable:;;Parc Orsay Universit=C3=A9 ;Orsay CEDEX;;91893;France
email;internet:fabrice.le_fessant@inria.fr
title;quoted-printable:Charg=C3=A9 de Recherche
tel;work:+33 1 74 85 42 14
tel;fax:+33 1 74 85 42 49 
url:http://fabrice.lefessant.net/
version:2.1
end:vcard

Re: [Caml-list] Re: Is OCaml fast?

[oliver]

On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
[...]
>  The main problem was that other languages have bigger standard
> libraries, whereas OCaml has a very small one (just what is needed
> to compile the compiler, actually). In many problems, you could
> benefit from using a very simple shared-memory library (in
> mandelbrot, the ocaml multicore solution has to copy the image in a
> socket between processes, whereas it could just be in a shared
> memory segment),


...so you work on a shared-mem module?!


> and in general, many solutions could benefit from
> specialised data structures that are provided in other languages by
> their standard libraries, and from some system calls that are
> currently not in the Unix library.
[...]

During the last some releases a lot more unix syscalls were added
and that's fine of course).

Which calls are you missing there?

Ciao,
   Oliver

Re: [Caml-list] Re: Is OCaml fast?

[Gerd Stolpmann]

Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
oliver@first.in-berlin.de:
> On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
> [...]
> >  The main problem was that other languages have bigger standard
> > libraries, whereas OCaml has a very small one (just what is needed
> > to compile the compiler, actually). In many problems, you could
> > benefit from using a very simple shared-memory library (in
> > mandelbrot, the ocaml multicore solution has to copy the image in a
> > socket between processes, whereas it could just be in a shared
> > memory segment),
> 
> 
> ...so you work on a shared-mem module?!

Don't know what Fabrice is referring to, but at least I work on a
multicore-enabling library:

https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netmulticore/

This is work in progress and highly experimental. What's currently
available:

- managing processes and resources like files, shared memory objects 
  etc.
- support for message passing via Netcamlbox (another library)
- low-level only so far: shared memory, including copying Ocaml values
  to and from shm
- low-level only so far: kernel semaphores
- a Netmulticore process is also a Netplex container, so mixing with
  Netplex-managed servers is possible. Also, the Netplex plugins 
  are available (semaphores, mutexes, global variables), but these
  are relatively slow

I've also written a few examples:

https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/examples/multicore/

Don't expect wonders, though. For instance, the port of the chameneos
game is based on message passing, but this is by design slower than
direct use of shared memory (and this game mostly consists of
synchronization, and there is not any computation involved where
multicore would be an advantage).

The further direction is the addition of more primitives, especially for
managing shared memory. The difficult here is that there is not any
support in the core language, and I have to work around that. This is
based on

val Netsys_mem.init_value 
      ?targetaddr:nativeint -> 
      ?target_custom_ops:(string * custom_ops) list ->
      memory -> int -> 'a -> init_value_flag list -> (int * int)

where type memory = (char,Bigarray.int8_unsigned_elt,Bigarray.c_layout) Bigarray.Array1.t

This means shared memory is handled just as a bigarray of chars that is
mapped into the address spaces of several processes. The init_value
function copies an arbitrary Ocaml value to such a bigarray  - in the
same way as Marshal.to_string - only that it is "to_bigarray", and that
the same representation is used as for normal values (so you can access
the copied values directly). This copying is quite time-consuming: you
have to create the Ocaml value in normal memory first, and then to use a
quite expensive generic copying machinery to get it to shared memory. It
would be more elegant if there was a way to instruct ocamlopt so that
code is emitted that creates the value directly in a user-supplied
memory area.

The arguments targetaddr and target_custom_ops point to another
difficulty: For certain uses of shared memory you cannot ensure that all
processes map the area to the same address. Because of this, there is
support for filling bigarrays so that the addresses are offset for a
different final mapping address. Netcamlbox uses this feature - the
sending process can map the shared bigarray to any address, and
nevertheless format a message with addresses that are right for the
receiving process.

In general, shared memory is difficult to add in an add-on library.
However, some lessons can be learned, and maybe this results in some
"plot" for adding better support in the core language.

Gerd

> 
> 
> > and in general, many solutions could benefit from
> > specialised data structures that are provided in other languages by
> > their standard libraries, and from some system calls that are
> > currently not in the Unix library.
> [...]
> 
> During the last some releases a lot more unix syscalls were added
> and that's fine of course).
> 
> Which calls are you missing there?
> 
> Ciao,
>    Oliver
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 


-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Oliver Bandel]

Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:

> Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
> oliver@first.in-berlin.de:
>> On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
>> [...]
>> >  The main problem was that other languages have bigger standard
>> > libraries, whereas OCaml has a very small one (just what is needed
>> > to compile the compiler, actually). In many problems, you could
>> > benefit from using a very simple shared-memory library (in
>> > mandelbrot, the ocaml multicore solution has to copy the image in a
>> > socket between processes, whereas it could just be in a shared
>> > memory segment),
>>
>>
>> ...so you work on a shared-mem module?!
>
> Don't know what Fabrice is referring to, but at least I work on a
> multicore-enabling library:
>
> https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netmulticore/
>
> This is work in progress and highly experimental. What's currently
> available:
>
> - managing processes and resources like files, shared memory objects
>   etc.
> - support for message passing via Netcamlbox (another library)
> - low-level only so far: shared memory, including copying Ocaml values
>   to and from shm
[...]

You use shared mem(?), but you link only to *.ml files,
and I see no *.c there.

How can this be done?

At least not via the libs that are shipped with OCaml?!

I would have expected some *.c for the shared mem part and
the creation of Caml-values....


Ciao,
    Oliver

P.S.: OCaml also provides a Thread-Lib, which seems to use pthread-lib.
       Normally this should help in making things possible to run on multiple
       cores. What are the restrictions  that this does not run that way?
       Somehow... when all values are handled via one GC, then those threads
       are somehow bound together, but on the other side, it works threaded,
       and consumer-worker pipes and such stuff can be used.
       So... somehow the GC seems to be the point, where the show will be
       stopped? (Anyone who has looked inside OCaml here more detailed?)

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Gerd Stolpmann]

Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
> Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:
> 
> > Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
> > oliver@first.in-berlin.de:
> >> On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
> >> [...]
> >> >  The main problem was that other languages have bigger standard
> >> > libraries, whereas OCaml has a very small one (just what is needed
> >> > to compile the compiler, actually). In many problems, you could
> >> > benefit from using a very simple shared-memory library (in
> >> > mandelbrot, the ocaml multicore solution has to copy the image in a
> >> > socket between processes, whereas it could just be in a shared
> >> > memory segment),
> >>
> >>
> >> ...so you work on a shared-mem module?!
> >
> > Don't know what Fabrice is referring to, but at least I work on a
> > multicore-enabling library:
> >
> > https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netmulticore/
> >
> > This is work in progress and highly experimental. What's currently
> > available:
> >
> > - managing processes and resources like files, shared memory objects
> >   etc.
> > - support for message passing via Netcamlbox (another library)
> > - low-level only so far: shared memory, including copying Ocaml values
> >   to and from shm
> [...]
> 
> You use shared mem(?), but you link only to *.ml files,
> and I see no *.c there.

cd ../netsys

it's part of a larger package

> 
> How can this be done?
> 
> At least not via the libs that are shipped with OCaml?!
> 
> I would have expected some *.c for the shared mem part and
> the creation of Caml-values....
> 
> 
> Ciao,
>     Oliver
> 
> P.S.: OCaml also provides a Thread-Lib, which seems to use pthread-lib.
>        Normally this should help in making things possible to run on multiple
>        cores. What are the restrictions  that this does not run that way?
>        Somehow... when all values are handled via one GC, then those threads
>        are somehow bound together, but on the other side, it works threaded,
>        and consumer-worker pipes and such stuff can be used.
>        So... somehow the GC seems to be the point, where the show will be
>        stopped? (Anyone who has looked inside OCaml here more detailed?)

Quite easy: there is a global lock, and when Ocaml code runs, this lock
must be acquired. So only one of the pthreads can have this lock, and so
only one pthread can run Ocaml code.

The reason is that memory management is not thread-safe.

Gerd

> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 


-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Oliver Bandel]

Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:

> Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
>> Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>:
>>
>> > Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
>> > oliver@first.in-berlin.de:
>> >> On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
>> >> [...]
>> >> >  The main problem was that other languages have bigger standard
>> >> > libraries, whereas OCaml has a very small one (just what is needed
>> >> > to compile the compiler, actually). In many problems, you could
>> >> > benefit from using a very simple shared-memory library (in
>> >> > mandelbrot, the ocaml multicore solution has to copy the image in a
>> >> > socket between processes, whereas it could just be in a shared
>> >> > memory segment),
>> >>
>> >>
>> >> ...so you work on a shared-mem module?!
>> >
>> > Don't know what Fabrice is referring to, but at least I work on a
>> > multicore-enabling library:
>> >
>> >  
>> https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netmulticore/
>> >
>> > This is work in progress and highly experimental. What's currently
>> > available:
>> >
>> > - managing processes and resources like files, shared memory objects
>> >   etc.
>> > - support for message passing via Netcamlbox (another library)
>> > - low-level only so far: shared memory, including copying Ocaml values
>> >   to and from shm
>> [...]
>>
>> You use shared mem(?), but you link only to *.ml files,
>> and I see no *.c there.
>
> cd ../netsys
>
> it's part of a larger package

ah, ok. :)


>
>>
>> How can this be done?
>>
>> At least not via the libs that are shipped with OCaml?!
>>
>> I would have expected some *.c for the shared mem part and
>> the creation of Caml-values....
>>
>>
>> Ciao,
>>     Oliver
>>
>> P.S.: OCaml also provides a Thread-Lib, which seems to use pthread-lib.
>>        Normally this should help in making things possible to run  
>> on multiple
>>        cores. What are the restrictions  that this does not run that way?
>>        Somehow... when all values are handled via one GC, then those threads
>>        are somehow bound together, but on the other side, it works threaded,
>>        and consumer-worker pipes and such stuff can be used.
>>        So... somehow the GC seems to be the point, where the show will be
>>        stopped? (Anyone who has looked inside OCaml here more detailed?)
>
> Quite easy: there is a global lock, and when Ocaml code runs, this lock
> must be acquired. So only one of the pthreads can have this lock,
[...]

Aha, ok.
Thanks for the details.

Wouldn't it be possible for each thread to have it's own GC,
and letting the global lock on global GC only be used, when
global variables are touched?
Then this could be added to the Threads-module...

Ciao,
    Oliver