IMHO all what is needed is to update the download page with some description of deferences between the compilers, like:

dmd
  - reference compiler, Digital Mars backend
  - best for latest dlang features, fast compile times

gdc
  - GNU gcc backend based compiler
  - best for portability and compatibility with gnu tools

ldc
  - LLVM backend based compiler
  - best for optimized builds, best runtime speed

Note to benchmark users: please use ldc compiler with -inline -O -boundscheck=off (or whatever is correct for LDC) options for best results

On Friday, 29 May 2015 at 20:02:49 UTC, Martin Krejcirik wrote:
> IMHO all what is needed is to update the download page with some description of deferences between the compilers, like:

+1

On Friday, 29 May 2015 at 19:17:14 UTC, Andrei Alexandrescu wrote:
> 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?

http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html?showComment=1432925658409#c6228383399074019471

On Friday, 29 May 2015 at 20:23:13 UTC, Vladimir Panteleev wrote:
> On Friday, 29 May 2015 at 19:17:14 UTC, Andrei Alexandrescu wrote:
>> 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?
>
> http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html?showComment=1432925658409#c6228383399074019471

Thanks,

he updated the results.
DMD

    MD5 - 16.05s (470% slower)
    SHA1 - 2.35s (19% faster)
    SHA256 - 47.96s (690% slower (!))
    SHA512 - 61.47s (1375% slower (!))

LDC2

    MD5 - 2,18s (55% faster)
    SHA1 - 2.88s (same)
    SHA256 - 6,79s (3% faster)
    SHA512 - 4,6s (3% slower)

% is compared to Rust.

On Friday, 29 May 2015 at 20:02:49 UTC, Martin Krejcirik wrote:
> Note to benchmark users: please use ldc compiler with -inline -O -boundscheck=off (or whatever is correct for LDC) options for best results

AFAIK you shouldn't use the -inline flag with LDC, as it tells LDC to run the inline LLVM pass. LDC's inlining is enabled with -enable-inlining and is enabled at -O2 and higher. I believe these are similar except LDC's -enable-inlining has better cost analysis configured for the pass(?)

-inline should probably be renamed because this is confusing due to dmd's usage of it.

But yes, a simple blurb on which compiler flags to use for optimization would probably help as there seems to be some confusion about this due to differing compiler flags. I imagine Iain, Kai, Nadlinger, etc would know which ones to use.

On Friday, 29 May 2015 at 19:16:45 UTC, Steven Schveighoffer wrote:
> 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

For the development cycle too?

On Friday, 29 May 2015 at 22:05:27 UTC, Idan Arye wrote:
>
> For the development cycle too?

I've had LDC edge out dmd in compilation times during development cycle. dmd sees zero boost from separate object compilation.

Using DCD as an example(because it has not-long not-short build times,)

initial non-optimized build took 3.10 elapsed with dmd, 5.11 with ldc.
Changing one file and building took the same amount for dmd but only 0.43 seconds(430 milliseconds) for ldc.

Bye,

On Fri, 29 May 2015 11:58:09 -0700, 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.

the thing is that benchmarks are measuring execution time, not compiling time. that's why D is failing benchmarks. making LDC or GDC a "reference" compiler, and stating that if someone is ready to trade codegen quality for compilation speed, he can use DMD instead, is the way to start being "benchmark friendly".

people doing benchmarks usually downloading what official site gives 'em. so they taking DMD and assuming that it's the best *execution* speed D can offer.

i.e. developers can continue using DMD as their base, but offering it as "experimental compiler not recommended to use in production" on the offsite, replacing "download D compiler" links with LDC/GDC. this way people will not get Hot New Features right away, but "D is sloooow" rants will go down. ;-)

On Fri, 29 May 2015 20:02:47 +0000, Martin Krejcirik wrote:

> dmd
>    - reference compiler, Digital Mars backend - best for latest dlang
>    features, fast compile times
> 
> gdc
>    - GNU gcc backend based compiler - best for portability and
>    compatibility with gnu tools
> 
> ldc
>    - LLVM backend based compiler - best for optimized builds, best
>    runtime speed

does LDC really surpasses GDC in generated code speed?

On Friday, 29 May 2015 at 23:19:36 UTC, ketmar wrote:
> On Fri, 29 May 2015 20:02:47 +0000, Martin Krejcirik wrote:
>
>> dmd
>>    - reference compiler, Digital Mars backend - best for latest dlang
>>    features, fast compile times
>> 
>> gdc
>>    - GNU gcc backend based compiler - best for portability and
>>    compatibility with gnu tools
>> 
>> ldc
>>    - LLVM backend based compiler - best for optimized builds, best
>>    runtime speed
>
> does LDC really surpasses GDC in generated code speed?

yes
GDC is 2-3x slower than LDC on this bench for example.
I think it's because of a lack of cross module inlining.