Re: [***SPAM*** Score/Req: 10.1/8.0] Re: [Caml-list] Re: OCaml is broken

[Jon Harrop <jon@ffconsultancy.com>]

On Sunday 20 December 2009 12:21:44 Erik Rigtorp wrote:
> On Sun, Dec 20, 2009 at 05:43, Jon Harrop <jon@ffconsultancy.com> wrote:
> > As long as you're looking at OCaml's close relatives with multicore
> > support, F# is your only viable option. Soon, HLVM will provide a
> > cross-platform open source solution. If you look further you will also
> > find Scala and Clojure.
>
> F# is not viable since i'm developing for Solaris.

Yes. F# is Windows only for all intents and purposes.

> I also believe the .NET GC is not good enough for real-time systems.

Although heavily allocating threads will experience pauses of up to several 
seconds on .NET. However, threads that do not exceed their allocation quota 
run almost completely concurrently with the GC, so their real-time 
performance characteristics are good. This is the key to keeping UI threads 
responsive.

Note that OCaml's GC has some problems. Specifically, the stack and arrays of 
pointers in the heap are not traversed incrementally, incurring 
arbitrarily-long stalls.

> Clojure running under real-time Java might be interesting.

Sounds like you have hard RT guarantees.

> It's too bad that INRIA is not interested in fixing this bug.

They spent something like a decade trying to write a decent concurrent GC and 
pioneered the field.

> No matter what people say I consider this a bug.

A perf bug at best: it just means that OCaml is slower for many tasks.

> Two cores is standard by 
> now, I'm used to 8, next year 32 and so on. OCaml will only become
> more and more irrelevant. I hate to see that happening.

Me too. The OCaml language will continue to kick ass for some time to come but 
INRIA's implementation is no longer competitively performant for many tasks. 
However, open source offerings are all quite dire, particularly stand-alone 
ones.

> I think right now only Erlang got this right and they have a great
> library for developing enterprise applications too!

I couldn't disagree more. The *only* reason to work on parallelism is 
performance and Erlang's performance sucks. I know Erlang scales better, but 
it scales from poor absolute performance on 1 core to poor absolute 
performance on n cores. Hence Erlang is hardly the defacto standard for HPC 
on shared-memory supercomputers.

> The first step for OCaml would be to be able to run multiple
> communicating instances of the runtime bound to one core each in one
> process and have them communicate via lock free queues.

I think the first step is simply to replace OCaml's GC with a stop-the-world 
parallel one like the one I wrote for HLVM. The problem is that OCaml's data 
representation gives absolutely dire performance and kills scalability if you 
do that. So you either need to optimize the GC for this or rewrite everything 
from the ground up. OC4MC is doing the former. My HLVM project is doing the 
latter. Suffice to say, there is no easy solution (although I prefer 
mine ;-).

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e