www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How fast is D compilation compared to C++?

reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
D's CTFE can make D compilation infinitely slow. Let's put anomalous 
cases aside...

We say D compiles much faster than C++. Does anyone have any measurement 
or a gut feeling about the same program written in idiomatic C++ vs. 
idiomatic D? I think it may be 30 seconds vs. 5 seconds. I that a fair 
guess?

Although a ballpark figure is good enough, precise measurements would be 
useful as well.

Thank you,
Ali
Sep 20 2022
next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 20 September 2022 at 16:13:30 UTC, Ali Çehreli wrote:

 D's CTFE can make D compilation infinitely slow. Let's put 
 anomalous cases aside...

 We say D compiles much faster than C++. Does anyone have any 
 measurement or a gut feeling about the same program written in 
 idiomatic C++ vs. idiomatic D? I think it may be 30 seconds vs. 
 5 seconds. I that a fair guess?

 Although a ballpark figure is good enough, precise measurements 
 would be useful as well.


The change in DMD from version 2.67 to 2.68 where the backend 
went from C++ to D is one example that allows a comparison. Fair 
in the sense that both backend were 1 to 1 translation but not 
really representative as no advanced C++ or D features (template, 
CDFE, etc.. were used).

Compiling DMD on our server at work using 2GHZ intel of 4th 
generation (single thread) went from a little less than 2 minutes 
for 2.67 to just a little above 8s.
Sep 20 2022
prev sibling next sibling parent reply Krzysztof =?UTF-8?B?SmFqZcWbbmljYQ==?= <krzysztof.jajesnica gmail.com> writes:
On Tuesday, 20 September 2022 at 16:13:30 UTC, Ali Çehreli wrote:

 D's CTFE can make D compilation infinitely slow. Let's put 
 anomalous cases aside...

 We say D compiles much faster than C++. Does anyone have any 
 measurement or a gut feeling about the same program written in 
 idiomatic C++ vs. idiomatic D? I think it may be 30 seconds vs. 
 5 seconds. I that a fair guess?

 Although a ballpark figure is good enough, precise measurements 
 would be useful as well.

 Thank you,
 Ali


Out of curiosity I tried comparing build times for 2 personal 
projects (one written in C++, the other written in D).

The C++ project is ~3k lines of code (including header files) and 
takes ~8s to do a clean debug build with GCC+CMake (~2s for a 
parallel build).

The D project is ~8k lines of code, takes ~1.4s to build with 
DMD+DUB and ~3.6s to build with LDC. Unfortunately DUB seems to 
be much worse than CMake at parallelising the build (or maybe my 
spaghetti is a bit difficult to build in parallel) because 
building with `dub --parallel` takes basically the same amount of 
time.

Both projects are small video games using GLFW+OpenGL and very 
few dependencies beyond that. The D project has 2-3 cases of 
horrible CTFE/template abuse which is absent in the C++ project 
and uses templates a bit more extensively. The C++ project has 
more low level code.

Overall it seems that for single threaded debug builds D compiles 
~15-20 times faster (per line of code) than C++ with DMD and ~5-7 
times faster with LDC.

You should only treat these numbers as very rough estimates, 
since I'm not exactly comparing apples to apples here.
Sep 20 2022
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/20/22 12:10, Krzysztof Jajeśnica wrote:


 You should only treat these numbers as very rough estimates, since I'm
 not exactly comparing apples to apples here.


Of course. I appreciate your taking time to measure the build times.

Ali
Sep 20 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 20 September 2022 at 20:41:45 UTC, Ali Çehreli wrote:

 On 9/20/22 12:10, Krzysztof Jajeśnica wrote:


 You should only treat these numbers as very rough estimates,


 since I'm

 not exactly comparing apples to apples here.


 Of course. I appreciate your taking time to measure the build 
 times.

 Ali


My game engine, wich is quite big now, compiles in 1second with 
dmd, ~1.5sec with ldc, in debug build

A full clean rebuild!

My old c++ game engine project full recompiles in ~30 seconds



Long live D!
Sep 20 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 20 September 2022 at 22:10:52 UTC, ryuukk_ wrote:

 On Tuesday, 20 September 2022 at 20:41:45 UTC, Ali Çehreli 
 wrote:

 On 9/20/22 12:10, Krzysztof Jajeśnica wrote:


 You should only treat these numbers as very rough estimates,


 since I'm

 not exactly comparing apples to apples here.


 Of course. I appreciate your taking time to measure the build 
 times.

 Ali


 My game engine, wich is quite big now, compiles in 1second with 
 dmd, ~1.5sec with ldc, in debug build

 A full clean rebuild!

 My old c++ game engine project full recompiles in ~30 seconds



 Long live D!


I advise to eventually cross check those numbers against C++ 
modules.

In Visual C++, the C++23 "import std" (which includes the 
complete standard library), is faster than a plain "#include 
<iostream>".

Naturally for the forseable future, C++ modules are something 
that only Visual C++ users can enjoy, as other commercial vendors 
with forks taken out of GCC and clang aren't that keen into 
providing upstream support for better ISO C++ compliance.
Sep 21 2022
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 21 September 2022 at 07:55:22 UTC, Paulo Pinto 
wrote:

 On Tuesday, 20 September 2022 at 22:10:52 UTC, ryuukk_ wrote:

 On Tuesday, 20 September 2022 at 20:41:45 UTC, Ali Çehreli 
 wrote:

 On 9/20/22 12:10, Krzysztof Jajeśnica wrote:


 You should only treat these numbers as very rough estimates,


 since I'm

 not exactly comparing apples to apples here.


 Of course. I appreciate your taking time to measure the build 
 times.

 Ali


 My game engine, wich is quite big now, compiles in 1second 
 with dmd, ~1.5sec with ldc, in debug build

 A full clean rebuild!

 My old c++ game engine project full recompiles in ~30 seconds



 Long live D!


 I advise to eventually cross check those numbers against C++ 
 modules.

 In Visual C++, the C++23 "import std" (which includes the 
 complete standard library), is faster than a plain "#include 
 <iostream>".

 Naturally for the forseable future, C++ modules are something 
 that only Visual C++ users can enjoy, as other commercial 
 vendors with forks taken out of GCC and clang aren't that keen 
 into providing upstream support for better ISO C++ compliance.


I tried C++20 modules when visual studio added support for it

It made a huge improvement, but you still had to forward declare 
everything, wich i don't want to do anymore, hence why i quit C++ 
and rewrote my engine in D, wich is now much larger than the C++ 
one, and yet still fully compiles in 1sec with dmd (i do not use 
phobos, i do use templates and type introspection, with care! i 
run my build always with time, so i know whenever i introduce 
something that slow things down)
Sep 21 2022
prev sibling next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 20 September 2022 at 16:13:30 UTC, Ali Çehreli wrote:

 D's CTFE can make D compilation infinitely slow. Let's put 
 anomalous cases aside...

 We say D compiles much faster than C++. Does anyone have any 
 measurement or a gut feeling about the same program written in 
 idiomatic C++ vs. idiomatic D? I think it may be 30 seconds vs. 
 5 seconds. I that a fair guess?

 Although a ballpark figure is good enough, precise measurements 
 would be useful as well.

 Thank you,
 Ali


Although this project is likely not representative of real world 
usage, I believe it contains the most reliable data, at least as 
far D is concerned (there certainly other projects, but I don't 
know if they include D in their comparisons):

https://github.com/nordlow/compiler-benchmark
Sep 20 2022
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 20 September 2022 at 16:13:30 UTC, Ali Çehreli wrote:

 D's CTFE can make D compilation infinitely slow. Let's put 
 anomalous cases aside...

 We say D compiles much faster than C++. Does anyone have any 
 measurement or a gut feeling about the same program written in 
 idiomatic C++ vs. idiomatic D? I think it may be 30 seconds vs. 
 5 seconds. I that a fair guess?

 Although a ballpark figure is good enough, precise measurements 
 would be useful as well.

 Thank you,
 Ali


This is something we should emphasize more when talking about D.

I have been in D for some years now, and I still don't understand 
why it never really seems to "catch on". It's ready now, I would 
consider using it in production.

I think before I was too focused on trying to find a c(pp) 
replacement for embedded, but I now think the world isn't ready 
yet to replace C, it might not happen in 30 years.

But other than that, D is superior in many ways. The language 
itself is ready, the ecosystem and IDE (maybe this is better now 
as well) are the only things holding it back. Or maybe just 
ecosystem then, which comes with a bigger community. People need 
to understand that D is a serious option. I get the impression in 
various contexts that for some reason, people think D is not 
ready for serious enterprise use. But I never got an explanation 
to why it wouldn't.

It's one of the 10 greatest mysteries of the world.
Sep 24 2022
parent reply IGotD- <nise nise.com> writes:
On Saturday, 24 September 2022 at 08:49:46 UTC, Imperatorn wrote:

 This is something we should emphasize more when talking about D.

 I have been in D for some years now, and I still don't 
 understand why it never really seems to "catch on". It's ready 
 now, I would consider using it in production.

 I think before I was too focused on trying to find a c(pp) 
 replacement for embedded, but I now think the world isn't ready 
 yet to replace C, it might not happen in 30 years.

 But other than that, D is superior in many ways. The language 
 itself is ready, the ecosystem and IDE (maybe this is better 
 now as well) are the only things holding it back. Or maybe just 
 ecosystem then, which comes with a bigger community. People 
 need to understand that D is a serious option. I get the 
 impression in various contexts that for some reason, people 
 think D is not ready for serious enterprise use. But I never 
 got an explanation to why it wouldn't.

 It's one of the 10 greatest mysteries of the world.


Because it is how the D project is managed. If I would have been 
a project manager, that alone would be enough to avoid the 
language. There is also significant resistance to evolve the 
language which is needed. D is a product of the 90s but the world 

evolved with time. This is really sad because D is really a nice 
language but a lost opportunity.

I will move on and I'm currently looking into if Swift can be a 
better choice and by the looks of it, it is. Swift is like a user 
friendly version of Rust. The big difference is that Swift is 
backed by Apple which sets up certain requirements for a 
language. They couldn't just take Rust because it wouldn't fit 
and would be too difficult coming from Objective-C. Instead they 
make a new language from the ground up to fit their developer 
base. Here we have real "customers" that have 
requirements/desires which D doesn't really have but more a 
hobbyist approach.

BTW. Swift has a binary literal which has been the from the 
beginning and nobody really cares/questions it (being pretty high 
level they are probably rarely used). The D maintainers want to 
remove binary literals which is a good indication how tone deaf 
the management is and thus the project runs they way it does.

It's not a mystery for me but pretty obvious why D isn't more 
popular.
Sep 24 2022
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 24 September 2022 at 10:47:24 UTC, IGotD- wrote:

 On Saturday, 24 September 2022 at 08:49:46 UTC, Imperatorn 
 wrote:

 [...]


 Because it is how the D project is managed. If I would have 
 been a project manager, that alone would be enough to avoid the 
 language. There is also significant resistance to evolve the 
 language which is needed. D is a product of the 90s but the 

 but has evolved with time. This is really sad because D is 
 really a nice language but a lost opportunity.

 [...]


Hmm, I see your point. But isn't Swift painfully slow to compile? 
🤔

**Disclaimer**: I'm basing that on information from 
third-parties, I haven't tried it myself.
Sep 24 2022
prev sibling next sibling parent reply Tejas <notrealemail gmail.com> writes:
On Saturday, 24 September 2022 at 10:47:24 UTC, IGotD- wrote:

 The big difference is that Swift is backed by Apple which sets 
 up certain requirements for a language.



What kind of requirements? They even have officially suppported 
Windows realeases now, no Apple-ism in sight, AFAICT
Sep 24 2022
parent IGotD- <nise nise.com> writes:
On Saturday, 24 September 2022 at 11:24:11 UTC, Tejas wrote:

 What kind of requirements? They even have officially suppported 
 Windows realeases now, no Apple-ism in sight, AFAICT


Maybe this is too much OT.

Swift was made open source a while ago and as a consequence of 
that is that people started to port it to other platforms. How 
much this is supported by Apple, I cannot say but probably not 
much. However, Apple probably don't mind as it makes the language 
more popular. When Apple develops Swift and its libraries in 
house they probably try to write it as portable as possible. The 

helps advance the popularity of the language.

When it comes to requirements, this is only my speculation. 
Language engineers are kind of peculiar people, at least about 
all I have met. It takes a high level of knowledge to develop 
languages and it turn this makes these persons to become stuck in 
their academic topics and forget that computer languages are made 
to be used by average SW developers. Apple hired a bunch of very 
skilled engineers, some from the Rust team which is obvious. In 
such organization there is a management to pull these engineers 
in ears to make the language user friendly and so that it appeals 
to the masses. You can clearly see it in Swift how they cleaned 
up the syntax compared to Rust and removed the explicit memory 
management. The question is how much that would have happened if 
they language engineers would have their own way.

In Apple there is a management to make "the customers are always 
right" versus "the language developer is always right". This is 
highly simplified of course.
Sep 24 2022
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 24 September 2022 at 10:47:24 UTC, IGotD- wrote:

 Because it is how the D project is managed. If I would have 
 been a project manager, that alone would be enough to avoid the 
 language. There is also significant resistance to evolve the 
 language which is needed.


There is a high bar for new features, which is as it should be. 
The fact that people sometimes don't put the work in to write and 
evolve a solid proposal is not the maintainers fault. And even 
well written proposals should be turned down sometimes if they 
don't have a good power to weight ratio.


 Here we have real "customers" that have requirements/desires 
 which D doesn't really have but more a hobbyist approach.


The last quarterly foundation meeting had 9 representatives from 
companies taking part:
https://forum.dlang.org/post/lxfildvecircypoabain forum.dlang.org

D is focused on professional users, rather than every syntax 
proposal that comes up on the forum.


 The D maintainers want to remove binary literals which is a 
 good indication how tone deaf the management is and thus the 
 project runs they way it does.


What's your evidence the maintainers (plural) want to remove it? 
Wasn't it just an idea of Walter's? I strongly doubt this will 
happen. D since roughly 2010 hasn't removed anything that wasn't 
bug-prone, hard to support or not working properly.
Sep 24 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 25/09/2022 5:10 AM, Nick Treleaven wrote:

 D since roughly 2010 hasn't removed anything that wasn't bug-prone, hard 
 to support or not working properly.


Hex strings...
Sep 24 2022
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 24 September 2022 at 16:22:26 UTC, rikki cattermole 
wrote:

 On 25/09/2022 5:10 AM, Nick Treleaven wrote:

 D since roughly 2010 hasn't removed anything that wasn't 
 bug-prone, hard to support or not working properly.


 Hex strings...


OK, and there may be other things. But did people complain as 
loudly when they were removed?
Sep 24 2022
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 25/09/2022 5:28 AM, Nick Treleaven wrote:

 OK, and there may be other things. But did people complain as loudly 
 when they were removed?


I regret not speaking up at the time, I'm not quite sure why I didn't.

Lets just say, I won't be making that same mistake again ;)
Sep 24 2022
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 20 September 2022 at 16:13:30 UTC, Ali Çehreli wrote:

 D's CTFE can make D compilation infinitely slow. Let's put 
 anomalous cases aside...

 We say D compiles much faster than C++. Does anyone have any 
 measurement or a gut feeling about the same program written in 
 idiomatic C++ vs. idiomatic D? I think it may be 30 seconds vs. 
 5 seconds. I that a fair guess?

 Although a ballpark figure is good enough, precise measurements 
 would be useful as well.

 Thank you,
 Ali


Side note:

Does anyone know how updated this is?

https://programming-language-benchmarks.vercel.app/d
Sep 24 2022
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/24/22 08:56, Imperatorn wrote:


 Does anyone know how updated this is?

 https://programming-language-benchmarks.vercel.app/d


The page says updated [2 days ago] and uses the most recent dmd.

However, the code can be improved. A random and quick look reveals use 
of 'class' and 'new' seemingly unnecessarily for D.

Ali
Sep 24 2022