On 1/23/2013 6:36 PM, Rob T wrote:
> BTW the D version of my sqlite3 lib is at least 1/3 smaller than the C++
> version, and not only is it smaller, but it is far more flexible due to the use
> of templates (I just could not make much use out of C++ templates). A reduction
> like that is very significant. For large projects. it's a drastic reduction in
> development costs and perhaps more so in long term maintenance costs.

Interesting. I found the same percentage reduction in translating C++ code to D.

On Thursday, 24 January 2013 at 02:19:06 UTC, Era Scarecrow wrote:
> On Thursday, 24 January 2013 at 00:35:13 UTC, Joshua Niehus wrote:
>> On Thursday, 24 January 2013 at 00:29:15 UTC, Joshua Niehus wrote:
>>> You don't need to compete, you can take established "good and fast" FORTRAN/C code and use it within your own D program.
>>
>> I forgot to add:
>> If you doing new stuff then D can be as fast as anything eles, provided the algorithm is sound, optimizers turned on, sprinkle in a lil assembly, etc...
>
>  And use nothrow when it's applicable; Found with a sudoku solver how much nothrow was making an impact on the algorithm speed.

Do you know why ? It shouldn't.

On 01/24/2013 11:16 AM, Walter Bright wrote:
> If you use the 64 bit model, dmd will use SIMD instructions for float and
> double, which are much faster.

I generally find that dmd-compiled programs run at about half the speed of those built with gdc or ldc (the latter seem pretty much equivalent these days, some programs run faster compiled with one, some with the other).  That's running off latest GitHub source for all compilers.

That's been a fairly consistent speed difference for a long time.  And yes, I'm using 64-bit.

On 1/24/2013 2:41 AM, Joseph Rushton Wakeling wrote:
> That's been a fairly consistent speed difference for a long time.  And yes, I'm
> using 64-bit.

Is that with floating point code, or otherwise?

On 01/24/2013 11:49 AM, Walter Bright wrote:
> Is that with floating point code, or otherwise?

Yes, quite heavily floating-point.  I did once have a brief go at writing some entirely integer-based number-crunching code just to see if it made any difference, but I think other priorities intervened ... :-)

On Thursday, 24 January 2013 at 10:42:10 UTC, Joseph Rushton Wakeling wrote:
> On 01/24/2013 11:16 AM, Walter Bright wrote:
>> If you use the 64 bit model, dmd will use SIMD instructions for float and
>> double, which are much faster.
>
> I generally find that dmd-compiled programs run at about half the speed of those built with gdc or ldc (the latter seem pretty much equivalent these days, some programs run faster compiled with one, some with the other).  That's running off latest GitHub source for all compilers.
>
> That's been a fairly consistent speed difference for a long time.  And yes, I'm using 64-bit.

Same for me. The difference between ldc and dmd seems to be mainly due to optimizing and especially inlining (see http://d.puremagic.com/issues/show_bug.cgi?id=9320 for an example in that matter).

On Thursday, 24 January 2013 at 10:42:10 UTC, Joseph Rushton Wakeling wrote:
> On 01/24/2013 11:16 AM, Walter Bright wrote:
>> If you use the 64 bit model, dmd will use SIMD instructions for float and
>> double, which are much faster.
>
> I generally find that dmd-compiled programs run at about half the speed of those built with gdc or ldc (the latter seem pretty much equivalent these days, some programs run faster compiled with one, some with the other).  That's running off latest GitHub source for all compilers.
>
> That's been a fairly consistent speed difference for a long time.  And yes, I'm using 64-bit.

I had similar experience with all my numerical code. gdc and ldc trade places but dmd is always solidly behind.

Walter, I know you like working with the current backend and you understand it etc..., but this gives dmd a bus factor of 1 and is slowing down code in the process.

On 01/24/2013 02:11 PM, John Colvin wrote:
> Walter, I know you like working with the current backend and you understand it
> etc..., but this gives dmd a bus factor of 1 and is slowing down code in the
> process.

Honestly, I don't feel this is too strong an issue.  The point of dmd is to be a reference compiler -- speed is nice if it's possible, but not the most important consideration.

The most important thing is that new frontend updates can get merged quickly into ldc/gdc, so that there is no time lag between new feature development and their incorporation into other compilers.

On Thu, Jan 24, 2013 at 05:28:16PM +0100, Joseph Rushton Wakeling wrote:
> On 01/24/2013 02:11 PM, John Colvin wrote:
> >Walter, I know you like working with the current backend and you understand it etc..., but this gives dmd a bus factor of 1 and is slowing down code in the process.
> 
> Honestly, I don't feel this is too strong an issue.  The point of dmd is to be a reference compiler -- speed is nice if it's possible, but not the most important consideration.

I think it would be ideal if the dmd front end were more isolated from the back end, so that it's easier to port to gdc/ldc (i.e. it can happen in the matter of days after a dmd release, not, say, weeks or months).

But I believe Walter has already said that patches to this effect are welcome, so I can only see the situation improve in the future.

Nevertheless, I also have made the same observation that code produced by gdc consistently outperforms code produced by dmd. Usually by about 20-30%, sometimes as much as 50-60%, IME. That's a pretty big discrepancy for me, esp. when I'm doing compute-intensive geometric computations.


> The most important thing is that new frontend updates can get merged quickly into ldc/gdc, so that there is no time lag between new feature development and their incorporation into other compilers.

Agreed.


T

-- 
It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton

On Thursday, 24 January 2013 at 16:28:29 UTC, Joseph Rushton Wakeling wrote:
> On 01/24/2013 02:11 PM, John Colvin wrote:
>> Walter, I know you like working with the current backend and you understand it
>> etc..., but this gives dmd a bus factor of 1 and is slowing down code in the
>> process.
>
> Honestly, I don't feel this is too strong an issue.  The point of dmd is to be a reference compiler -- speed is nice if it's possible, but not the most important consideration.

Fair point, i guess the reference doesn't have to be fastest.

> The most important thing is that new frontend updates can get merged quickly into ldc/gdc, so that there is no time lag between new feature development and their incorporation into other compilers.

This would be really great.