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

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.

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.

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

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!

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

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.

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)

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.

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 has moved on from there. C# is also a product of the 90s but has 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.