On Sunday, 4 February 2018 at 01:57:26 UTC, Rubn wrote:
On Saturday, 3 February 2018 at 23:07:30 UTC, Norm wrote:
On Saturday, 3 February 2018 at 15:22:37 UTC, Rubn wrote:
On Saturday, 3 February 2018 at 08:18:57 UTC, H. S. Teoh wrote:
On Fri, Feb 02, 2018 at 08:16:25PM -0800, Walter Bright via Digitalmars-d wrote:
On 2/2/2018 7:06 AM, Benny wrote:
> Other languages have slogans, they have selling points.
> > When i hear Go, you hear uniformal, fast, simple syntax > language.
> When i hear Rust, you hear safe, manual memory management.
> When i hear D, you hear ... ... ... ...

                          Fast code, fast

Frankly, that slogan makes me cringe. Makes D sound like a fast food chain -- cheap code, fast. Would you like fa^Wfries with that?

Yup I agree, it's a horrible slogan. Speed isn't even a priority in D, if it was so many things would be different.

- Make dmd's optimizer better, esp. with loop unrolling on par with ldc/gdc, or better, so that we don't keep having to defend poor dmd
  benchmarks with "use ldc/gdc instead";

I don't think time should be wasted on making DMD's optimizer better. It's not an easy job and it'll just pull resources for something that has no purpose. The compile times with DMD -O can vary dramatically, it's best just to not use it at all. The reason I hear as to why DMD even exists instead of just having 1 compiler like Rust or any other language that isn't 20+ years old. Is cause DMD's unoptimized compilation is fast and creates reasonably fast enough code for debugging.

I agree, DMD should switch to LLVM backend. But it is unlikely to happen because the core DMD developers are in their comfort zone with DMD backend and worried that switching to LLVM would put them at the mercy of the LLVM community. To be honest though I don't know how much time DMD backend optimizer really takes core devs away from D language development. It would be interesting to see some numbers on this.

We use LDC exclusively where I work because DMD codegen just isn't production ready. And the argument that DMD debug builds are so much faster than LDC is bogus. Yes it is faster but nowhere near the point where we would consider swapping compilers between debug and release builds.

So that leaves little scripts and the like where DMD could maybe replace Python. But again, LDC isn't *that* slow in debug builds either and could do this just as well.


I agree it isn't that much faster, though that's the argument I hear. I would prefer to have one compiler that is being worked on than having split effort for 3 different compilers when larger communities only have 1 compiler. Not that everyone working on those compilers will work on one compiler if it does happen. It's just a shame the solution was to create more compilers.

All the major compilers, dmd, ldc, and gdc, share the same frontend. Two of the backends, llvm and gcc, are not worked on by the D compiler devs. The DM backend used by dmd is not worked on much, mostly bug fixes and some refactoring recently, as Walter prepares to move it to D:


There is no evidence that having more compiler backends available to D devs has "split effort" in any way.

As for the compilers' speed, I thought I'd test that out. I just built the dmd frontend a handful of times in a single-core linux/x64 VPS, both with the official dmd 2.078.0 and the latest ldc 1.7.0. Leaving out all the C++ files, dmd consistently took 3-4 seconds to build the D frontend alone and link the final dmd binary, whereas ldc took 9-10 seconds for the same work. This is with no debug or optimization options added, just the default build by the dmd makefile.

That's a 200% increase in compilation speed when iterating on the almost 80k lines of code (reported by DScanner) in the dmd frontend, certainly not insignificant. When the backend is in D too- the C++ files currently take about 10 seconds to compile- building dmd itself will be incredibly fast, even more than it is now.

With DMD it seems like they are entirely unwilling to let go from using DM tools/code. The backend is just one example. Optlink is another. DM Make is also another, etc...

Why let it go, when you don't have to use it? Optlink has around 5 commits in the last 3 years, it's not like it's taking up much time:


Rather than worrying about DM tools that receive almost no attention, D would be better off if more people chipped in on the code they _do_ care about, whether through submitting pull requests or posting bounties:


Reply via email to