Tzvetan Mikov (tmikov@gmail.com) on 10/18/06 wrote:
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/18/06 wrote:
>---------------------------
>>Yes. This is quite a serious issue for the future of OCaml as a fast language.
>>The authors of OCaml previously wrote CamlLight. CamlLight was multithreaded properly,
>>but for a variety of reasons it was complex and hard to maintain. OCaml removed
>>this feature. Many other MLs are slowly moving towards supporting multi-processing properly.
>>
>>It's quite possible that in a few years something like Steel Bank Common Lisp may
>>be doing better than OCaml. SBCL already has a reasonable threading system that
>can take advantage of multi-processing.
>>
>>I guess this uncertainty is one of the main problems with using OCaml for performance at present.
>>
>>The reason for this situation is tied up with GC. With a ML like language GC can
>>be made much simpler and more efficient if that language is also single-threaded.
>>This doesn't work so well in impurely functional languages like lisp. If you're curious I'll explain in full.
>
>Please do. Does OCaml use a "tagless" garbage collector ?
>
>I have to admit that efficient multi-threaded GC has always been a murky subject
>for me. Does it require generating explicit write barriers in the code ?

It is possible to make fast single-threaded GCs for an ML. Taking a generational GC, one big problem is that objects in the old generation may point into the new generation. Normally a write barrier is needed to solve this, that is a record of every instance where old points to new.

In a purely functional language, like a classical ML there are no mutable variables, only immutable variables and functions that return values. This can be arranged to mean that no pointers can point from the old generation to the new, dispensing with a write barrier entirely. Doing this is impractical though, and many MLs these days allow mutation in some forms anyway. But even though there tend to be few old->new pointers, and as such little performance degradation caused by the write barrier.

OCaml's GC is a generational GC with two heaps. It incrementally GCs to old object heap, once every minor collection. It has a write barrier, but due to the way people write ML it isn't slowed much by it, if people wrote ML the way they write Java things would be different. Since it's single processor and threading is done at the language level above it doesn't use loads of locks the way a JVM type GC would.

To make the GC possible of multi-processor use it would need locks adding to make things behave. The locks would need to be carefully designed to prevent causing performance problems themselves. The write-barrier would have to be multi-threaded.

So, from the POV of Java for example GC can be painful and MP can make it slightly more painful. From the POV of ML GC is not so painful for the reasons above, and significantly bigger leap in pain is involved to go to MP.

This is all AFAIK, see:-
http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/64c14acb90cb14bedb2cacb73338fb15.en.html
for the view of the big cheese himself.