I'm seeing huge speed-ups in a benchmark between std.math's sqrt and

>
> import gcc.builtins;
> real sqrt(real r) { return __builtin_sqrtl(r); }.
>

I presume this is because GDC's std.math uses library functions, which become function calls; whereas __builtin_sqrtl is compiled as a single assembler instruction.

Is there any specific reason why GDC's current std.math does not take advantage of GCC's built-in functions?

If there isn't, I'd suggest std.math be changed to call these functions instead, which could lead to significant speed gains in math-heavy programs.

See also: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins

Looking forward to opinions/explanations,
 --downs

downs wrote:
> I'm seeing huge speed-ups in a benchmark between std.math's sqrt and
> 
>> import gcc.builtins;
>> real sqrt(real r) { return __builtin_sqrtl(r); }.
>>
> 
> I presume this is because GDC's std.math uses library functions, which become function
> calls; whereas __builtin_sqrtl is compiled as a single assembler instruction.
> 
> Is there any specific reason why GDC's current std.math does not take advantage of GCC's
> built-in functions?
> 
> If there isn't, I'd suggest std.math be changed to call these functions instead,
> which could lead to significant speed gains in math-heavy programs.
> 
> See also: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins
> 
> Looking forward to opinions/explanations,
>  --downs

So was that the main culprit for the slowdowns in your raytracer test?

--bb

Bill Baxter wrote:
> So was that the main culprit for the slowdowns in your raytracer test?
> 
> --bb

Nope, afraid not. Would have been nice though :)
 --downs, still clueless about gdc performance