In nearly every benchmark I see D in, the default compiler used is dmd which runs computationally intense tasks 4-5x+ slower than GDC/LDC

example of a random blog post I found:
http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html

D is up to 10x(!) slower than Rust.

Well... dmd is. Under LDC:
MD5 is 5x faster,
SHA1 is about the same,
SHA256 is 10x faster,
SHA512 is 10x faster.

The kicker?
_all_ of these were faster than the Rust timings(albeit by 5-10%) when using LDC.

This isn't the first time I've seen this, in basically every benchmark featuring D I have to submit a patch/make a comment that dmd shouldn't be used. Make no mistake, this is damaging to D's reputation - how well does D's "native efficiency" go over when people are saying it's slower than Scala and F#(mono)?

LDC and GDC need promoted more.

Bye,

On Fri, May 29, 2015 at 06:13:02PM +0000, weaselcat via Digitalmars-d wrote:
> In nearly every benchmark I see D in, the default compiler used is dmd which runs computationally intense tasks 4-5x+ slower than GDC/LDC

As I keep saying, in my own compute-intensive projects I have consistently found that dmd-generated code (dmd -O -inline -release) is about 20-30% slower on average, sometimes even up to 50% slower, compared to gdc-generated code (gdc -O3 -finline -frelease). This is measured by actual running time in an actual application, not benchmark-specific code.

I have looked at the generated assembly before, and it's clear that the gdc optimizer is way ahead of dmd's. The dmd optimizer starts failing to inline inner loop code after about 1-2 levels of function call nesting, not to mention it's unable to factor out a lot of loop boilerplate code.

The gdc optimizer, by contrast, not only factors out almost all loop boilerplate code and inlines inner loop function calls several levels deep, it also unrolls loops in a CPU-specific way, does major loop restructuring, compounded with much more linear code optimization than dmd does, instruction reordering and then refactoring after that, etc., in some cases reducing the size of inner loop code (as in, the amount of code that runs per iteration) by up to 90%.

I don't know the internal workings of the dmd optimizer, but it's clear that at present, with almost nobody working on it except Walter, it's never going to catch up. (Maybe this statement will provoke Walter into working his magic? :-P)


[...]
> This isn't the first time I've seen this, in basically every benchmark featuring D I have to submit a patch/make a comment that dmd shouldn't be used. Make no mistake, this is damaging to D's reputation - how well does D's "native efficiency" go over when people are saying it's slower than Scala and F#(mono)?
> 
> LDC and GDC need promoted more.
[...]

This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you fail to deliver after.

On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
> This will probably offend some people, but I think LDC/GDC should be the
> default download on dlang.org, and dmd should be provided as an
> alternative for those who want the latest language version and don't
> mind the speed compromise.

I did make LDC default compiler used in Arch but now people are unhappy with increased compile times so I may need to revert it back :)

On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d wrote:
> On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
> >This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise.
> 
> I did make LDC default compiler used in Arch but now people are unhappy with increased compile times so I may need to revert it back :)

Can't please 'em all... According to Walter, many D users want fast compile times, and aren't as concerned about performance of the generated code. But from this thread's OP, it seems there's another group of users who don't care about fast compile times but want the generated code to squeeze every last drop of performance from their CPUs.

So I guess we should be equally recommending all 3 compilers, with a note to help people choose their compiler depending on their needs.


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N

On 29 May 2015 20:15, "weaselcat via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> In nearly every benchmark I see D in, the default compiler used is dmd
which runs computationally intense tasks 4-5x+ slower than GDC/LDC
>
> example of a random blog post I found:
>
http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html
>
> D is up to 10x(!) slower than Rust.
>
> Well... dmd is. Under LDC:
> MD5 is 5x faster,
> SHA1 is about the same,
> SHA256 is 10x faster,
> SHA512 is 10x faster.
>
> The kicker?
> _all_ of these were faster than the Rust timings(albeit by 5-10%) when
using LDC.
>
> This isn't the first time I've seen this, in basically every benchmark
featuring D I have to submit a patch/make a comment that dmd shouldn't be used. Make no mistake, this is damaging to D's reputation - how well does D's "native efficiency" go over when people are saying it's slower than Scala and F#(mono)?
>
> LDC and GDC need promoted more.
>
> Bye,

It's also hurting in a lot of recent pull requests I've been seeing. People are going out their way to micro optimise code for DMD, but ultimately their intention ends up being rejected because of GDC/LDC providing said optimisations for free.  It's not just PR, but also a waste/drain on resource for people who could be better focusing their limited free time.

On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
> On Fri, May 29, 2015 at 06:13:02PM +0000, weaselcat via Digitalmars-d wrote:
>> In nearly every benchmark I see D in, the default compiler used is dmd
>> which runs computationally intense tasks 4-5x+ slower than GDC/LDC
>
> As I keep saying, in my own compute-intensive projects I have
> consistently found that dmd-generated code (dmd -O -inline -release) is
> about 20-30% slower on average, sometimes even up to 50% slower,
> compared to gdc-generated code (gdc -O3 -finline -frelease). This is
> measured by actual running time in an actual application, not
> benchmark-specific code.
>
> I have looked at the generated assembly before, and it's clear that the
> gdc optimizer is way ahead of dmd's. The dmd optimizer starts failing to
> inline inner loop code after about 1-2 levels of function call nesting,
> not to mention it's unable to factor out a lot of loop boilerplate code.
>
> The gdc optimizer, by contrast, not only factors out almost all loop
> boilerplate code and inlines inner loop function calls several levels
> deep, it also unrolls loops in a CPU-specific way, does major loop
> restructuring, compounded with much more linear code optimization than
> dmd does, instruction reordering and then refactoring after that, etc.,
> in some cases reducing the size of inner loop code (as in, the amount of
> code that runs per iteration) by up to 90%.
>
> I don't know the internal workings of the dmd optimizer, but it's clear
> that at present, with almost nobody working on it except Walter, it's
> never going to catch up. (Maybe this statement will provoke Walter into
> working his magic? :-P)

dmd's backend is also under a proprietary license reducing the amount of people willing to contribute.
Not to mention that GDC and LDC benefit heavily from GCC and LLVM respectively, these aren't exactly one man projects(e.g, Google, Redhat, Intel, AMD etc contribute heavily to GCC and LLVM is basically Apple's baby.)

>
>
> [...]
>> This isn't the first time I've seen this, in basically every benchmark
>> featuring D I have to submit a patch/make a comment that dmd shouldn't
>> be used. Make no mistake, this is damaging to D's reputation - how
>> well does D's "native efficiency" go over when people are saying it's
>> slower than Scala and F#(mono)?
>> 
>> LDC and GDC need promoted more.
> [...]
>
> This will probably offend some people, but I think LDC/GDC should be the
> default download on dlang.org, and dmd should be provided as an
> alternative for those who want the latest language version and don't
> mind the speed compromise.
>
>
> T

I think they probably should be if only for the licensing issues, dmd can't even be redistributed - AFAIK it's in very, very few D repositories on Linux.


re dicebot:

>I did make LDC default compiler used in Arch but now people are unhappy with increased compile times so I may need to revert it back :)

Maybe this should be brought up on LDC's issue tracker(that is, slower compilation times compared to dmd.)
Although it might have already been discussed.

On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
> On Fri, May 29, 2015 at 06:13:02PM +0000, weaselcat via Digitalmars-d wrote:
>> In nearly every benchmark I see D in, the default compiler used is dmd
>> which runs computationally intense tasks 4-5x+ slower than GDC/LDC
>
> As I keep saying, in my own compute-intensive projects I have
> consistently found that dmd-generated code (dmd -O -inline -release) is
> about 20-30% slower on average, sometimes even up to 50% slower,
> compared to gdc-generated code (gdc -O3 -finline -frelease). This is
> measured by actual running time in an actual application, not
> benchmark-specific code.
>
> I have looked at the generated assembly before, and it's clear that the
> gdc optimizer is way ahead of dmd's. The dmd optimizer starts failing to
> inline inner loop code after about 1-2 levels of function call nesting,
> not to mention it's unable to factor out a lot of loop boilerplate code.
>
> The gdc optimizer, by contrast, not only factors out almost all loop
> boilerplate code and inlines inner loop function calls several levels
> deep, it also unrolls loops in a CPU-specific way, does major loop
> restructuring, compounded with much more linear code optimization than
> dmd does, instruction reordering and then refactoring after that, etc.,
> in some cases reducing the size of inner loop code (as in, the amount of
> code that runs per iteration) by up to 90%.
>
> I don't know the internal workings of the dmd optimizer, but it's clear
> that at present, with almost nobody working on it except Walter, it's
> never going to catch up. (Maybe this statement will provoke Walter into
> working his magic? :-P)
>
>
> [...]
>> This isn't the first time I've seen this, in basically every benchmark
>> featuring D I have to submit a patch/make a comment that dmd shouldn't
>> be used. Make no mistake, this is damaging to D's reputation - how
>> well does D's "native efficiency" go over when people are saying it's
>> slower than Scala and F#(mono)?
>> 
>> LDC and GDC need promoted more.
> [...]
>
> This will probably offend some people, but I think LDC/GDC should be the
> default download on dlang.org, and dmd should be provided as an
> alternative for those who want the latest language version and don't
> mind the speed compromise.
>
>
> T

LDC can work wonders, indeed. I've seen it. Drawback: GDC and LDC lag behind.

D doesn't like legacy code, so I always update my code.

Maybe we could synchronize dmd, ldc and gdc faster? Dmd is the only way to update your code.

On Friday, 29 May 2015 at 19:01:18 UTC, H. S. Teoh wrote:
> On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d wrote:
>> On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
>> >This will probably offend some people, but I think LDC/GDC should be
>> >the default download on dlang.org, and dmd should be provided as an
>> >alternative for those who want the latest language version and don't
>> >mind the speed compromise.
>> 
>> I did make LDC default compiler used in Arch but now people are
>> unhappy with increased compile times so I may need to revert it back
>> :)
>
> Can't please 'em all... According to Walter, many D users want fast
> compile times, and aren't as concerned about performance of the
> generated code. But from this thread's OP, it seems there's another
> group of users who don't care about fast compile times but want the
> generated code to squeeze every last drop of performance from their
> CPUs.
>
> So I guess we should be equally recommending all 3 compilers, with a
> note to help people choose their compiler depending on their needs.
>
>
> T

I think it might be worth investigating why LDC/GDC are slower than dmd when compiling non-optimized builds. This seems like something that would be easier to solve than getting dmd up to the same performance level as LDC/GDC.
Bye,

On 5/29/15 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d wrote:
>> On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
>>> This will probably offend some people, but I think LDC/GDC should be
>>> the default download on dlang.org, and dmd should be provided as an
>>> alternative for those who want the latest language version and don't
>>> mind the speed compromise.
>>
>> I did make LDC default compiler used in Arch but now people are
>> unhappy with increased compile times so I may need to revert it back
>> :)
>
> Can't please 'em all... According to Walter, many D users want fast
> compile times, and aren't as concerned about performance of the
> generated code. But from this thread's OP, it seems there's another
> group of users who don't care about fast compile times but want the
> generated code to squeeze every last drop of performance from their
> CPUs.
>
> So I guess we should be equally recommending all 3 compilers, with a
> note to help people choose their compiler depending on their needs.

myOpinion = (fastCompileTimes * 10000 < fastCode);

-Steve

On 5/29/15 12:13 PM, weaselcat wrote:
> In nearly every benchmark I see D in, the default compiler used is dmd
> which runs computationally intense tasks 4-5x+ slower than GDC/LDC
>
> example of a random blog post I found:
> http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html

One problem here is pointed by the blogger: "I tried to compile with LDC2 and failed (windows 7 x64): ..."

Can he be helped?


Andrei