www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is dmd fast?

reply qznc <qznc web.de> writes:
Walter and we as a community often claim that dmd is fast as in 
"compiles quickly". Go also claims this. Rust does not. They even 
state that compilation speed is one of the big tasks they are 
working on.

 From the general sentiment, I would expect that dmd performs on 
the level of Go and Rust being slower.

Now, D as a language supports arbitrary compile-time computation 
so dmd can be arbitrarily slow. We need to look at the benchmark 
carefully. I started with the canonical Hello World. Here are 
some numbers:

Dash         0:00:00.002366
Bash         0:00:00.002474
TCC          0:00:00.007044
Python2      0:00:00.009881
Python3      0:00:00.015547
GCC          0:00:00.028578
Go           0:00:00.149691
Rust         0:00:00.212053
RDMD         0:00:00.275884
Haskell      0:00:00.310539
DMD          0:00:00.311102
Java         0:00:00.596517
Scala        0:00:01.917606
X10 Java     0:00:02.484673
X10 C++      0:00:03.887826

Hm, Rust is faster than dmd? Go is roughly twice as fast as dmd?

Destroy!

But run your own numbers first: 
https://github.com/qznc/hello-benchmark ;)
Jun 22 2016
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 22 June 2016 at 13:46:50 UTC, qznc wrote:

 ...


Including scripting languages in that example is unfair as they 
only lex the file.

Right away you can tell that "Hello World" is a poor example of 
fast compile times because GCC is near the top; (as you probably 
know) large Cpp projects can have half hour to an hour long build 
times. Large projects are way faster to compile using dmd.

Using the code from even a small piece of code that does 
something real, all of a sudden the numbers get a lot closer. 
Here is the code I'm using: 
https://github.com/kostya/benchmarks/tree/master/brainfuck2

$ time rustc bf.rs
rustc bf.rs  0.29s user 0.05s system 99% cpu 0.350 total

$ time go build bf.go
go build bf.go  0.46s user 0.07s system 128% cpu 0.416 total

$ time dmd bf.d
dmd bf.d  0.32s user 0.09s system 73% cpu 0.556 total

$ time g++ bf.cpp
g++ bf.cpp  0.36s user 0.36s system 65% cpu 1.093 total
Jun 22 2016
next sibling parent reply qznc <qznc web.de> writes:
On Wednesday, 22 June 2016 at 14:11:12 UTC, Jack Stouffer wrote:

 On Wednesday, 22 June 2016 at 13:46:50 UTC, qznc wrote:

 ...


 Including scripting languages in that example is unfair as they 
 only lex the file.


Sure. Especially bash, which is always in RAM anyways. It shows 
the possible span, though.


 Right away you can tell that "Hello World" is a poor example of 
 fast compile times because GCC is near the top; (as you 
 probably know) large Cpp projects can have half hour to an hour 
 long build times. Large projects are way faster to compile 
 using dmd.


This is the C hello world. I added a C++ one and it is slightly 
faster than Go.

I completely agree that Hello World is poor. Brainfuck is a 
little better.


 Using the code from even a small piece of code that does 
 something real, all of a sudden the numbers get a lot closer. 
 Here is the code I'm using: 
 https://github.com/kostya/benchmarks/tree/master/brainfuck2

 $ time rustc bf.rs
 rustc bf.rs  0.29s user 0.05s system 99% cpu 0.350 total

 $ time go build bf.go
 go build bf.go  0.46s user 0.07s system 128% cpu 0.416 total

 $ time dmd bf.d
 dmd bf.d  0.32s user 0.09s system 73% cpu 0.556 total

 $ time g++ bf.cpp
 g++ bf.cpp  0.36s user 0.36s system 65% cpu 1.093 total


Rust faster than Go? That still seems weird.

I like your overall benchmark. Measuring build times there seems 
like a good idea.
Jun 22 2016
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 22 June 2016 at 14:28:28 UTC, qznc wrote:

 Rust faster than Go? That still seems weird.

 I like your overall benchmark. Measuring build times there 
 seems like a good idea.


I'm more surprised that Go is faster than D.
Jun 22 2016
prev sibling parent Icecream Bob <icecream icecream.com> writes:
On Wednesday, 22 June 2016 at 14:11:12 UTC, Jack Stouffer wrote:

 On Wednesday, 22 June 2016 at 13:46:50 UTC, qznc wrote:

 ...


 Including scripting languages in that example is unfair as they 
 only lex the file.

 Right away you can tell that "Hello World" is a poor example of 
 fast compile times because GCC is near the top; (as you 
 probably know) large Cpp projects can have half hour to an hour 
 long build times. Large projects are way faster to compile 
 using dmd.


 From a marketing standpoint, you want simple things to compile 
fast. Ain't nobody gonna create big applications in multiple 
languages to see which one compiles faster. They will most likely 
go a little bit further than hello world, if they know what they 
are doing. Testing things that shows lexing speed, linking speed, 
etc, but they aren't gonna do complicated stuff.
Jun 22 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 22 June 2016 at 13:46:50 UTC, qznc wrote:

 RDMD         0:00:00.275884
 DMD          0:00:00.311102



Since rdmd is just a script wrapper around dmd, it shouldn't 
actually be faster.

BTW this more measures linker speed than compiler. dmd -c -o- 
just runs the compiler and skips filesystem output... it'd be 
pretty fast and if there's similar options for other compilers 
(gcc has -c too at least) it might be better for small programs.

Larger programs I think is fair to include the link step, since 
it should be less a percentage there and you do need to run it 
anyway.
Jun 22 2016
next sibling parent qznc <qznc web.de> writes:
On Wednesday, 22 June 2016 at 14:28:19 UTC, Adam D. Ruppe wrote:

 On Wednesday, 22 June 2016 at 13:46:50 UTC, qznc wrote:

 RDMD         0:00:00.275884
 DMD          0:00:00.311102



 Since rdmd is just a script wrapper around dmd, it shouldn't 
 actually be faster.

 BTW this more measures linker speed than compiler. dmd -c -o- 
 just runs the compiler and skips filesystem output... it'd be 
 pretty fast and if there's similar options for other compilers 
 (gcc has -c too at least) it might be better for small programs.

 Larger programs I think is fair to include the link step, since 
 it should be less a percentage there and you do need to run it 
 anyway.


I agree that this is strange.

It is tricky compare compilation time with Python or Java. Python 
works as in interpreter (with bytecode compilation behind the 
scene). Java does most of the compiling in the JVM and javac is 
pretty stupid.

What I want to get at is actually the "iteration speed", not just 
the "compilation speed". How fast can edit-compile-test your 
program? It might actually be more truthful to use dub (and cargo 
and maven ...), since it is the idiomatic way.
Jun 22 2016
prev sibling next sibling parent Adrian Matoga <dlang.spam matoga.info> writes:
On Wednesday, 22 June 2016 at 14:28:19 UTC, Adam D. Ruppe wrote:

 BTW this more measures linker speed than compiler. dmd -c -o- 
 just runs the compiler and skips filesystem output... it'd be 
 pretty fast and if there's similar options for other compilers 
 (gcc has -c too at least) it might be better for small programs.

 Larger programs I think is fair to include the link step, since 
 it should be less a percentage there and you do need to run it 
 anyway.


Yeah, you do need to run it anyway, even if you build 
incrementally.
It'd be a lie to omit the link time when the compiler actively 
works to make linker's job harder by inflating the symbol table 
to tens or hundreds of megabytes.
Jun 22 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/22/2016 7:28 AM, Adam D. Ruppe wrote:

 On Wednesday, 22 June 2016 at 13:46:50 UTC, qznc wrote:

 RDMD         0:00:00.275884
 DMD          0:00:00.311102



 Since rdmd is just a script wrapper around dmd, it shouldn't actually be
faster.


rdmd caches "script" programs, so could be faster.



 BTW this more measures linker speed than compiler. dmd -c -o- just runs the
 compiler and skips filesystem output... it'd be pretty fast and if there's
 similar options for other compilers (gcc has -c too at least) it might be
better
 for small programs.

 Larger programs I think is fair to include the link step, since it should be
 less a percentage there and you do need to run it anyway.


Also, "hello world" is just a handful of lines of code. Measuring compile speed 
with this is measuring the time it takes to load dmd off of the disk, 
initialize, etc., rather than time spent compiling. It's a constant added to 
overall time.

"hello world" also imports object.d and std.stdio, both of which have a
tendency 
to accrete barnacles which slows down compilation by another constant.
Jun 22 2016
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 22 June 2016 at 13:46:50 UTC, qznc wrote:

 Destroy!


microbenchmarks sux. destruction sequence complete.
Jun 22 2016
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 22 June 2016 at 13:46:50 UTC, qznc wrote:

 Walter and we as a community often claim that dmd is fast as in 
 "compiles quickly". Go also claims this. Rust does not. They 
 even state that compilation speed is one of the big tasks they 
 are working on.

 From the general sentiment, I would expect that dmd performs on 
 the level of Go and Rust being slower.

 Now, D as a language supports arbitrary compile-time 
 computation so dmd can be arbitrarily slow. We need to look at 
 the benchmark carefully. I started with the canonical Hello 
 World. Here are some numbers:

 Dash         0:00:00.002366
 Bash         0:00:00.002474
 TCC          0:00:00.007044
 Python2      0:00:00.009881
 Python3      0:00:00.015547
 GCC          0:00:00.028578
 Go           0:00:00.149691
 Rust         0:00:00.212053
 RDMD         0:00:00.275884
 Haskell      0:00:00.310539
 DMD          0:00:00.311102
 Java         0:00:00.596517
 Scala        0:00:01.917606
 X10 Java     0:00:02.484673
 X10 C++      0:00:03.887826

 Hm, Rust is faster than dmd? Go is roughly twice as fast as dmd?

 Destroy!

 But run your own numbers first: 
 https://github.com/qznc/hello-benchmark ;)


You methodology is flawed. You are essentially measuring link 
time against the standard lib.
Jun 22 2016
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote:

 You methodology is flawed. You are essentially measuring link 
 time against the standard lib.


As someone else in the thread alluded to, people don't care about 
the nuance, and it's not particularly important. Linking is part 
of the compilation process that people have to wait for before 
their program can run. So if linking is slow, then compilation is 
slow.
Jun 22 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 22 June 2016 at 19:25:13 UTC, Jack Stouffer wrote:

 On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote:

 You methodology is flawed. You are essentially measuring link 
 time against the standard lib.


 As someone else in the thread alluded to, people don't care 
 about the nuance, and it's not particularly important. Linking 
 is part of the compilation process that people have to wait for 
 before their program can run. So if linking is slow, then 
 compilation is slow.


you can dramatically decrease linking times by switching from 
libphobos2.a to libphobos2.so.
Jun 22 2016
parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Or on linux use ld.gold instead of ld.bfd. Using .so instead of .a has 
another problem with speed. Application link against static phobos lib 
is much faster than against dynamic version.


Dne 22.6.2016 v 21:33 ketmar via Digitalmars-d napsal(a):

 On Wednesday, 22 June 2016 at 19:25:13 UTC, Jack Stouffer wrote:

 On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote:

 You methodology is flawed. You are essentially measuring link time 
 against the standard lib.


 As someone else in the thread alluded to, people don't care about the 
 nuance, and it's not particularly important. Linking is part of the 
 compilation process that people have to wait for before their program 
 can run. So if linking is slow, then compilation is slow.


 you can dramatically decrease linking times by switching from 
 libphobos2.a to libphobos2.so.
Jun 23 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 23 June 2016 at 13:32:35 UTC, Daniel Kozak wrote:

 Or on linux use ld.gold instead of ld.bfd. Using .so instead of 
 .a has another problem with speed. Application link against 
 static phobos lib is much faster than against dynamic version.


either i didn't understood you right, or... my tests shows that 
ld.gold is indeed faster than ld.bfd (as it should be), but 
linking against libphobos2.so is still faster in both linkers 
than linking against libphobos2.a. it is ~100 ms faster, for both 
linkers.

and if you meant that resulting application speed is different... 
tbh, i didn't noticed that at all. i did no benchmarks, but i 
have videogame engine, for example, and sound engine with pure D 
vorbis decoding, and some other apps, and never noticed any 
significant speed/CPU load difference between .a and .so versions.
Jun 23 2016
parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 23.6.2016 v 16:39 ketmar via Digitalmars-d napsal(a):


 On Thursday, 23 June 2016 at 13:32:35 UTC, Daniel Kozak wrote:

 Or on linux use ld.gold instead of ld.bfd. Using .so instead of .a 
 has another problem with speed. Application link against static 
 phobos lib is much faster than against dynamic version.


 either i didn't understood you right, or... my tests shows that 
 ld.gold is indeed faster than ld.bfd (as it should be), but linking 
 against libphobos2.so is still faster in both linkers than linking 
 against libphobos2.a. it is ~100 ms faster, for both linkers.

 and if you meant that resulting application speed is different... tbh, 
 i didn't noticed that at all. i did no benchmarks, but i have 
 videogame engine, for example, and sound engine with pure D vorbis 
 decoding, and some other apps, and never noticed any significant 
 speed/CPU load difference between .a and .so versions.


Yes I was speaking about application speed or runtime overhead. Mainly 
about one shot scripts something like this:

//a.d
import std.stdio: writeln;

void main() {
     writeln("Ahoj svete");
}

[kozzi samuel ~]$ dmd -defaultlib=libphobos2.so a.d
[kozzi samuel ~]$ time for t in {1..1000}; do ./a; done > /dev/null

real    0m7.187s
user    0m4.470s
sys    0m0.943s

[kozzi samuel ~]$ dmd -defaultlib=libphobos2.a a.d
[kozzi samuel ~]$ time for t in {1..1000}; do ./a; done > /dev/null

real    0m1.716s
user    0m0.047s
sys    0m0.323s
Jun 23 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 23 June 2016 at 17:39:45 UTC, Daniel Kozak wrote:

 [kozzi samuel ~]$ dmd -defaultlib=libphobos2.so a.d
 [kozzi samuel ~]$ time for t in {1..1000}; do ./a; done > 
 /dev/null

 real    0m7.187s
 user    0m4.470s
 sys    0m0.943s

 [kozzi samuel ~]$ dmd -defaultlib=libphobos2.a a.d
 [kozzi samuel ~]$ time for t in {1..1000}; do ./a; done > 
 /dev/null

 real    0m1.716s
 user    0m0.047s
 sys    0m0.323s


yep, you are right. on my tests .a took 0.695 total, but .so took 
4.908 total.

not really matters for one-shot scripts, but... i didn't knew 
that the difference is SO huge. thank you for pointing that.
Jun 23 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 22 June 2016 at 19:25:13 UTC, Jack Stouffer wrote:

 So if linking is slow, then compilation is slow.


But, 1/3 second isn't slow... I don't feel compilation is slow 
until it takes more like 5 seconds. Certainly, 1/3s is noticable 
(if you do a hello world with printf instead of writeln you can 
feel the difference btw), but it isn't important.

D compile speed typically *scales* better than the competition. 
Instead of chasing the 100ms in hello world, it tackles the 
10000ms of a real project.
Jun 22 2016
next sibling parent qznc <qznc web.de> writes:
On Wednesday, 22 June 2016 at 19:56:26 UTC, Adam D. Ruppe wrote:

 D compile speed typically *scales* better than the competition. 
 Instead of chasing the 100ms in hello world, it tackles the 
 10000ms of a real project.


Ok, but this is hard to test. It is not feasible to build the 
same real project in many languages.

Generating programs might work. They would not be very realistic, 
but it gives a sense of scaling.
Jun 22 2016
prev sibling parent reply Tofu Ninja <joeyemmons yahoo.com> writes:
On Wednesday, 22 June 2016 at 19:56:26 UTC, Adam D. Ruppe wrote:

 On Wednesday, 22 June 2016 at 19:25:13 UTC, Jack Stouffer wrote:

 So if linking is slow, then compilation is slow.


 But, 1/3 second isn't slow... I don't feel compilation is slow 
 until it takes more like 5 seconds. Certainly, 1/3s is 
 noticable (if you do a hello world with printf instead of 
 writeln you can feel the difference btw), but it isn't 
 important.

 D compile speed typically *scales* better than the competition. 
 Instead of chasing the 100ms in hello world, it tackles the 
 10000ms of a real project.


I have a >15000 LOC project that also depends on many dub 
packages and uses a fair amount of CTFE. Even doing a full 
rebuild, it still only takes roughly 10s. If I skip rebuilding 
the dub dependencies then the time is usually cut in half. Over 
all dmd seems pretty fast to me.
Jul 05 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 6 July 2016 at 05:38:25 UTC, Tofu Ninja wrote:

 dmd seems pretty fast to me.


add "-O -inline" and go to bed. ;-)
Jul 05 2016
next sibling parent reply thedeemon <dlang thedeemon.com> writes:
On Wednesday, 6 July 2016 at 05:46:20 UTC, ketmar wrote:

 On Wednesday, 6 July 2016 at 05:38:25 UTC, Tofu Ninja wrote:

 dmd seems pretty fast to me.


 add "-O -inline" and go to bed. ;-)


Nah, in my multi-KLOC project the difference between debug (-g) 
and release (-O -inline) is like 6 vs. 8 seconds.
Jul 05 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 6 July 2016 at 06:10:20 UTC, thedeemon wrote:

 On Wednesday, 6 July 2016 at 05:46:20 UTC, ketmar wrote:

 On Wednesday, 6 July 2016 at 05:38:25 UTC, Tofu Ninja wrote:

 dmd seems pretty fast to me.


 add "-O -inline" and go to bed. ;-)


 Nah, in my multi-KLOC project the difference between debug (-g) 
 and release (-O -inline) is like 6 vs. 8 seconds.


heh. and with my NanoVG port (nothing fancy, almost no templates 
and such), the difference between "-O" and "-O -inline" is 
something like: 2.5 seconds for "-O", 28 seconds for "-O 
-inline"...
Jul 05 2016
prev sibling parent reply Tofu Ninja <joeyemmons yahoo.com> writes:
On Wednesday, 6 July 2016 at 05:46:20 UTC, ketmar wrote:

 On Wednesday, 6 July 2016 at 05:38:25 UTC, Tofu Ninja wrote:

 dmd seems pretty fast to me.


 add "-O -inline" and go to bed. ;-)


Went up to about 18s for a full rebuild of the project and the 
dub dependencies, I am ok with these times :)
Jul 06 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 6 July 2016 at 08:13:01 UTC, Tofu Ninja wrote:

 On Wednesday, 6 July 2016 at 05:46:20 UTC, ketmar wrote:

 On Wednesday, 6 July 2016 at 05:38:25 UTC, Tofu Ninja wrote:

 dmd seems pretty fast to me.


 add "-O -inline" and go to bed. ;-)


 Went up to about 18s for a full rebuild of the project and the 
 dub dependencies, I am ok with these times :)


so you can't just start project rebuilding when you want some 
free hours... DMD should add some slow build mode!
Jul 06 2016
parent Tofu Ninja <joeyemmons yahoo.com> writes:
On Wednesday, 6 July 2016 at 19:12:23 UTC, ketmar wrote:

 On Wednesday, 6 July 2016 at 08:13:01 UTC, Tofu Ninja wrote:

 On Wednesday, 6 July 2016 at 05:46:20 UTC, ketmar wrote:

 On Wednesday, 6 July 2016 at 05:38:25 UTC, Tofu Ninja wrote:

 dmd seems pretty fast to me.


 add "-O -inline" and go to bed. ;-)


 Went up to about 18s for a full rebuild of the project and the 
 dub dependencies, I am ok with these times :)


 so you can't just start project rebuilding when you want some 
 free hours... DMD should add some slow build mode!


You could probably add something in CTFE to slow things down.
Jul 06 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Wednesday, 22 June 2016 at 19:25:13 UTC, Jack Stouffer wrote:

 On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote:

 You methodology is flawed. You are essentially measuring link 
 time against the standard lib.


 As someone else in the thread alluded to, people don't care 
 about the nuance, and it's not particularly important. Linking 
 is part of the compilation process that people have to wait for 
 before their program can run. So if linking is slow, then 
 compilation is slow.


If you are to include link time in the measurement, you need to 
make sure that link time are representative of typical link time 
in real life applications. This require an application 
sufficiently large (and then you run into problem as to assert 
how similar applications are).

In this case, one is essentially measuring the size of the 
standardlib rather than the speed of the compiler. There are much 
better way to measure the size of the standard lib than measuring 
how long the linker take to go through it.
Jun 22 2016
prev sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote:

 You methodology is flawed. You are essentially measuring link 
 time against the standard lib.


If you're sitting on Linux make sure that you're using the GNU 
gold linker (`ld.gold`) by default (`ld`).

On Ubuntu/Debian you should use

     sudo update-alternatives --config ld

to configure this.

The GNU gold linker should be the default on newer distributions.
Jun 23 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/23/2016 03:14 AM, Nordlöw wrote:

 On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote:

 You methodology is flawed. You are essentially measuring link time
 against the standard lib.


 If you're sitting on Linux make sure that you're using the GNU gold
 linker (`ld.gold`) by default (`ld`).

 On Ubuntu/Debian you should use

      sudo update-alternatives --config ld

 to configure this.

 The GNU gold linker should be the default on newer distributions.


Is there a way to tell? Thanks! -- Andrei
Jun 23 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 23 June 2016 at 14:28:08 UTC, Andrei Alexandrescu 
wrote:

 The GNU gold linker should be the default on newer 
 distributions.


 Is there a way to tell? Thanks! -- Andrei


it's not something dmd should enforce: it is the system setting 
under user control. there may be many various reasons to choose 
one or another linker, and in terms of interoperability it's 
better to stick with what system provides.

as of the linker itsef, on most systems /usr/bin/ld is just a 
symling to either ld.bfd or ld.gold. we can include some notion 
in DMD documentation regarding to that.
Jun 23 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/23/2016 10:36 AM, ketmar wrote:

 as of the linker itsef, on most systems /usr/bin/ld is just a symling to
 either ld.bfd or ld.gold. we can include some notion in DMD
 documentation regarding to that.


On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does that mean? 
-- Andrei
Jun 23 2016
next sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Thursday, 23 June 2016 at 17:24:34 UTC, Andrei Alexandrescu 
wrote:

 On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does 
 that mean? -- Andrei


`ld --version` should clear that up. ;)

  — David
Jun 23 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/23/2016 01:33 PM, David Nadlinger wrote:

 On Thursday, 23 June 2016 at 17:24:34 UTC, Andrei Alexandrescu wrote:

 On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does that mean?
 -- Andrei


 `ld --version` should clear that up. ;)


GNU ld (GNU Binutils for Ubuntu) 2.26

So how do I get and install gold?


Thanks,

Andrei
Jun 23 2016
parent Brad Anderson <eco gnuk.net> writes:
On Thursday, 23 June 2016 at 17:57:33 UTC, Andrei Alexandrescu 
wrote:

 On 06/23/2016 01:33 PM, David Nadlinger wrote:

 On Thursday, 23 June 2016 at 17:24:34 UTC, Andrei Alexandrescu 
 wrote:

 On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does 
 that mean?
 -- Andrei


 `ld --version` should clear that up. ;)


 GNU ld (GNU Binutils for Ubuntu) 2.26

 So how do I get and install gold?


 Thanks,

 Andrei


Martin covered it here: 
https://code.dawg.eu/reducing-vibed-turnaround-time-part-1-faster-linking.html
Jun 23 2016
prev sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 23.6.2016 v 19:24 Andrei Alexandrescu via Digitalmars-d napsal(a):


 On 06/23/2016 10:36 AM, ketmar wrote:

 as of the linker itsef, on most systems /usr/bin/ld is just a symling to
 either ld.bfd or ld.gold. we can include some notion in DMD
 documentation regarding to that.


 On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does that mean? 
 -- Andrei


[kozzi samuel ~]$ ld -v
GNU ld (GNU Binutils) 2.26.0.20160501
[kozzi samuel ~]$ ld.gold -v
GNU gold (GNU Binutils 2.26.0.20160501) 1.11
Jun 23 2016
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
On Thursday, 23 June 2016 at 14:28:08 UTC, Andrei Alexandrescu 
wrote:

 On 06/23/2016 03:14 AM, Nordlöw wrote:

 On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote:

 You methodology is flawed. You are essentially measuring link 
 time
 against the standard lib.


 If you're sitting on Linux make sure that you're using the GNU 
 gold
 linker (`ld.gold`) by default (`ld`).

 On Ubuntu/Debian you should use

      sudo update-alternatives --config ld

 to configure this.

 The GNU gold linker should be the default on newer 
 distributions.


 Is there a way to tell? Thanks! -- Andrei


ld --version
Jun 23 2016
prev sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Thursday, 23 June 2016 at 14:28:08 UTC, Andrei Alexandrescu 
wrote:

 Is there a way to tell? Thanks! -- Andrei


ld --version

I presume.
Jun 23 2016
prev sibling next sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Thursday, 23 June 2016 at 07:14:02 UTC, Nordlöw wrote:

 The GNU gold linker should be the default on newer 
 distributions.


It seems the non-gold version is the default, on my Ubuntu 16.04.

It would be nice to automate the step of choosing the fast 
gold-version, so I don't have to bother with this anymore.

What about adding a flag to DMD that overrides the default name 
for the linker from `ld` to `ld.gold`?
Jun 24 2016
next sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 24 June 2016 at 09:09:49 UTC, Nordlöw wrote:

 What about adding a flag to DMD that overrides the default name 
 for the linker from `ld` to `ld.gold`?


Something like

     dmd -linker=ld.gold ...
Jun 24 2016
prev sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 24 June 2016 at 09:09:49 UTC, Nordlöw wrote:

 What about adding a flag to DMD that overrides the default name 
 for the linker from `ld` to `ld.gold`?


Ping!
Aug 08 2016
prev sibling next sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Thursday, 23 June 2016 at 07:14:02 UTC, Nordlöw wrote:

 On Ubuntu/Debian you should use

     sudo update-alternatives --config ld

 to configure this.


Hmm, my prompt answers:

     update-alternatives: error: no alternatives for ld

Doesn't this work anymore?
Jun 24 2016
prev sibling parent Kagamin <spam here.lot> writes:
BTW, anybody tested LLD? They claim it's faster than gold 
http://lld.llvm.org/NewLLD.html
Aug 05 2016
prev sibling parent qznc <qznc web.de> writes:
On Wednesday, 22 June 2016 at 13:46:50 UTC, qznc wrote:

 Walter and we as a community often claim that dmd is fast as in 
 "compiles quickly". Go also claims this. Rust does not. They 
 even state that compilation speed is one of the big tasks they 
 are working on.


I found a comparison for D and Rust, which uses a bigger program: 
Compile the respective package manager dub/cargo. They are (very 
roughly) programs of the same complexity.

Short: DMD 21sec vs Rust 56sec

Longer:
➤ time dub build --force
Performing "debug" build using dmd for x86_64.
dub 1.0.0+commit.8.gcdfaf60: building configuration 
"application"...
source/dub/internal/sdlang/lexer.d(16,8): Deprecation: module 
std.stream is deprecated - It will be removed from Phobos in 
October 2016. If you still need it, go to 
https://github.com/DigitalMars/undeaD
Linking...
6.76user 0.96system 0:21.83elapsed 35%CPU (0avgtext+0avgdata 
1106000maxresident)k
141800inputs+84280outputs (225major+325767minor)pagefaults 0swaps
➤ time cargo build
    Compiling cargo v0.12.0 (file:///home/qznc/dev/rust/cargo)
54.02user 1.56system 0:56.00elapsed 99%CPU (0avgtext+0avgdata 
629400maxresident)k
1144inputs+297400outputs (6major+459076minor)pagefaults 0swaps

Even more drastic is the user time: DMD 7sec vs Rust 54sec. I'm 
not sure where DMD spends the rest of the time? Page faults?
Jul 05 2016