Comment by mas644 | Hacker News Reader

Comment by mas644 | Hacker News Reader

Look, I love OCaml and it's my favorite language syntax-wise, but the real big elephant in the room is not its JS-backend maturity. Rather it doesn't have kernel thread support...all threads are user-level just like Python due to a global lock for garbage collection. This means threads do not run concurrently across multiple cores. This is UNACCEPTABLE in 2014 - roughly 8 years since processors went multi-core. Intel is talking about having hundreds of cores on a single die by next decade and having programs that can't take advantage of that is extremely limiting.

Xavier Leroy (the creator of OCaml) and his team at INRIA didn't think this was a big deal because when they were writing this stuff, processors were single core and had been since the beginning. Sure there were multiprocessor machines (not the same as multicore as there are multiple die), but those were only meant for servers/workstations. OCaml seemed very promising around 2006, the peak and end of the single core era with the Intel Pentium 4. What made OCaml so impressive was not only was it this beautifully simple, high-level functional language, but that the native compiler produced very fast code that was comparable to C/C++ performance. However, as multicore processors were introduced (Intel Core, Core 2), not having this capability made writing new code in OCaml less appealing. There are solutions like MPI, but that's lame. The same excuses you hear in the Python world about having true multithreading you hear in the OCaml world. Microsoft was able to do it with F#, which is essentially a clone of Caml by targeting their .NET CLR. Haskell is able to do it with GHC.

I still think OCaml is a wonderful language -- not having true multithreading doesn't make it useless. However, to me it has become more like a statically-typed Python which I can use for scripting. Having to use hacks like MPI to do multicore processing is a huge turn off in a multicore world. This is again nothing against the language, but the standard implementation needs a concurrent garbage collector and kernel threads. Otherwise I think OCaml may be doomed to irrelevance in the long run, which would be truly sad.

Apparently multicore ocaml is worked on again: https://github.com/ocamllabs/compiler-hacking/wiki/Multicore... https://github.com/ocamllabs/compiler-hacking/wiki/Multicore...

That being said you can still use multiple cores by using multiple processes, and that doesn't necesarelly imply MPI. OCamlNet (and probably some other libraries) provide a way to communicate between multiple OCaml processes.

Good to see work is being done on it, but until it's in the main implementation for at least a year...I wouldn't trust it on anything that matters.

The advantage of kernel threads is that they have way less overhead than a process (both in context size as well as more efficient memory caching at processor and OS level)...though more than a user-level thread. If there isn't any sort of message passing between two processes, the only mechanism I can think of of sharing data is shared memory (i.e and mmap) which is just as efficient as threads sharing the same process heap...but awkward (yes there are sockets, file IO, signals, queues, etc, but not as efficient). Even if OCaml provides a way to abstract that to be more palatable + safe -- my argument is that in a multicore world, kernel threads must be a first class citizen and the programmer shouldn't have to resort to tricks to harness it -- otherwise it's a major flaw that is going to prevent future adaptation. Also, as the number of cores increase, this is going to matter more and more...so hopefully this stuff gets out in the wild soon.

The multithreading situation in Haskell is pretty exciting. Simon Marlow's Parallel and Concurrent Programming in Haskell is the best new programming book I've picked up in a long time. And there are new developments since he wrote it (http://www.haskellcast.com/episode/004-simon-marlow-on-paral...). It would be a shame to give all that up.

What's interesting about Haskell in this regard is due to the pure functional nature, the Church-Rosser theorem applies...every function call could be executed in its own thread without protecting any resources with locks/mutexes/etc! I haven't studied the compiler design of Haskell, do you know if the compiler can delegate function calls to a thread pool automatically?

This won't be a problem for very long. See http://www.cl.cam.ac.uk/~sd601/multicore.md for the working design.

But "someday we'll only be a decade behind haskell" isn't much of a reason to choose ocaml over haskell.

I don't think multicore will be touted as a reason to choose OCaml over Haskell, but it will remove one of the reasons to avoid OCaml. Subtle but important difference :)

It won't though. Because it'll still be a decade behind haskell. People want more than just "ok, you can use multiple OS threads now". They want a concurrent IO manager, painless and seemless multiplexing of low cost green threads over OS threads, and high level concurrency and parallelism constructs. It is going to take a long time for ocaml to catch up to haskell in this department, and who knows what haskell is going to be offering by then.

Yeah, I should've addressed this in my post. Right now multicore doesn't mean squat to me as I'm using it for JavaScript support. I did investigate this, but forgot to add the links (others have already replied with) about work that is progressing nicely.

I'll update the post once this traffic calms down a bit :)

The situation is improving, specially with companies like Facebook and Microsoft using it.

However I do think that from the ML family, F# might be the one getting more widespread.

Reply on news.ycombinator.com