Plea for inline expansion of transcendentals.

Plea for inline expansion of transcendentals.

[David McClain]

Since I do a great deal of bluk math processing, it would sure be nice if
many of the simpler transcendental functions could be inlined by OCAMLOPT.
I'm speaking primarily of round_to_int, sin, cos, tan, asin, acos, atan,
atan2, log, exp, sqrt, etc.

I modified the 2.02 compiler to support these and found that the necessary
changes were really quite easy to make. But I don't look forward to making
these same mods every time a new compiler is released.

Of course I am working on Pentium class machines which have these functions
available in hardware. Other arhitectures might not be so kind in this
regard...

David McClain

Re: Plea for inline expansion of transcendentals.

[Xavier Leroy]

> Since I do a great deal of bluk math processing, it would sure be nice if
> many of the simpler transcendental functions could be inlined by OCAMLOPT.
> I'm speaking primarily of round_to_int, sin, cos, tan, asin, acos, atan,
> atan2, log, exp, sqrt, etc.
> Of course I am working on Pentium class machines which have these functions
> available in hardware. Other arhitectures might not be so kind in this
> regard...

One difficulty with the FSIN, FCOS, etc, Pentium instructions is that
they fail if the argument is greater than 2^64 (if I remember
correctly).  To produce a correct result in all cases, the error must
be trapped and the operation retried after suitable normalization of
the argument.  This makes it difficult to inline those operations.

(Note: I said "correct result", not "meaningful result".  No one in
their right minds would compute sin(2^64), but still we have to
produce the same result as everyone else even in this case.)

- Xavier Leroy

Re: Plea for inline expansion of transcendentals.

[Xavier Leroy]

> It seems better to fail in this case, as the part of the number
> which is significant for these periodic functions is completely lost
> by the machine precision, so the renormalization is useless, isn't
> it ?

Yes, the result of sin(2^64) is totally meaningless.  However,
the Single Unix specification doesn't say that there is a range of
values for the argument of "sin" outside of which we can return an
error (however, it says "The sin() function may lose accuracy when its
argument is far from 0.0", which could be interpreted as "we can
return any wrong result"...)

> The best would be to trap and raise an ML exception (Silly_Trigo :-).

The trapping itself isn't trivial and requires a few instructions,
making the inlining of "sin" less interesting.

> Actually ocaml2.04 toplevel (I have not try the compilers) does
> something very silly:
> 
> #  sin(10.0);;
> - : float = -0.544021110889
> # sin(10e21);;
> - : float = 1e+22    
> 
> Using Ocaml I can therefore prove -1 <  1e+22  < 1 .... Whooo :-) 

Nice example.  You must be using RedHat Linux 6 on a PC :-)  The
toplevel and bytecode compiler use whatever "sin" function is provided
by the C compiler and C library.  If the latter is correct, you'll get
correct results.  Your example works fine under Digital Unix, for instance.

But it so happens that under RH 6.1, the "sin" function in the C
library does the right thing (perform the "fsin" instruction, check
for overflow, and normalize and try again if necessary), but "gcc -O"
generates directly an "fsin" instruction -- "gcc" without -O calls the
C library function.  I view this as a gcc bug, though.

- Xavier Leroy

Re: Plea for inline expansion of transcendentals.

[David McClain]

I can appreciate the desire to keep the language pure and proper, but I must
say that in nearly 30 years of experience I have never been tempted to take
the sin of 2^64. I would suggest that an inline version of the basic
transcendentals be made available along the same lines that unsafe_get and
unsafe_set are made available for array access. They are inlined for speed,
and provide little or no error checking. Their use is flagged by the
prominent "unsafe" prefix in the source text, and the option is available to
the end user as to when to use them....

- DM

-----Original Message-----
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>
Cc: caml-list@inria.fr <caml-list@inria.fr>
Date: Monday, December 13, 1999 7:48 AM
Subject: Re: Plea for inline expansion of transcendentals.


>> It seems better to fail in this case, as the part of the number
>> which is significant for these periodic functions is completely lost
>> by the machine precision, so the renormalization is useless, isn't
>> it ?
>
>Yes, the result of sin(2^64) is totally meaningless.  However,
>the Single Unix specification doesn't say that there is a range of
>values for the argument of "sin" outside of which we can return an
>error (however, it says "The sin() function may lose accuracy when its
>argument is far from 0.0", which could be interpreted as "we can
>return any wrong result"...)
>
>> The best would be to trap and raise an ML exception (Silly_Trigo :-).
>
>The trapping itself isn't trivial and requires a few instructions,
>making the inlining of "sin" less interesting.
>
>> Actually ocaml2.04 toplevel (I have not try the compilers) does
>> something very silly:
>>
>> #  sin(10.0);;
>> - : float = -0.544021110889
>> # sin(10e21);;
>> - : float = 1e+22
>>
>> Using Ocaml I can therefore prove -1 <  1e+22  < 1 .... Whooo :-)
>
>Nice example.  You must be using RedHat Linux 6 on a PC :-)  The
>toplevel and bytecode compiler use whatever "sin" function is provided
>by the C compiler and C library.  If the latter is correct, you'll get
>correct results.  Your example works fine under Digital Unix, for instance.
>
>But it so happens that under RH 6.1, the "sin" function in the C
>library does the right thing (perform the "fsin" instruction, check
>for overflow, and normalize and try again if necessary), but "gcc -O"
>generates directly an "fsin" instruction -- "gcc" without -O calls the
>C library function.  I view this as a gcc bug, though.
>
>- Xavier Leroy
>