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
Google summer of Code proposal
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-03-30 (15:42)
From: Nicolas Cannasse <ncannasse@m...>
Subject: Re: [Caml-list] Google summer of Code proposal
Xavier Leroy a écrit :
>>>    2- OCaml's strategy is close to optimal for symbolic computing.
>> Is MLton not several times faster than OCaml for symbolic computing?
> No, only in your dreams.  If there was a Caml or SML compiler that was
> twice as fast as Caml on codes like Coq or Isabelle/HOL, everyone (me
> included) would have switched to that compiler a long time ago.
> MLton can probably outperform Caml on some symbolic codes, but not by
> a large factor and not because of data representation strategies (but
> rather because of more aggressive inlining and the like).

I agree that OCaml runtime representation is already pretty good, 
although it lacks some runtime inspection abilities.

IMHO, the main optimization that using LLVM can perform wrt OCaml 
internal representation is the ability to fully unbox floats, including 
for FFI callbacks. Of course, that might not help much for symbolic 

As for 5 years for designing a whole system, thanks to today great tools 
(which OCaml is part of), I was myself able to build a complete 
ecosystem with haXe and NekoVM in "only" 2 years, I'm 
pretty sure this can be done much faster when people know exactly what 
they are doing on how they want to get there.