[m-dev.] Fwd: single-precision floats on 64 bit platforms

Julien Fischer jfischer at opturion.com
Thu Apr 30 17:34:49 AEST 2020


On Thu, 30 Apr 2020, Zoltan Somogyi wrote:

> ----- Start Forwarded Message -----
> Sent: Thu, 30 Apr 2020 16:32:03 +1000 (AEST)
> From: "Zoltan Somogyi" <zoltan.somogyi at runbox.com>
> To: "developers" <developers at lists.mercurylang.org>
> Subject: single-precision floats on 64 bit platforms
>
> On 32 bit platforms, spf grades could be a major performance win
> for applications that didn't need double precision, because it avoided boxing.
> On 64 bit platforms, that is not an issue. On 64 bit platforms, for code
> like this:
>
> :- type t
>    --->    f(int, float, int).
>
> :- func test(float) = t.
> test(F) = f(41, F, 42).
>
> we generate the exact same code in both hlc.gc.spf and hlc.gc, namely
>
> MR_hl_field(MR_mktag(0), HeadVar__2_2, 0) = ((MR_Box) (Var_4));
> MR_hl_field(MR_mktag(0), HeadVar__2_2, 1) = MR_box_float(F_3);
> MR_hl_field(MR_mktag(0), HeadVar__2_2, 2) = ((MR_Box) (Var_5));
>
> With spf on 64 bit platforms, we are using only 32 bits of that middle word.
> This does not seem to be a problem, since I don't recall hearing anyone
> complain about it. So on 64 bit platforms, the only possible benefit of
> spf grades is that float multiplies and divides *may* be a bit faster
> than double multiplies and divides, though on most FP-intensive workloads,
> such differences will be lost in the noise of the cost of traffic to and from
> main memory. (IIRC, on most platforms, FP addition and subtraction take
> just one cycle for both floats and doubles, due to carry lookahead.)

Or I may be using 32-bit floats because I am interacting with some
API that uses them (e.g. single-precision floats are one of the pixel
data formats in OpenGL).

> At the moment, the documentation of the spf grade (what little there is
> of it) makes no mention of the fact that its use makes sense only
> on 32 bit platforms.
>
> I think it would improve the situation if we took one of two actions:
>
> (a) documenting that spf reduces memory usage only on 32 bit platforms, or
>
> (b) ignoring the setting of the spf grade component on 54 bit platforms,
> and documenting this fact.

I think if we now dealing with _54_ bit platforms as well we've got bigger
problems than this ;-)

I vote for option (a).

That said, I think we should get rid of the spf grades entirely, fix
Mercury's float type to be 64-bit float and introduce a second 32-bit
float type.  With the possible exception of Erlang, that's what all
the target languages provide anyway.

Julien.


More information about the developers mailing list