On Fri, 29 May 2015 23:29:39 +0000, weaselcat wrote:

> 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.

thanks for the info.

On 5/29/15 4:05 PM, Idan Arye wrote:
> 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);
>
> For the development cycle too?

I saw the slide from Liran that shows your compiler requirements :) I can see why it's important to you.

But compiled code outlives the compiler execution. It's the wart that persists.

But techniques (for most projects) are available to speed compile time, and even in that case, compile time for whole project is quite low.

For very large projects, toolchain performance is definitely important. We need to work on that.

But I don't see how speed of compiler should sacrifice runtime performance.

-Steve

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.

On Sat, 30 May 2015 11:43:07 +1000, Manu via Digitalmars-d wrote:

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

just to note: ARM is supported in GDC (althru i never tested that support myself), and there are semi-official windows builds of GDC.

so GDC can give us windows support (it's simply not required by many GDC users for the time), but this is relatively easy to fix.

dunno about iOS specifics, but if LDC has some druntime fixes for that, such fixes can be integrated in mainline, and GDC should be able to build ARM binaries for that apple thingy.

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 ;)

On Saturday, 30 May 2015 at 03:24:45 UTC, Rikki Cattermole wrote:
>
> 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 ;)

LDC seemed to work for the author of the blog on windows after fixing a path issue. After a quick look in the LDC NG, it seems to be mostly(?) working.

It feels like GDC/LDC are fragmented from the main D community which isn't good due to an already not-so-large community. Outside of manually going to check their issue trackers it's hard to know what's going on with them.

Bye,

On 30/05/2015 3:36 p.m., weaselcat wrote:
> On Saturday, 30 May 2015 at 03:24:45 UTC, Rikki Cattermole wrote:
>>
>> 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 ;)
>
> LDC seemed to work for the author of the blog on windows after fixing a
> path issue. After a quick look in the LDC NG, it seems to be mostly(?)
> working.
>
> It feels like GDC/LDC are fragmented from the main D community which
> isn't good due to an already not-so-large community. Outside of manually
> going to check their issue trackers it's hard to know what's going on
> with them.
>
> Bye,

Even as of a few months ago LLVM wasn't fully working on 64bit Windows.
The llvm debugger had a long way to go for it.

So hopefully its come along way since then :)

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 ;)
>

On Saturday, 30 May 2015 at 04:01:00 UTC, Manu wrote:
> 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.

Does it generate any debug info at all, or does it just lack PDB debug info?
If the former, have you tried visualGDB with it(assuming you're using VS)?

Just a guess, I don't use windows. : )

On 30 May 2015 05:25, "ketmar via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Sat, 30 May 2015 11:43:07 +1000, Manu via Digitalmars-d wrote:
>
> > * I don't mean to down-play GDC, but it can't give us Windows or iOS, which are critical targets.
>
> just to note: ARM is supported in GDC (althru i never tested that support myself), and there are semi-official windows builds of GDC.
>
> so GDC can give us windows support (it's simply not required by many GDC users for the time), but this is relatively easy to fix.
>

When he says Windows, he means MSVC, gcc backend will never support interfacing that ABI (at least I see no motivation as of writing).