www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why the DMD Backend?

reply "Xinok" <xinok live.com> writes:
Given that we have GDC with the GCC backend and LDC with the LLVM 
backend, what are the benefits of keeping the DMD compiler 
backend? It seems to me that GCC and LLVM are far more developed 
and better supported by their respective communities. They have 
superior optimizers and are better equipped for migrating D to 
new platforms. On the other hand, from what I gather, there's 
lots of work to be done on DMD on improving support for x64 
Windows and ARM.

It's a genuine question, which is why I posted this to D.learn. I 
don't follow development on the backend and overall I'm 
unfamiliar with compilers, so I'm not sure what the benefits are 
of the D community continuing to maintain it's own backend.
Nov 28 2014
next sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Fri, 28 Nov 2014 19:59:39 +0000
Xinok via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:


 Given that we have GDC with the GCC backend and LDC with the LLVM=20
 backend, what are the benefits of keeping the DMD compiler=20
 backend?


build time for the whole DMD compiler with standard library, using
G++: 100 seconds. yea, no kidding.

gdc: i don't even want to think about that, way toooo long.

ldc: not that long as gcc, but still much longer than DMD.

besides, for get ready to use compiler with DMD i need only installed
c++ compiler binary. for gdc i need the whole gcc source tree. for ldc
i need installed llvm with it's headers.

DMD is good for fast write-compile-test cycles. and in most cases it's
codegen is satisfying enough.

last, but not least: rdmd is faster than rgdc. ;-)
Nov 28 2014
prev sibling next sibling parent reply "LeakingAntonovPlane" <LeakingAntonovPlane gmx.de> writes:
On Friday, 28 November 2014 at 19:59:40 UTC, Xinok wrote:

 Given that we have GDC with the GCC backend and LDC with the 
 LLVM backend, what are the benefits of keeping the DMD compiler 
 backend? It seems to me that GCC and LLVM are far more 
 developed and better supported by their respective communities. 
 They have superior optimizers and are better equipped for 
 migrating D to new platforms. On the other hand, from what I 
 gather, there's lots of work to be done on DMD on improving 
 support for x64 Windows and ARM.

 It's a genuine question, which is why I posted this to D.learn. 
 I don't follow development on the backend and overall I'm 
 unfamiliar with compilers, so I'm not sure what the benefits 
 are of the D community continuing to maintain it's own backend.


DDMD, bootstraping.
LDC and GDC are not written in D.
Nov 28 2014
parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 28 November 2014 at 20:14:07 UTC, LeakingAntonovPlane 
wrote:

 DDMD, bootstraping.
 LDC and GDC are not written in D.


Pretty sure that DDMD project is not a translation of the backend 
and is only the shared front end source code.
Dec 03 2014
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 28 November 2014 at 19:59:40 UTC, Xinok wrote:

 Given that we have GDC with the GCC backend and LDC with the 
 LLVM backend, what are the benefits of keeping the DMD compiler 
 backend? It seems to me that GCC and LLVM are far more 
 developed and better supported by their respective communities. 
 They have superior optimizers and are better equipped for 
 migrating D to new platforms. On the other hand, from what I 
 gather, there's lots of work to be done on DMD on improving 
 support for x64 Windows and ARM.


The backend comes from the dmc and dmc++ compilers which Walter 
wrote, so he's always going to build against that, both because 
he knows it well and because he refuses to look at source for 
other compilers, for legal reasons.  I don't know that there's 
much work left for Win64, certainly not on the backend.  The dmc 
backend is for Intel only, ie i386 and x64.  No support for ARM 
or any other arch and no plans to add them.


 It's a genuine question, which is why I posted this to D.learn. 
 I don't follow development on the backend and overall I'm 
 unfamiliar with compilers, so I'm not sure what the benefits 
 are of the D community continuing to maintain it's own backend.


What are the drawbacks?  ldc and gdc have their own maintainers.  
I don't think it takes much work to maintain the dmc backend.

On Friday, 28 November 2014 at 20:10:03 UTC, ketmar via 
Digitalmars-d-learn wrote:

 On Fri, 28 Nov 2014 19:59:39 +0000
 Xinok via Digitalmars-d-learn 
 <digitalmars-d-learn puremagic.com> wrote:


 Given that we have GDC with the GCC backend and LDC with the 
 LLVM backend, what are the benefits of keeping the DMD 
 compiler backend?


 build time for the whole DMD compiler with standard library, 
 using
 G++: 100 seconds. yea, no kidding.

 gdc: i don't even want to think about that, way toooo long.

 ldc: not that long as gcc, but still much longer than DMD.


I haven't timed it, but compiling ldc feels about 50-100% longer 
to me, which isn't too bad.  Unless you're including the time to 
compile llvm, which is a different story.

On Friday, 28 November 2014 at 20:14:07 UTC, LeakingAntonovPlane 
wrote:

 DDMD, bootstraping.
 LDC and GDC are not written in D.


That's not the reason, both those projects plan on moving to the 
new D frontend also.  dmd isn't written in D either: they just 
plan on translating the common dmd frontend from C++ to D, then 
using it across all three compilers.  There is a D frontend 
written from scratch in D, SDC, which also uses llvm as the 
backend:

https://github.com/deadalnix/SDC
Nov 29 2014
parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sat, 29 Nov 2014 15:37:32 +0000
Joakim via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 build time for the whole DMD compiler with standard library,=20
 using
 G++: 100 seconds. yea, no kidding.

 gdc: i don't even want to think about that, way toooo long.

 ldc: not that long as gcc, but still much longer than DMD.


=20
 I haven't timed it, but compiling ldc feels about 50-100% longer=20
 to me, which isn't too bad.  Unless you're including the time to=20
 compile llvm, which is a different story.


at least 80%-100% longer. this is noticable.

besides, i don't want to use anything llvm-related.
Nov 29 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/29/14, 3:48 PM, ketmar via Digitalmars-d-learn wrote:

 On Sat, 29 Nov 2014 15:37:32 +0000
 Joakim via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
 wrote:


 build time for the whole DMD compiler with standard library,
 using
 G++: 100 seconds. yea, no kidding.

 gdc: i don't even want to think about that, way toooo long.

 ldc: not that long as gcc, but still much longer than DMD.


 I haven't timed it, but compiling ldc feels about 50-100% longer
 to me, which isn't too bad.  Unless you're including the time to
 compile llvm, which is a different story.


 at least 80%-100% longer. this is noticable.

 besides, i don't want to use anything llvm-related.


Why not?
Nov 29 2014
parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sat, 29 Nov 2014 22:57:52 -0300
Ary Borenszweig via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:


 besides, i don't want to use anything llvm-related.


 Why not?


let's say that there is some "ideological" reasons.
Nov 29 2014
parent reply "MachineCode" <netorib94 gmail.com> writes:
On Sunday, 30 November 2014 at 02:07:16 UTC, ketmar via 
Digitalmars-d-learn wrote:

 On Sat, 29 Nov 2014 22:57:52 -0300
 Ary Borenszweig via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:


 besides, i don't want to use anything llvm-related.


 Why not?


 let's say that there is some "ideological" reasons.


but do you use anything gpl-related?
Dec 02 2014
next sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 03 Dec 2014 01:48:53 +0000
MachineCode via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 On Sunday, 30 November 2014 at 02:07:16 UTC, ketmar via=20
 Digitalmars-d-learn wrote:

 On Sat, 29 Nov 2014 22:57:52 -0300
 Ary Borenszweig via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:


 besides, i don't want to use anything llvm-related.


 Why not?


 let's say that there is some "ideological" reasons.


=20
 but do you use anything gpl-related?


that is exactly the reason i'm against LLVM: it's license. i believe
that compiler and compiler construction tools must be [L]GPLed or
proprietary, but not MITed/BSDLed/SIMILARed.
Dec 02 2014
prev sibling next sibling parent Shriramana Sharma via Digitalmars-d-learn writes:
On Wed, Dec 3, 2014 at 8:03 AM, ketmar via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:

 that is exactly the reason i'm against LLVM: it's license. i believe
 that compiler and compiler construction tools must be [L]GPLed or
 proprietary, but not MITed/BSDLed/SIMILARed.


Heh -- fine for whatever compiler tools *you* create, but if someone
else creates it, and is willing to distribute it under a more liberal
license, why should you find it unacceptable, I'm not sure!

Isn't LGPL largely the same way versus the GPL?

And I'm pretty sure I read somewhere that even the Linux kernel code
(or most big popular L/GPL libs like Qt) has some BSD-licensed stuff
inside it...

BTW isn't Phobos Boost-licensed? And that's almost the same as
BSD/MIT/ISC terms?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா
श्रीरमणशर्मा
Dec 02 2014
prev sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 3 Dec 2014 08:14:53 +0530
Shriramana Sharma via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:


 Heh -- fine for whatever compiler tools *you* create, but if someone
 else creates it, and is willing to distribute it under a more liberal
 license, why should you find it unacceptable, I'm not sure!


'cause BSDL-likes allows proprietary forks. i don't trust proprietary
vendors and i don't want 'em to create slightly incompatible closed fork
which is "better". they have either do all the work by themselves and
release proprietary product from the start, or have no legal way to
fork and close the work of the other people.

i'm not against BSDL-likes per se, the only things i don't want with
such licenses are compiler tools. so i'm not using LLVM-based
compilers, i'm not interested in LLVM-based compilers, and such
compilers are pretty much non-existant in my world.
Dec 02 2014
prev sibling next sibling parent reply "MachineCode" <jckj33 gmail.com> writes:
On Friday, 28 November 2014 at 19:59:40 UTC, Xinok wrote:

 Given that we have GDC with the GCC backend and LDC with the 
 LLVM backend, what are the benefits of keeping the DMD compiler 
 backend? It seems to me that GCC and LLVM are far more 
 developed and better supported by their respective communities. 
 They have superior optimizers and are better equipped for 
 migrating D to new platforms. On the other hand, from what I 
 gather, there's lots of work to be done on DMD on improving 
 support for x64 Windows and ARM.

 It's a genuine question, which is why I posted this to D.learn. 
 I don't follow development on the backend and overall I'm 
 unfamiliar with compilers, so I'm not sure what the benefits 
 are of the D community continuing to maintain it's own backend.


I don't want to download neither gcc or llvm just to use D
language. If so, I could refuse to install and move me away from
the language. I tried to use others compilers which use gcc/llvm
as backend where I had to do alot of workaround just to make it
working on Windows that I just gave up.
Nov 30 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
MachineCode:


 I tried to use others compilers which use gcc/llvm
 as backend where I had to do alot of workaround just to make it
 working on Windows that I just gave up.


I using ldc2 on Windows with no problems, and the installation is 
very easy, just download two archives and unpack them in the 
root. Add a path to your path file, and you are done.

Bye,
bearophile
Nov 30 2014
parent "MachineCode" <jckj33 gmail.com> writes:
On Sunday, 30 November 2014 at 22:15:44 UTC, bearophile wrote:

 MachineCode:


 I tried to use others compilers which use gcc/llvm
 as backend where I had to do alot of workaround just to make it
 working on Windows that I just gave up.


 I using ldc2 on Windows with no problems, and the installation 
 is very easy, just download two archives and unpack them in the 
 root. Add a path to your path file, and you are done.

 Bye,
 bearophile


I wasn't speaking about the ldc(I haven't used it yet) but other 
compilers gcc/llvm-based that I've tried to use a while ago.
Nov 30 2014
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 28 November 2014 at 19:59:40 UTC, Xinok wrote:

 Given that we have GDC with the GCC backend and LDC with the 
 LLVM backend, what are the benefits of keeping the DMD compiler 
 backend? It seems to me that GCC and LLVM are far more 
 developed and better supported by their respective communities. 
 They have superior optimizers and are better equipped for 
 migrating D to new platforms. On the other hand, from what I 
 gather, there's lots of work to be done on DMD on improving 
 support for x64 Windows and ARM.

 It's a genuine question, which is why I posted this to D.learn. 
 I don't follow development on the backend and overall I'm 
 unfamiliar with compilers, so I'm not sure what the benefits 
 are of the D community continuing to maintain it's own backend.


As others have said already, the reasons why I use dmd are:

1. short compilation times which is important when coding both 
big projects and little test programs (i.e. fast prototyping). 
Nothing more annoying than having to wait for "ages" after you've 
made a few minor changes to your code.

 From a PR point of view, this is important, because it gives D an 
advantage over other compiled languages and defeats the argument 
that scripting languages like Python don't have long compilation 
times.

2. dmd works out of the box on all supported OSes. You download 
it and are basically ready to go. GDC and LDC require a bit more 
work in this respect, especially on Windows (which can be a deal 
breaker for newcomers who are curious about the language).

As for the speed, I think that dmd is not too bad in most cases. 
I have a project I wanted to compile with LDC or GDC for the 
release build, but didn't, because the dmd version is already 
very responsive. So I decided to leave well enough alone (at 
least for now).

The thing about ARM is admittedly a chagrin in the behind. But 
what can you do.
Dec 02 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:


 As others have said already, the reasons why I use dmd are:


Walter has developed the back-end of DMD and he wants to keep 
using it no matter what. But I love the very small compilation 
time of dmd sources.

Bye,
bearophile
Dec 02 2014
parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 2 December 2014 at 10:37:18 UTC, bearophile wrote:

 Chris:


 As others have said already, the reasons why I use dmd are:


 Walter has developed the back-end of DMD and he wants to keep 
 using it no matter what. But I love the very small compilation 
 time of dmd sources.

 Bye,
 bearophile


What I was trying to say is that I would be very disappointed if 
we didn't have the dmd backend anymore. It would be a real pain 
in the backend.
Dec 02 2014
prev sibling parent reply "Temtaime" <temtaime gmail.com> writes:
It's only words.
If we speak about LDC it can compile fast in debug mode with 
performance average to DMD's backend but with much great 
performance in release mode thanks to vectorization and other 
techniques.
Also LDC thanks to LLVM supports X86, X86-64, PowerPC, 
PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, 
SystemZ, and XCore platforms. And what about DMD? Only x86 and 
x86-64.

Just link LLVM statically with LDC and LDC will work out of the 
box as DMD. No problems at both Windows and Linux.
Dec 02 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 2 December 2014 at 10:57:20 UTC, Temtaime wrote:

 It's only words.
 If we speak about LDC it can compile fast in debug mode with 
 performance average to DMD's backend but with much great 
 performance in release mode thanks to vectorization and other 
 techniques.
 Also LDC thanks to LLVM supports X86, X86-64, PowerPC, 
 PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, 
 SystemZ, and XCore platforms. And what about DMD? Only x86 and 
 x86-64.

 Just link LLVM statically with LDC and LDC will work out of the 
 box as DMD. No problems at both Windows and Linux.


That's good to hear. I never opposed to LDC nor GCD. In fact, LDC 
has the much needed support for other architectures. But the fact 
remains that dmd is a nice-to-have tool that works out of the 
box, and I don't see why there shouldn't be a dmd backend only 
because we have two other compilers. It always sounds as if a dmd 
backend somehow "harmed" the other two compilers.

Also, one has to set up the LLVM infrastructure etc., which is an 
extra step, unless LLVM works out of the box on Windows, which I 
might not be aware right now.
Dec 02 2014
parent "Temtaime" <temtaime gmail.com> writes:
Setting up LLVM infrastructure is only needed when you is a LDC 
developer.
I think for ordinary users it's not their business.
Dec 02 2014