Browse thread
Strange observation on polymorphic '<'
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-12-03 (08:23) |
From: | Ville-Pertti Keinonen <will@e...> |
Subject: | Re: [Caml-list] Strange observation on polymorphic '<' |
On Fri, 2004-12-03 at 02:24 -0500, Ritesh Kumar wrote: > let max a b = if a>b then a else b;; > print_int (max 2 3);; > ============ > Separate compilation means that the function max should use the C call > (for the toplevel module). However, the invocation of max 2 3 shouldn't > use a direct call to the function in the same module as the invocation > is in the same module (i.e. there is opportunity to optimize it based The decision of whether to inline a function is done based on its size. You can increase the inlining level to allow for larger functions to be inlined. However, apparently inlining is currently done after deciding whether to call the polymorphic function, so it doesn't help in this case, which is definitely a missed optimization opportunity. > on the known invocation types). Secondly, does separate compilation > make that strong a sense in case of native compilation for OcaML ... > most probably not because it anyways generates a standalone executable? OCaml supports inlining across compilation units, so eliminating separate compilation probably wouldn't automatically give you any benefits. There is at least one compiler for a related language (Standard ML) that does global analysis by compiling everything at once (MLtoN). It's quite a bit more complex compared to OCaml, doesn't generate significantly faster code for common cases, and supports far fewer platforms. MLtoN does have the nice ability to support unboxed, untagged integers, though.