I'm having a pretty good experience with win64 ldc lately. Obviously the fact that there's no debug info is a gigantic hole.
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. The biggest problem I have with ldc, is that lots of normal compiler errors pop up an ICE instead of a normal error message. On 30 May 2015 1:26 pm, "Rikki Cattermole via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > On 30/05/2015 1:43 p.m., Manu via Digitalmars-d wrote: > >> On 30 May 2015 at 09:14, ketmar via Digitalmars-d >> <digitalmars-d@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. >> > > Both you and ketmer are evil. > I'm liking these ideas... > > Now we just need some pretty and nice packages for e.g. Windows for ldc > with debugger full support and we will be good. > 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 ;) >
