Re: [Caml-list] Efficient OCaml multicore -- roadmap?

[Hugo Ferreira <hmf@inescporto.pt>]

Hi,

Don't mean to drag this on but...

On 03/25/2011 01:10 PM, Fabrice Le Fessant wrote:
> On 03/25/2011 01:58 PM, Hugo Ferreira wrote:
>>>> Assuming all shared data structures are immutable is it possible to:
>
> Well, Java has fully multi-threaded garbage collection, so there is no
> point that it is possible to do it.
>
> The problem is that it has a cost, and the cost is a huge slowdown on
> mono-threaded programs. Since most OCaml programs are mono-threaded, and
> only few programs would really benefit from multi-threading, we are
> trying to come up with a solution that would satisfy both worlds.
> Mono-threaded programs would still run as fast (possibly using a
> non-reentrant version of the runtime, to avoid the cost of TLS if it is
> visible), and multi-threaded programs can be written easily.
>

Personally I think this is an "impossible" feat.
Why not simply allow for the existence of two GC's and let
the programmer select the one that is best for the application?

>   Of course, sharing structured mutable data between threads will not be
> possible, but actually, it is a good thing if you want to write correct
> programs ;-)
>

I'll stick to my guns here. It simply makes solving certain problem
unfeasible. Point in case: I work on machine learning algorithms. I
use large data-structures that must be processed (altered)
in order to learn. Because these data-structures are large it become
impractical to copy this to a process every time I start off a new
"thread".

R,
Hugo F.