<p dir="ltr">I'm having a pretty good experience with win64 ldc lately. Obviously the fact that there's no debug info is a gigantic hole.</p>
<p dir="ltr">I have a hack environment where I dmd in debug and ldc for release builds, but it's really not ideal. And you're limited to code that doesn't expose bugs in both compilers.</p>
<p dir="ltr">The biggest problem I have with ldc, is that lots of normal compiler errors pop up an ICE instead of a normal error message.</p>
<div class="gmail_quote">On 30 May 2015 1:26 pm, "Rikki Cattermole via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 30/05/2015 1:43 p.m., Manu via Digitalmars-d wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 30 May 2015 at 09:14, ketmar via Digitalmars-d<br>
<<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, 29 May 2015 11:58:09 -0700, H. S. Teoh via Digitalmars-d wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, May 29, 2015 at 06:50:02PM +0000, Dicebot via Digitalmars-d<br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This will probably offend some people, but I think LDC/GDC should be<br>
the default download on <a href="http://dlang.org" target="_blank">dlang.org</a>, and dmd should be provided as an<br>
alternative for those who want the latest language version and don't<br>
mind the speed compromise.<br>
</blockquote>
<br>
I did make LDC default compiler used in Arch but now people are unhappy<br>
with increased compile times so I may need to revert it back :)<br>
</blockquote>
<br>
Can't please 'em all... According to Walter, many D users want fast<br>
compile times, and aren't as concerned about performance of the<br>
generated code. But from this thread's OP, it seems there's another<br>
group of users who don't care about fast compile times but want the<br>
generated code to squeeze every last drop of performance from their<br>
CPUs.<br>
<br>
So I guess we should be equally recommending all 3 compilers, with a<br>
note to help people choose their compiler depending on their needs.<br>
</blockquote>
<br>
the thing is that benchmarks are measuring execution time, not compiling<br>
time. that's why D is failing benchmarks. making LDC or GDC a "reference"<br>
compiler, and stating that if someone is ready to trade codegen quality<br>
for compilation speed, he can use DMD instead, is the way to start being<br>
"benchmark friendly".<br>
<br>
people doing benchmarks usually downloading what official site gives 'em.<br>
so they taking DMD and assuming that it's the best *execution* speed D<br>
can offer.<br>
<br>
i.e. developers can continue using DMD as their base, but offering it as<br>
"experimental compiler not recommended to use in production" on the<br>
offsite, replacing "download D compiler" links with LDC/GDC. this way<br>
people will not get Hot New Features right away, but "D is sloooow" rants<br>
will go down. ;-)<br>
</blockquote>
<br>
I actually think this is a really good idea. I don't think it's right<br>
that random people should encounter DMD as a first impression, they<br>
should encounter GDC or LDC, since those are the toolsets they will be<br>
making direct comparisons against during their evaluation. At the<br>
point that they're not yet a D enthusiast, access to cutting edge<br>
language features should mean practically nothing to them.<br>
<br>
That said, it would be nice if the DMD developer community at large<br>
were able to work closer with GDC/LDC. Is there some changes in<br>
workflow that may keep GDC/LDC up to date beside DMD as PR's are<br>
added? Possible to produce 'nightlies' for those compilers, so that<br>
developers following mainline DMD can easily update their respective<br>
compilers to reflect? Perhaps DMD developers could even develop<br>
language features against LDC instead of DMD, and backport to DMD?<br>
<br>
For my work, and what I noticed in my other thread, is that LDC is<br>
central to expansion of the D ecosystem, and I think it needs to be<br>
taken more seriously by the entire DMD community; it can't be a little<br>
thing off to the side.<br>
LDC gives us portability; iOS, Android, Windows, Emscripten,<br>
NativeClient, and plenty of other platforms. It's 2015; the fact that<br>
we still don't support Android and iOS is just not unacceptable. Most<br>
computers in the world run those operating systems. LDC is also the<br>
only performant way to target Windows, the overwhelmingly largest<br>
desktop platform... but we lose the debugger! >_<<br>
How can we release products created with D if we still don't have a<br>
way to build and run on modern computers?<br>
<br>
So, LDC: Windows, Android, iOS... this must be 99.9999% of computers<br>
on the planet! LDC needs to be first-class. Ideally, even more<br>
polished than DMD, and it should probably be the first contact people<br>
have with D.<br>
<br>
* I don't mean to down-play GDC, but it can't give us Windows or iOS,<br>
which are critical targets.<br>
<br>
<br>
I want to use D in my work, right now. I could... if I could actually<br>
target the computers we run code on.<br>
</blockquote>
<br>
Both you and ketmer are evil.<br>
I'm liking these ideas...<br>
<br>
Now we just need some pretty and nice packages for e.g. Windows for ldc with debugger full support and we will be good.<br>
Last time I looked llvm still needs a lot of work for Windows unfortunately. It may be time to direct some people to help them out ;)<br>
</blockquote></div>