Re: [Caml-list] Closing the performance gap to C

[Alain Frisch <alain.frisch@lexifi.com>]

On 21/12/2016 17:39, Yotam Barnoy wrote:
> As far as I understand, the current calling convention has to do with
> generic functions.

Indeed.  If you write:

let f x = x +. 1.

let g y = f (y +. 1)

you cannot simply choose a specific calling convention more suited to fp 
arguments/results, because the same function can be used as:

let h l = List.map f l

Currently, the code would be compiled as (pseudo code with explicit 
boxing/unboxing, and explicit function symbol and closures):

let f$direct x = box (unbox x +. 1.)
let f = closure(f$direct)
let g$direct y = f$direct (box (unbox y. +. 1.))
let g y = closure(g$direct)
let h y = List.map f l


> And Alain, even if we create these alternate calling conventions, the
> tricky part is still detecting when it's ok to call using direct
> calling conventions. That's the hard part, and it's best done by
> Flambda with its inlining.

The point is that it's not really hard: there is already some support in 
the compiler to detect direct calls and apply a specific calling 
convention (cf Clambda.Udirect_apply vs Clambda.Ugeneric_apply).  It is 
"just" that this specific calling convention does not do any 
specialization (the same function body is used for the direct calling 
convention and the generic one).

The suggested approach would compile the code above as (assuming no 
inling of f'd nor g'd body):

let f$unboxed x = x +. 1.
let f$direct x = box (f$unboxed (unbox x))
let f = closure(f$direct)

let g$unboxed y = unbox (f$direct (box (y. +. 1.)))
                 = unbox (box (f$unboxed (unbox (box (y. +. 1.)))))
                      (* short-circuit the wrapper *)
                 = f$unboxed  (y. +. 1.)
                      (* collapse unbox(box(..))->.. *)
let g$direct y = box (g$unboxed (unboxed y))
let h l = List.map f l


The fact that g can be compiled to a direct call to f (and not to an 
arbitrary function) is already known to the compiler.  And at the level 
of cmm, one can already describe functions that take unboxed floats (cf 
Cmm.machtype, and the fun_args field in Cmm.fundecl).

What is missing is mostly just the plumbing of type information to know 
that f and g should be compiled as above (i.e. keep track of the type of 
their arguments and result), and arrange so that direct calls 
short-circuit the boxing wrapper.

Now of course there are cases were this strategy would degrade 
performances:  imagine a function taking a float, but using it most 
often as a boxed float (e.g. passing it to Printf.printf "%f"); all call 
sites would still pass an unboxed float (even if the float comes 
naturally in already boxed form) and that function would need to box the 
float again (possibly several times).  This is exactly the same story as 
for the current unboxing strategy (described in 
http://www.lexifi.com/blog/unboxed-floats-ocaml ), where the compiler 
always decides to keep a local "float ref" variable in unboxed form, 
sometimes leading to extra boxing.  But in practice, this works well and 
leads to low-level numerical code work with no boxing at all except at 
data-structure boundaries and function calls (for now).


Alain