On 1/24/13 5:21 AM, deadalnix wrote:
> 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.

More code motion. It's a classic in C++ code as well (where it's mode difficult to detect).

Andrei

On Thursday, 24 January 2013 at 10:21:47 UTC, deadalnix wrote:
> On Thursday, 24 January 2013 at 02:19:06 UTC, Era Scarecrow wrote:
>> 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.

 As mentioned somewhere, with nothrow the compiler can drop various checks and support for exceptions (assert/ensure don't throw exceptions, they throw errors instead).

 How big this overhead is I'm not sure, but the speedup in my code went from some 30 seconds down to 7 or so. But nothrow can't be used everywhere.

On 1/24/2013 8:36 AM, H. S. Teoh wrote:
> 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.

Do you mean floating point code? 32 or 64 bit?

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.

You are taking care to compare with full optimization flag settings? I'm sure you are, but I ask just in case.

--rt

There is also Plot2Kill, that David Simcha developed for his own thesis, to do 2D drawings:

https://github.com/dsimcha/Plot2kill


I used it 1 (2?) years ago, and it worked well. It was quite nice to be able to generate / manipulate data in D, and then to keep the same powerful language for graphs.

On Thu, Jan 24, 2013 at 12:15:07PM -0800, Walter Bright wrote:
> On 1/24/2013 8:36 AM, H. S. Teoh wrote:
> >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.
> 
> Do you mean floating point code? 32 or 64 bit?

Floating-point, 64-bit, tested on dmd -O vs. gdc -O3.


T

-- 
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous

On 1/24/2013 1:13 PM, H. S. Teoh wrote:
> On Thu, Jan 24, 2013 at 12:15:07PM -0800, Walter Bright wrote:
>> On 1/24/2013 8:36 AM, H. S. Teoh wrote:
>>> 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.
>>
>> Do you mean floating point code? 32 or 64 bit?
>
> Floating-point, 64-bit, tested on dmd -O vs. gdc -O3.

Next, are you using floats, doubles, or reals?

On 01/24/2013 10:05 PM, Rob T wrote:
> You are taking care to compare with full optimization flag settings? I'm sure
> you are, but I ask just in case.

I use -O -release -inline typically (I use the dmd-ish interfaces for gdc and ldc as well).

Absent any optimizations, executables seem to run at about the same speed no matter what compiler is used.  Interestingly, at least on the code that I just tested with, the different compilers react differently to different optimizations: dmd gains much less from -O than gdmd, and ldmd2 gains much more than both of the others.  Adding -inline doesn't seem to affect executable speed at all (this is probably a quirk of the particular code I'm testing with). Adding -release speeds up executables about as much as -O (for dmd and gdmd) and maybe makes a slight additional speedup for ldmd2.

With -O -release -inline, executables compiled with gdmd and ldmd2 seem to run at about the same speed.  Interestingly, using -release alone results in about the same executable speed for both gdmd and ldmd2, but using -O alone means ldmd2-compiled executables are as fast as gdmd-compiled executables compiled with both -O and -release.

That surely means that these identical DFLAGS translate in practice into different underlying optimizations depending on the compiler.

Of course, these are very casual and trivial tests using a single piece of code -- here if you want to repeat the tests: https://github.com/WebDrake/Dregs -- but they reflect my typical experience with the different D compilers.

On 01/25/2013 01:02 AM, Joseph Rushton Wakeling wrote:
> but they reflect my typical experience with the different D compilers.

The caveat here is that these results are typical for _number-crunching_ code. If the dominant factor in your program's speed is e.g. console output, you'll find the differences between the compilers much less noticeable.  For example: I have a piece of code that implements a Monte Carlo simulation and prints an update of its status at each time step -- with -O -release -inline flags, this runs in about 23s with gdmd, 25 with ldmd2 and 28 with dmd.

If I remove the writef statements, leaving just the number-crunching part, it runs in about 4s with gdmd, 7s with ldmd2 and 14s (!) with dmd.

On 01/24/2013 05:36 PM, H. S. Teoh wrote:
> 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).

Case in point -- today I got bitten by this issue:
http://forum.dlang.org/thread/sntkmtabuhuctcbnlsgq@forum.dlang.org

AFAICT it's fixed in 2.061, and it certainly doesn't show up when compiling with latest-git dmd.  But as 2.061 isn't yet merged into ldc or gdc, both of these compilers are temporarily out of commission ...

> 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.

Yes, my impression too, and I know that some people have been putting work towards it.