This one of the main strengths of D, it is what Walter focuses on, yet I have seen almost nothing on the D blog talking about this.  What brought me to emphasize this today is this recent post about how long it takes to compile the mostly-C++ Chromium web browser and the reddit discussion about it:

https://lobste.rs/s/iri1te/chromium_has_compilation_time_problem
https://www.reddit.com/r/programming/comments/7ktzog/chromium_has_a_compilation_time_problem/

I'm tempted to call BS on that 6-7 hour build time, as I used to contribute to the Chromium project, and I think it used to take me 20 minutes for a release build in a FreeBSD jail on a fairly weak, 2008-vintage mini-desktop, a dual-core Celeron with 2 GBs of RAM (don't hold me to that build time, just a vague recollection, but probably in the ballpark).  Of course, the last time I built Chromium was more than 5 years ago, and a lot has likely changed since then, such as now using LTO to speed up the browser apparently, and maybe the cross-compilation toolchain for ARM is slower, though others note similar times for native x64 compilation also.

That still implies a slowdown of 2-3 orders of magnitude over the last 5 years, given the much more powerful hardware he's using, which is nuts.

D really needs the community to write blog posts talking about how fast it is, publicizing that there is an alternative to these glacial build times: who wants to do this?  It doesn't need to be on the D blog, could just be on your personal blog, but it is a message that really needs to be spread.

On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:
> This one of the main strengths of D, it is what Walter focuses on, yet I have seen almost nothing on the D blog talking about this.  What brought me to emphasize this today is this recent post about how long it takes to compile the mostly-C++ Chromium web browser and the reddit discussion about it:
>
> https://lobste.rs/s/iri1te/chromium_has_compilation_time_problem
> https://www.reddit.com/r/programming/comments/7ktzog/chromium_has_a_compilation_time_problem/
>
> I'm tempted to call BS on that 6-7 hour build time, as I used to contribute to the Chromium project, and I think it used to take me 20 minutes for a release build in a FreeBSD jail on a fairly weak, 2008-vintage mini-desktop, a dual-core Celeron with 2 GBs of RAM (don't hold me to that build time, just a vague recollection, but probably in the ballpark).  Of course, the last time I built Chromium was more than 5 years ago, and a lot has likely changed since then, such as now using LTO to speed up the browser apparently, and maybe the cross-compilation toolchain for ARM is slower, though others note similar times for native x64 compilation also.
>
> That still implies a slowdown of 2-3 orders of magnitude over the last 5 years, given the much more powerful hardware he's using, which is nuts.
>
> D really needs the community to write blog posts talking about how fast it is, publicizing that there is an alternative to these glacial build times: who wants to do this?  It doesn't need to be on the D blog, could just be on your personal blog, but it is a message that really needs to be spread.

If this ever happens, what will be published will have to be based on LDC2.
If benchmarks based on DMD are published, the article will be subject to the criticism that is that the shorter build time is due to the optimization pass, since it's known not to be super deep in DMD backend.

On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:
> This one of the main strengths of D, it is what Walter focuses on, yet I have seen almost nothing on the D blog talking about this.  What brought me to emphasize this today is this recent post about how long it takes to compile the mostly-C++ Chromium web browser and the reddit discussion about it:
>
> https://lobste.rs/s/iri1te/chromium_has_compilation_time_problem
> https://www.reddit.com/r/programming/comments/7ktzog/chromium_has_a_compilation_time_problem/
>
> I'm tempted to call BS on that 6-7 hour build time, as I used to contribute to the Chromium project, and I think it used to take me 20 minutes for a release build in a FreeBSD jail on a fairly weak, 2008-vintage mini-desktop, a dual-core Celeron with 2 GBs of RAM (don't hold me to that build time, just a vague recollection, but probably in the ballpark).  Of course, the last time I built Chromium was more than 5 years ago, and a lot has likely changed since then, such as now using LTO to speed up the browser apparently, and maybe the cross-compilation toolchain for ARM is slower, though others note similar times for native x64 compilation also.
>
> That still implies a slowdown of 2-3 orders of magnitude over the last 5 years, given the much more powerful hardware he's using, which is nuts.
>
> D really needs the community to write blog posts talking about how fast it is, publicizing that there is an alternative to these glacial build times: who wants to do this?  It doesn't need to be on the D blog, could just be on your personal blog, but it is a message that really needs to be spread.

D does not do itself any favors when it keeps accepting mediocre results in benchmarks.

https://www.techempower.com/benchmarks/previews/round15/

Some years it does not complete the tests, in others it shows results that are below mediocre.

Vibe.d ( and other D web frameworks ) benching twice slower then scripting languages like PHP/Ruby. That does not advertise D.

How about:

http://benchmarksgame.alioth.debian.org/

No D there? Performance must be bad because its not listed at all ( for a language that exist 20 years )?

Another one:

https://github.com/costajob/app-servers

Single threaded ( look at CPU total ), losing to other languages again.

Impressions are everything when there is a wealth of languages to pick from. Anybody stumbling over these results think: Well, i am better going with Go, Rust, Crystal, ... for a web hosting as they show more consistent high speed results.

On Friday, 22 December 2017 at 11:46:49 UTC, Chris wrote:
> http://benchmarksgame.alioth.debian.org/
>
> No D there? Performance must be bad because its not listed at all ( for a language that exist 20 years )?

D is not there for the only reason of that benchmark maintainer unwilling to include D. Technically you can take any C solution there, translate it to D (mostly by renaming from .c to .d) and with LDC get the same speed as C shows.

On Friday, 22 December 2017 at 11:39:48 UTC, user1234 wrote:

> If benchmarks based on DMD are published, the article will be subject to the criticism that is that the shorter build time is due to the optimization pass, since it's known not to be super deep in DMD backend.

Well, Go folks don't shy away from praising their compilation speed, but the situation is very similar there: Go compiles fast because it doesn't optimize the code. Last time I checked their compiler had zero options mentioning optimization, it's like "always debug build".

On Fri, 2017-12-22 at 14:48 +0000, thedeemon via Digitalmars-d wrote:
> […]
> 
> D is not there for the only reason of that benchmark maintainer unwilling to include D. Technically you can take any C solution there, translate it to D (mostly by renaming from .c to .d) and with LDC get the same speed as C shows.

For performance related stuff Go people use gccgo, just as D people use
gdc (or more usually ldc).

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Friday, 22 December 2017 at 11:39:48 UTC, user1234 wrote:
> If this ever happens, what will be published will have to be based on LDC2.
> If benchmarks based on DMD are published, the article will be subject to the criticism that is that the shorter build time is due to the optimization pass, since it's known not to be super deep in DMD backend.

Sure, ldc is slower but not significantly so, and will still beat the pants off clang, Rust, or Swift.

On Friday, 22 December 2017 at 11:46:49 UTC, Chris wrote:
> D does not do itself any favors when it keeps accepting mediocre results in benchmarks.

These are all runtime codegen benchmarks, whereas I was talking about build speed.

> https://www.techempower.com/benchmarks/previews/round15/
>
> Some years it does not complete the tests, in others it shows results that are below mediocre.
>
> Vibe.d ( and other D web frameworks ) benching twice slower then scripting languages like PHP/Ruby. That does not advertise D.

Sonke and others have noted that there are issues that need to be worked out with that benchmark submission.

> How about:
>
> http://benchmarksgame.alioth.debian.org/
>
> No D there? Performance must be bad because its not listed at all ( for a language that exist 20 years )?

It was on there for many years but was tossed out by a subsequent maintainer, who doesn't want it for some reason, as thedeemon pointed out:

http://forum.dlang.org/post/lspybogtpqorauausmmv@forum.dlang.org

> Another one:
>
> https://github.com/costajob/app-servers
>
> Single threaded ( look at CPU total ), losing to other languages again.

I think vibe.d is meant to be run in multiple process instances instead, and it does second-best to Rust on a single core (maybe beat out by Crystal too?), which is pretty good.

> Impressions are everything when there is a wealth of languages to pick from. Anybody stumbling over these results think: Well, i am better going with Go, Rust, Crystal, ... for a web hosting as they show more consistent high speed results.

I wouldn't say they're "everything," but they intrigue people enough to dig deeper into the language or just to move on without bothering.  Of course, you may get great benchmarks with Rust but once you try coding with it, you still may not like using it.

On Friday, 22 December 2017 at 14:48:22 UTC, thedeemon wrote:
> On Friday, 22 December 2017 at 11:46:49 UTC, Chris wrote:
>> http://benchmarksgame.alioth.debian.org/
>>
>> No D there? Performance must be bad because its not listed at all ( for a language that exist 20 years )?
>
> D is not there for the only reason of that benchmark maintainer unwilling to include D. Technically you can take any C solution there, translate it to D (mostly by renaming from .c to .d) and with LDC get the same speed as C shows.

Better than C actually, if you use D libraries instead:

http://forum.dlang.org/post/olelrjiaiwdxhjhilagv@forum.dlang.org

Getting back to the original topic of build speed, highlighting that the dmd compiler itself now builds in seconds after the C++->D translation would seem to be a layup:

http://forum.dlang.org/thread/oknuas$2lfp$1@digitalmars.com

On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:
> This one of the main strengths of D, it is what Walter focuses on, yet I have seen almost nothing on the D blog talking about this.  What brought me to emphasize this today is this recent post about how long it takes to compile the mostly-C++ Chromium web browser and the reddit discussion about it:
>
> [...]

Memory consumption is a deal breaker.

On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:
> This one of the main strengths of D, it is what Walter focuses on, yet I have seen almost nothing on the D blog talking about this.  What brought me to emphasize this today is this recent post about how long it takes to compile the mostly-C++ Chromium web browser and the reddit discussion about it:
>
> https://lobste.rs/s/iri1te/chromium_has_compilation_time_problem
> https://www.reddit.com/r/programming/comments/7ktzog/chromium_has_a_compilation_time_problem/
>
> I'm tempted to call BS on that 6-7 hour build time, as I used to contribute to the Chromium project, and I think it used to take me 20 minutes for a release build in a FreeBSD jail on a fairly weak, 2008-vintage mini-desktop, a dual-core Celeron with 2 GBs of RAM (don't hold me to that build time, just a vague recollection, but probably in the ballpark).  Of course, the last time I built Chromium was more than 5 years ago, and a lot has likely changed since then, such as now using LTO to speed up the browser apparently, and maybe the cross-compilation toolchain for ARM is slower, though others note similar times for native x64 compilation also.
>
> That still implies a slowdown of 2-3 orders of magnitude over the last 5 years, given the much more powerful hardware he's using, which is nuts.
>
> D really needs the community to write blog posts talking about how fast it is, publicizing that there is an alternative to these glacial build times: who wants to do this?  It doesn't need to be on the D blog, could just be on your personal blog, but it is a message that really needs to be spread.

I thought D did market itself that way.

However, my experience has been that D has fast builds from scratch, but is really really slow for incremental builds. Here's the thing: personally I don't care about anything except incremental builds. It's great that Phobos compiles in seconds when I do a git fetch after months. Win! Oh wait, I'm working on a bug, changed one character and it still takes the same amount of time...

Given that I write D code every day now, this incremental compilation situation is driving me nuts, and I'm definitely going to do something about it.

It's getting so bad that the day at work I had to write C++ I was happy. Because the edit-compile-link-test cycle was _faster_. Think about that for a bit - I enjoyed writing C++ (!!! either it or Scala are the slowest languages to compile ever) because I got faster feedback. Epic fail.

It's also possible I use templates and CTFE more that the regular D programmer. But... they're some of the main reasons I use D in the first place! I don't want to write Java in D syntax.

Atila

Atila

On Sunday, 24 December 2017 at 22:55:12 UTC, aberba wrote:
> On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:
>> This one of the main strengths of D, it is what Walter focuses on, yet I have seen almost nothing on the D blog talking about this.  What brought me to emphasize this today is this recent post about how long it takes to compile the mostly-C++ Chromium web browser and the reddit discussion about it:
>>
>> [...]
>
> Memory consumption is a deal breaker.

The dmd frontend prioritized speed over memory, which can cause problems with large or CTFE-heavy projects on low-memory systems:

http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941

On Wednesday, 27 December 2017 at 21:23:15 UTC, Atila Neves wrote:
> I thought D did market itself that way.

It has historically been a selling point, but perhaps it has been taken for granted.  I'm saying it needs a marketing push now.

I just went and checked the front page of the website, and I see a new marketing slogan that was added a couple weeks ago, "write fast, read fast, and run fast.  Fast code, fast:"

https://github.com/dlang/dlang.org/pull/1965

However, "build fast" is not included in that list.  You could argue it's implied by "write fast" or the last "code, fast," but it's not mentioned in the list under "write fast" below.  So even the front page doesn't highlight build speed, one of the core advantages of D.

> However, my experience has been that D has fast builds from scratch, but is really really slow for incremental builds. Here's the thing: personally I don't care about anything except incremental builds. It's great that Phobos compiles in seconds when I do a git fetch after months. Win! Oh wait, I'm working on a bug, changed one character and it still takes the same amount of time...
>
> Given that I write D code every day now, this incremental compilation situation is driving me nuts, and I'm definitely going to do something about it.
>
> It's getting so bad that the day at work I had to write C++ I was happy. Because the edit-compile-link-test cycle was _faster_. Think about that for a bit - I enjoyed writing C++ (!!! either it or Scala are the slowest languages to compile ever) because I got faster feedback. Epic fail.
>
> It's also possible I use templates and CTFE more that the regular D programmer. But... they're some of the main reasons I use D in the first place! I don't want to write Java in D syntax.

What do you plan to do about it?