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.
Cheers,
Norm
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:
https://github.com/dlang/dmd/commits/0b8d1fc0d5f6d09478d282202ad50a0c964b75b0?after=0b8d1fc0d5f6d09478d282202ad50a0c964b75b0+104&path%5B%5D=src&path%5B%5D=ddmd&path%5B%5D=backend
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:
https://github.com/DigitalMars/optlink/commits/master
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:
https://github.com/dlang/dmd/pulls
https://github.com/dlang/phobos/pulls
https://www.bountysource.com/teams/d
