On Sunday 20 December 2009 12:21:44 Erik Rigtorp wrote: > On Sun, Dec 20, 2009 at 05:43, Jon Harrop <j...@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 _______________________________________________ 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
