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 (17:30)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] More Caml
On Tuesday 23 December 2008 15:32:52 Ashish Agarwal wrote:
> > a lot more effort into numerics and string processing and a lot less
> > effort into symbolics.
> Is there any fundamental reason these two goals must be at odds?

No theoretical reason, AFAIK.

> Why can't a compiler be good at numeric and symbolic computation?

The required performance characteristics appear to be mutually exclusive when 
it comes to GCs.

Symbolics benefit enormously from extremely fast allocation rates for 
short-lived values and numerics benefit enormously from efficient handling of 
shared memory. Today's GCs either provide one or the other. OCaml is ideal 
for symbolics and awful for parallel programming. The CLR is awful for 
symbolics and good for parallel programming. The JVM is arguably the best 
trade-off but its run-time cannot handle tail calls, which makes it a useless 
for performant functional languages.

In the case of the compiler I'm writing, there are more pressing practical 
concerns. Primarily that it is extremely difficult to write an efficient GC 
like OCaml's, if not impossible within the confines of LLVM (and LLVM is the 
only thing making this feasible for me). I believe I can get some kind of GC 
working, possibly even a parallel GC. Moreover, I think I can remove all 
(performance) overhead associated with automatic memory management from 
numerical routines. I think that would be very compelling even if it were bad 
for symbolics...

Dr Jon Harrop, Flying Frog Consultancy Ltd.