Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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 (15:32)
From: Ashish Agarwal <agarwal1975@g...>
Subject: Re: [Caml-list] More Caml
> a lot more effort into numerics and string processing and a lot less
effort into
Is there any fundamental reason these two goals must be at odds? Why can't a
compiler be good at numeric and symbolic computation?

On Tue, Dec 23, 2008 at 4:59 AM, Jon Harrop <> wrote:

> 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.
> _______________________________________________
> Caml-list mailing list. Subscription management:
> Archives:
> Beginner's list:
> Bug reports: