Re: [Caml-list] More Caml

["Mikkel Fahnøe Jørgensen" <mikkel@dvide.com>]

2008/12/23 Jon Harrop <jon@ffconsultancy.com>:

> symbolics. I am guessing the performance of allocation will be degraded
> 10-100x but many allocations can be removed. This leaves me wondering how
> much slowdown is acceptable without deterring a lot of users?

I think this would be major problem. A great advantage of OCaml is
that you can do things you would not normally do in C/C++ for
performance reasons, like mapping a list.

I believe it is desirable to split allocation into pools dedicated to
each physical thread. Memory barriers are really expensive, such as
used for atomic increment, not to mention locking. Small block
allocation could be done in relatively small heap segments where each
physical thread locks a larger heap only when it needs a new segment,
but not while allocating within a segment. This can further be
improved by adding NUMA support and scope based allocation (arena). If
full segments are marked non-mutable where possible, it is probably
possible to reduce thread blocking during collection. Garbage
collection could be limited to processing full segments. Probably not
trivial though.

How do you think of adding an Erlang style threading model?

Speaking of JIT compiler, would eval make any sense?

Mikkel