<creichen>
Nutssh: Entire function definitions that are deemed inline-worthy?
<Nutssh>
I believe so, yes.
<creichen>
OK... guessing from some online mail archives and parts of the sources, it seems that function bodies that don't use "let rec", don't set globals, and don't contain "Uclosure" values (not sure what that is... "anonymous" function values, perhaps) can have their bodies contained in cmx files for inlining purposes.
<creichen>
Nutssh: Thanks for the reference to inlining!
smkl has quit [Read error: 60 (Operation timed out)]
tautologico has joined #ocaml
jinterest has joined #ocaml
smkl has joined #ocaml
jinterest has left #ocaml []
<Smerdyakov>
creichen, if you care about optimization, you shouldn't be using OCaml. :-)
<Nutssh>
Do you advocate C++ and the STL? :)
<KrispyKringle>
Smerdyakov: why not? it's faster than many alternatives.
<Smerdyakov>
MLton, of course.
<Smerdyakov>
I would sure like to see some large whole-project benchmarks of OCaml vs. MLton.
<Nutssh>
I'd probably give mlton a victory in any real program. Ocaml is a non-optimizing compiler.
<Smerdyakov>
The idea is to quantify the difference.
<KrispyKringle>
granted, the shootout.alioth stats are pretty meaningless.
<KrispyKringle>
but compared to, say, haskell, i think there's a clear winner :P
<Nutssh>
That'd be really hard to quantify and probably very application dependent.
<Smerdyakov>
I'd be surprised to see OCaml winning with a significant margin for any application.
<creichen>
Smerdyakov: You definitely have a point with MLton, but it seems to me that what it does is whole-program optimisation, which hardly leaves it as a "fair" contender to, say, plain old C.
<Smerdyakov>
creichen, I don't understand the relevance of that.
<Nutssh>
I've conjectured that the modern systems can support such high ILP, that the extra computations in ocaml don't degrade it much.
<Riastradh>
OCaml performs hardly _any_ optimization, however: no closure conversion, no loop optimization, &c.
<creichen>
Smerdyakov: Well, if you wanted to compile a large program, it wouldn't neccessarily fit into memory. You'll need to spend a lot of time compiling in any case. Unless MLton also supports non-globally optimised compilation somehow, you have to recompile everything for each tiny little change you make.
<Riastradh>
creichen, so don't develop your program with MLton, but build the final product with it.
<KrispyKringle>
Smerdyakov: compiled ocaml binaries seem to be fairly fast, from a subjective standpoint. certainly simply that it has a native code compiler is an edge over the large chunk of interpreted languages, i'd assume.
<creichen>
(Admittedly, if you stick to plain ML, you could use PolyML or SML/NJ or any other SML implementation for development and only use MLton for the final release.)
<Smerdyakov>
creichen, MLton will have such a mode within the next few years.
<creichen>
Sounds good, but, as Riastradh pointed out, it may not really be required.
<Smerdyakov>
It is. MLton is much better maintained than any other SML compiler, if nothing else.
<Smerdyakov>
It's no good to use those others that don't even have up-to-date Debian packages in testing.
<creichen>
Though I'm curious as to whether something like Isabelle could be compiled in MLton on my little machine... I guess I'll have to try that one of these days.
<creichen>
Huh, you're right... there actually is a Debian package for it :-)