dmd makes D appear slow

[Manu via Digitalmars-d]

On 30 May 2015 at 09:14, ketmar via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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. ;-)

I actually think this is a really good idea. I don't think it's right
that random people should encounter DMD as a first impression, they
should encounter GDC or LDC, since those are the toolsets they will be
making direct comparisons against during their evaluation. At the
point that they're not yet a D enthusiast, access to cutting edge
language features should mean practically nothing to them.

That said, it would be nice if the DMD developer community at large
were able to work closer with GDC/LDC. Is there some changes in
workflow that may keep GDC/LDC up to date beside DMD as PR's are
added? Possible to produce 'nightlies' for those compilers, so that
developers following mainline DMD can easily update their respective
compilers to reflect? Perhaps DMD developers could even develop
language features against LDC instead of DMD, and backport to DMD?

For my work, and what I noticed in my other thread, is that LDC is
central to expansion of the D ecosystem, and I think it needs to be
taken more seriously by the entire DMD community; it can't be a little
thing off to the side.
LDC gives us portability; iOS, Android, Windows, Emscripten,
NativeClient, and plenty of other platforms. It's 2015; the fact that
we still don't support Android and iOS is just not unacceptable. Most
computers in the world run those operating systems. LDC is also the
only performant way to target Windows, the overwhelmingly largest
desktop platform... but we lose the debugger! >_<
How can we release products created with D if we still don't have a
way to build and run on modern computers?

So, LDC: Windows, Android, iOS... this must be 99.9999% of computers
on the planet! LDC needs to be first-class. Ideally, even more
polished than DMD, and it should probably be the first contact people
have with D.

* I don't mean to down-play GDC, but it can't give us Windows or iOS,
which are critical targets.


I want to use D in my work, right now. I could... if I could actually
target the computers we run code on.