D 50% slower than C++. What I'm doing wrong?

[Joseph Rushton Wakeling]

On 15/04/12 09:23, ReneSac wrote:
>> What really amazes me is the difference between g++, DMD and GDC in size of
>> the executable binary. 100 orders of magnitude!
> I have remarked it in another topic before, with a simple "hello world". I need
> to update there, now that I got DMD working. BTW, it is 2 orders of magnitude.

Ack.  Yes, 2 orders of magnitude, 100 _times_ larger.  That'll teach me to send 
comments to a mailing list at an hour of the morning so late that it can be 
called early. ;-)

>> Sounds stupid as the C stuff should be fastest, but I've been surprised
>> sometimes at how using idiomatic D formulations can improve things.
>
> Well, it may indeed be faster, especially the IO that is dependent on things
> like buffering and so on. But for this I just wanted something as close as the
> C++ code as possible.

Fair dos.  Seems worth trying the idiomatic alternatives before assuming the 
speed difference is always going to be so great, though.

> Yeah, I don't know. I just did just throw those qualifiers against the compiler,
> and saw what sticks. And I was testing the decode speed specially to see easily
> if the output was corrupted. But maybe it haven't corrupted because the compiler
> don't optimize based on "pure" yet... there was no speed difference too.. so...

I think it's because although there's mutability outside the function, those 
variables are still internal to the struct.  e.g. if you try and compile this code:

       int k = 23;

       pure int twotimes(int a)
       {
             auto b = 2*a;
             auto c = 2*k;
             return b+c;
       }

... it'll fail, but if you try and compile,

       struct TwoTimes
       {
             int k = 23;

             pure int twotimes(int a)
             {
                   auto b = 2*a;
                   auto c = 2*k;
                   return b+c;
             }
       }

... the compiler accepts it.  Whether that's because it's acceptably pure, or 
because the compiler just doesn't detect this case of impurity, is another 
matter.  The int k is certainly mutable from outside the scope of the function, 
so AFAICS it _should_ be disallowed.