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

["Frédéric Bour" <frederic.bour@lakaban.net>]

[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]

OCamlopt is able to spill floating point register.
You can even see with -dalloc that the code will spill a floating point register in the loop.

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.

> 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 <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 <mailto:gerd@gerd-stolpmann.de>
> My OCaml site:          http://www.camlcity.org <http://www.camlcity.org/>
> Contact details:        http://www.camlcity.org/contact.html <http://www.camlcity.org/contact.html>
> Company homepage:       http://www.gerd-stolpmann.de <http://www.gerd-stolpmann.de/>
> ------------------------------------------------------------


[-- Attachment #2: Type: text/html, Size: 21661 bytes --]