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
processing...
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 http://haxe.org 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.
Best,
Nicolas
_______________________________________________
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
