double precision calculations in single precision code

Jeff Johnston jjohnstn@redhat.com
Wed Oct 31 16:19:00 GMT 2012


On 10/24/2012 12:09 PM, marco atzeri wrote:
> On 10/24/2012 1:30 PM, Branko Drevenšek wrote:
>> Hi.
>>
>> We have Newlib ported to our architecture. One of configurations that we
>> support is hardware single precision and soft-float double precision.
>>
>> I have noticed unexpected double precision soft-float function calls in
>> simple code like x = sinf(y), where both x and y are single precision.
>>
>> I have noticed that Newlib sinef function (libm/mathfp/sf_sine.c)
>> contains lines like:
>>    /* Calculate the exponent. */
>>    if (y < 0.0)
>>      N = (int) (y * ONE_OVER_PI - 0.5);
>>    else
>>      N = (int) (y * ONE_OVER_PI + 0.5);
>>
>> While y * ONE_OVER_PI gets calculated in single precision, that +- 0.5
>> causes the result of multiplication being converted to double and then
>> addition is done in double using soft-float. For our case this has big
>> performance penalty and also requires double soft-float functions to be
>> linked in, causing binary to grow.
>>
>> Is 0.5 (instead of 0.5f) used by purpose or is that just wrong (and
>> needs fixing)? Where did those math. functions originate from?
>>
>
> I bet from the double version, that use exactly the same lines
> and they are likely in that form from the begin in 98.
> On CVS there is no change from inital import in 2000..
>

These functions were an experiment from a Red Hat intern for running on 
a system with floating-point math instructions.  The algorithms chosen 
for some of the functions don't provide close to adequate accuracy for 
the large range of input possibilities and in the end, they didn't  show 
any real performance improvements in testing.

Consider the experiment a failure.  I long ago said I was going to 
remove them but I thought somebody might be interested in further 
experimentation and possibly fixing the algorithms.  I will add a README 
in the directory, comment out the configuration option, and also add an 
explanation in the top-level README so nobody else wastes their time.

-- Jeff J.


>  > Best regards,
>  > Branko Drevensek
>
>



More information about the Newlib mailing list