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

[Yotam Barnoy <yotambarnoy@gmail.com>]

On Mon, Dec 19, 2016 at 12:09 PM, Frédéric Bour
<frederic.bour@lakaban.net> wrote:
> The problem observed is not because of spilling but simply because of float
> boxing and compilation of recursive calls.
> The loop seems to compile down to an efficient code ended by a jump, but
> float unboxing is done in a much earlier pass in the compiler (cmm).
>
> Passing -dcmm to the compiler, we can see that before the recursive call to
> loop the float is boxed again.
> At this point, it is just a regular ocaml function call, taking boxed float.
>
> A simpler code to observe this behavior:
>
> let rec test f =
>   test (f +. 1.0)
>
> let () = test 0.0
>
> will box at every iteration.

Yes, this is a current weak point of OCaml compilation, which I've
reported here (https://caml.inria.fr/mantis/view.php?id=7289). The
only real solution to this currently is to improve Flambda to the
point that unboxing is done at the Flambda level rather than at
cmmgen. Unboxing decisions are currently extremely local, which isn't
good enough for recursive functions, which cannot be inlined.
Currently, the only solution to this is to use a. for/while loops or
b. a global mutable value instead of a parameter.

-Yotam

>
> Le 19 déc. 2016 à 17:41, Gerd Stolpmann <info@gerd-stolpmann.de> a écrit :
>
> Michael,
>
> look here, it's the "definitive source":
> https://github.com/ocaml/ocaml/blob/trunk/asmcomp/amd64/proc.ml
>
> Windows is in deed different. I don't have enough insight into the
> register spilling algorithm to say whether this has a significant
> effect, though. OCaml code never keeps registers alive, and thus I
> would bet the spilling algorithm is designed for that, and it is
> probably not tried to move values preferably to xmm6-15 in order to
> avoid spilling during C calls. But that's just a hypothesis... Does
> somebody know?
>
> Gerd
>
>
> Am Montag, den 19.12.2016, 14:52 +0000 schrieb Soegtrop, Michael:
>
> Dear Gerd,
>
>
> When you call a C function like cos it is likely that this
> happens because the C calling conventions do not preserve the FP
> registers
> (xmm*). This could be improved if the OCaml compiler tried
> alternate places for
> temporarily storing FP values:
>
> For Windows this doesn't seem to be true. See e.g.:
>
> https://msdn.microsoft.com/en-us/library/ms235286.aspx
>
> which states that XMM0..XMM5 are volatile, while XMM6..XMM15 must be
> preserved.
>
> I think for Linix you are right. I couldn't find a better reference
> than Wikipedia:
>
> https://en.wikipedia.org/wiki/X86_calling_conventions
>
> see "System V AMD64 ABI" there.
>
> This reference contains a good overview, which matches the above data
> in table 4:
>
> http://www.agner.org/optimize/calling_conventions.pdf
>
> So on Windows, there is for sure no need to save XMM6..XMM15, while
> on Linux this seems to be an issue.
>
> Best regards,
>
> Michael
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>
> --
> ------------------------------------------------------------
> Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> My OCaml site:          http://www.camlcity.org
> Contact details:        http://www.camlcity.org/contact.html
> Company homepage:       http://www.gerd-stolpmann.de
> ------------------------------------------------------------
>
>