2008/12/23 Jon Harrop <[email protected]>: > 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 _______________________________________________ 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
