English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
More cores
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-12-23 (09:56)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] More Caml
On Tuesday 23 December 2008 06:07:37 Jon Harrop wrote:
> Yes. I'll do a bit more work on it and then tidy it up and document it
> before uploading it, unless there is any great interest from people now.

Incidentally, I would like to know what performance issues (good and bad) 
people have with the current OCaml implementation?

AFAICT, OCaml evolved from a family of languages that were only optimized for 
symbolic processing. Some of OCaml's relatives, like PolyML, were able to 
provide even faster symbolic processing than naive C but their numerical 
performance is 100x worse. These heavily-skewed performance characteristics 
rendered many ML implementations domain specific.

I believe OCaml was the first ML to put an unusual amount of effort into 
optimizing other aspects, most notably high performance floating-point 
arithmetic and float arrays (where OCaml still thrashes SML/NJ and MLton). 
Moreover, I think OCaml became the world's favourite ML precisely because of 
this diversity.

I am just looking at the simplest possible GC implementations, like shadow 
stack, and trying to envisage an ML implementation that puts a lot more 
effort into numerics and string processing and a lot less effort into 
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?

Anyway, I'll try to implement a simple GC and get some concrete performance 
results first...

Dr Jon Harrop, Flying Frog Consultancy Ltd.