Code speed

[Don]

Lars T. Kyllingstad wrote:
> Lars T. Kyllingstad wrote:
>> Don wrote:
>>> Lars T. Kyllingstad wrote:
>>>> Don wrote:
>>>>> bearophile wrote:
>>>>>> So far I've just given a light reading of the code. Notes:
>>>>>
>>>>>> - pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but 
>>>>>> you have to import std.math anyway, because of a bug).
>>>>>
>>>>> That's not a bug. It's intentional. x ^^ y will probably always 
>>>>> require import std.math, if y is a floating point number.
>>>>
>>>> Really?  Why is that?  I find that kind of disappointing, I always 
>>>> believed it to be a temporary solution.
>>>>
>>>> I think the inconsistency with the other operators will make this a 
>>>> major WTF for people new to the language.  Why should a^^b require 
>>>> an explicit import while a*b doesn't?
>>>
>>> Because pow() for floating point, when implemented properly, is a 
>>> HUGE function, that ends up dragging almost all of std.math into the 
>>> executable. And I think it's deceptive to do that silently.
>>> To make it completely built-in, basically all of std.math would need 
>>> to be moved into druntime. Feel free to try to change my mind, of 
>>> course.
>>
>> Exponentiation is a built-in operation in FORTRAN, so I made this 
>> little program to check:
>>
>>       program test
>>
>>       implicit none
>>       real  :: base, expo, pow
>>
>>       write (*,*) "Base:"
>>       read  (*,*) base
>>       write (*,*) "Exponent:"
>>       read  (*,*) expo
>>
>>       pow = base**expo
>>       write (*,*) pow
>>
>>       end program test
>>
>> The produced executable is 11K.  If I replace exponentiation with 
>> multiplication, it is still 11K.  Why wouldn't the same be possible in D?
> 
> Scratch that, I just remembered that libgfortran is dynamically linked 
> in by default.  However, compiling with -static-libgfortran makes the 
> executable 155K with both exponentiation and multiplication.
> 
> -Lars

I have a vague recollection that correctly-rounded pow() will require 
bigint (can't quite remember, though). I'm also concerned about build 
tools -- I don't want them to have to know about the dependency.
As a bare minimum, the error message will need to improve (with some 
explanation of why std.math is required, to reduce the WTF factor).
But in any case, it's a very minor issue.
Personally, I'm finding that having ^^ as standard nomenclature is 
extremely useful, even apart from the use in code.