www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Zig's Andrew Kelley: "The compiler is too dam slow, that's why we have

reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
I'm glad Andrew too has realized in what order to fix things - we 
all should consider performance-problems bugs.

See:

https://youtu.be/5eL_LcxwwHg?t=565
Jan 29
next sibling parent reply Don Allen <donaldcallen gmail.com> writes:
On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

 I'm glad Andrew too has realized in what order to fix things - 
 we all should consider performance-problems bugs.

 See:

 https://youtu.be/5eL_LcxwwHg?t=565


He thinks they have bugs because the compiler is too slow? That 
is truly remarkable.

Does Rust accumulate open bugs at the rate we have been seeing 
for years in the Zig project? The Rust compiler is far slower 
than the Zig compiler. I've used them both. Haskell? GHC is 
pretty slow, too.

I'm surprised by this, because Andrew usually seems like a smart, 
sensible guy. Had he said "We've got lot of bugs. Speeding up the 
compiler would help to increase the rate at which we can fix 
them" I wouldn't have reacted this way. Perhaps that's what he 
meant. But that's not what he said.

And I can tell you from personal experience that the open bugs 
are a big issue with Zig. Every time I've checked in with Zig 
(it's been three or four years) and tried to use it, I run into a 
serious problem with the compiler. Zig is not good enough yet for 
production work, nor do they claim to be, simply based on the 
version number with the leading zero. But Andrew's marketing 
flair seems to have attracted a lot of followers. At least in the 
compiler area, D seems to be the opposite. No marketing flair, 
but DMD in my experience is rock solid (and FAST). Even the 
much-maligned Phobos has worked well for me. D's documentation, 
though far from perfect, is far better than zig's, which I think 
is absolutely awful. I'm not so enthusiastic about dfmt and dub.
Jan 29
next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

 He thinks they have bugs because the compiler is too slow? That 
 is truly remarkable.


Ok, thanks for the overview. I agree with what you're saying. I 
wonder why Zig has so many open bugs. Could it be the complexity 
of the incremental compilation and hot-code-reloading?
Jan 29
prev sibling next sibling parent max haughton <maxhaton gmail.com> writes:
On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

 On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

 I'm glad Andrew too has realized in what order to fix things - 
 we all should consider performance-problems bugs.

 See:

 https://youtu.be/5eL_LcxwwHg?t=565


 He thinks they have bugs because the compiler is too slow? That 
 is truly remarkable.


In a causal sense they're unrelated, but if a program takes far 
longer than it "should"
for the amount of work it's doing, then I would expect bugs.

Speed comes from creative people understanding a domain really 
well. Slowness usually comes from code that solves a problem in a 
weird/roundabout way (usually because its the first attempt).

In compilers in particular after a certain amount of time working 
on a codebase it's somewhat easy to see a bunch of places where 
you could make things faster/correct-er and so on, but these are 
often serious engineering projects to even try unless the 
compiler is particularly well put together i.e. other than the 
speedups that come from chesterton's fences (i.e. "the C standard 
says...").

It doesn't seem alien to me that codebases that can be made fast 
(which these days basically means getting to the heart of a 
problem in a self-contained atom of work that you can cache 
properly) are less buggy in some limit.
Jan 29
prev sibling next sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

 On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

 [...]


 He thinks they have bugs because the compiler is too slow? That 
 is truly remarkable.

 [...]


You should have stayed more than 5 seconds on the video. He 
literally said that "Because it takes too much time to fix them. 
If we could reduce that slice of compiling time to almost 
inexistent, we could spend more time fixing the bugs".
Jan 29
parent reply Don Allen <donaldcallen gmail.com> writes:
On Monday, 29 January 2024 at 23:14:50 UTC, Hipreme wrote:

 On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

 On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

 [...]


 He thinks they have bugs because the compiler is too slow? 
 That is truly remarkable.

 [...]


 You should have stayed more than 5 seconds on the video.


And you should mind your manners.

  He

 literally said that "Because it takes too much time to fix 
 them. If we could reduce that slice of compiling time to almost 
 inexistent, we could spend more time fixing the bugs".


"The compiler is too damned slow. That's why. **That's why we 
have bugs.** It takes too long to fix them". QED
Jan 29
parent Bruce Carneal <bcarneal gmail.com> writes:
On Tuesday, 30 January 2024 at 01:37:29 UTC, Don Allen wrote:

 On Monday, 29 January 2024 at 23:14:50 UTC, Hipreme wrote:

 On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

 On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

 [...]


 He thinks they have bugs because the compiler is too slow? 
 That is truly remarkable.

 [...]


 You should have stayed more than 5 seconds on the video.


 And you should mind your manners.

  He

 literally said that "Because it takes too much time to fix 
 them. If we could reduce that slice of compiling time to 
 almost inexistent, we could spend more time fixing the bugs".


 "The compiler is too damned slow. That's why. **That's why we 
 have bugs.** It takes too long to fix them". QED


I happened to read it as Hipreme but the original's phrasing is, 
IMO, less than stellar.  Shaky enough that I'd not make strong 
claims either way.
Jan 29
prev sibling next sibling parent user1234 <user1234 12.de> writes:
On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

 On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

 I'm glad Andrew too has realized in what order to fix things - 
 we all should consider performance-problems bugs.

 See:

 https://youtu.be/5eL_LcxwwHg?t=565


 He thinks they have bugs because the compiler is too slow? That 
 is truly remarkable.

 Does Rust accumulate open bugs at the rate we have been seeing 
 for years in the Zig project? The Rust compiler is far slower 
 than the Zig compiler. I've used them both. Haskell? GHC is 
 pretty slow, too.

 I'm surprised by this, because Andrew usually seems like a 
 smart, sensible guy. Had he said "We've got lot of bugs. 
 Speeding up the compiler would help to increase the rate at 
 which we can fix them" I wouldn't have reacted this way. 
 Perhaps that's what he meant. But that's not what he said.

 And I can tell you from personal experience that the open bugs 
 are a big issue with Zig. Every time I've checked in with Zig 
 (it's been three or four years) and tried to use it, I run into 
 a serious problem with the compiler. Zig is not good enough yet 
 for production work
 [...]


How many times this would have to be repeated: A software with no 
bugs is a software that is not used or tested. It's pretty common 
to see a huge amount of bugs opened in the bug tracker of a 
programming language (sure when it's a mono-repo, that can be 
dramatically big).

- LLVM, clang: 20,530 k
- SWIFT: 6,279 k
- etc.

Just to say the count of bug is not the metric you think it is. 
Amount of bugs can also say "very popular product". People use it 
and find problems.

I tend to think that the ratio opened/closed is a better metric, 
assuming tickets have something to say: do they go into the wall 
? do they manage the problems ? Are they falling into a black 
hole ? etc.
Jan 29
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:


 Every time I've checked in with Zig (it's been three or four 
 years) and tried to use it, I run into a serious problem with 
 the compiler. Zig is not good enough yet for production work, 
 nor do they claim to be, simply based on the version number 
 with the leading zero.


Yeah, I tried it a while back, but it didn't last long. It seemed 
like a nice community and the language sounds like it has good 
ideas. I felt as if they hid the "not ready for any serious use". 
This is in contrast to D, which around the time I started using 
it, any story would have false comments about compiler bugs. I've 
hit more bugs in gcc than in dmd in that time.

While a faster compiler might help, my impression was that they 
made a strategic error by trying to do too much, and that meant 
there was no small core of features you could count on to be 
reliable. It's been quite a while, so that may not be true in 
2024.
Jan 29
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2024 12:51 PM, Don Allen wrote:

 But Andrew's marketing flair seems to 
 have attracted a lot of followers. At least in the compiler area, D seems to
be 
 the opposite. No marketing flair, but DMD in my experience is rock solid (and 
 FAST). Even the much-maligned Phobos has worked well for me. D's
documentation, 
 though far from perfect, is far better than zig's, which I think is absolutely 
 awful.


Andrew is definitely charismatic and likeable, I've met him. D has an advantage 
in that I've written multiple compilers before D. Contrast how very different 
the Digital Mars C compiler's internals are from D.
Jan 29
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
D has the advantage of simple persistence. With enough persistence, you can
chop 
down an oak tree with a cauliflower.
Jan 29
next sibling parent Don Allen <donaldcallen gmail.com> writes:
On Tuesday, 30 January 2024 at 00:41:02 UTC, Walter Bright wrote:

 D has the advantage of simple persistence. With enough 
 persistence, you can chop down an oak tree with a cauliflower.


I would prefer not to cut down an oak tree with anything.

So while I don't like your metaphor, I do think you have a point. 
I have had the impression that the Zig guys are a bit making it 
up as they go along. I wonder how many, Andrew included, have 
written compilers before this one. I don't know the answer. But 
if this is their first, it's likely part of the explanation for 
the problems.

I'm quite sure that your long experience in compiler writing has 
had a very positive effect on DMD's internals.
Jan 29
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 30 January 2024 at 00:41:02 UTC, Walter Bright wrote:

 D has the advantage of simple persistence. With enough 
 persistence, you can chop down an oak tree with a cauliflower.


Will you be livestreaming the next time you need to cut down a 
tree?
Jan 30
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Tuesday, 30 January 2024 at 00:41:02 UTC, Walter Bright wrote:

 D has the advantage of simple persistence. With enough 
 persistence, you can chop down an oak tree with a cauliflower.


Uh..... what? *A* cauliflower? I've worked with cauliflower and 
I've worked with oak. I'm skeptical.

Is there a hyper-speed cauliflower launcher involved?

-Steve
Jan 30
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

 On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

 I'm glad Andrew too has realized in what order to fix things - 
 we all should consider performance-problems bugs.

 See:

 https://youtu.be/5eL_LcxwwHg?t=565


 He thinks they have bugs because the compiler is too slow? That 
 is truly remarkable.


So, I'm not too familiar with Zig, and haven't used Zig much. 
However, at least on this specific point, he is very right, and 
this is something we were able to measure at scale at Facebook.

The question can better be asked in the following form: if we 
want to reduce errors, do we slow down development speed, in such 
a way that we can be more careful to not introduce problems at 
every steps along the way, or do we speed things up, such as it 
is faster to fix bugs, and therefore more can be fixed.

The usual answer most would give in the software industry is that 
one needs to slow down and be more careful. But this is not what 
the data ended up showing. Quite the opposite in fact!

When it comes to Zig, I am not sure how much development is 
slowed down by the speed of the compiler itself, but if this is a 
significant part of the dev cycle, then one has to expect that 
making the compiler faster will creates an environment in which 
there are fewer bugs.
Jan 30
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
It would certainly slow me down if the edit-compile-debug loop of the compiler 
was longer than a few seconds.
Jan 30
parent reply Don Allen <donaldcallen gmail.com> writes:
On Tuesday, 30 January 2024 at 17:12:56 UTC, Walter Bright wrote:

 It would certainly slow me down if the edit-compile-debug loop 
 of the compiler was longer than a few seconds.


Yes, of course it would. But would you attribute bugs 
accumulating at too fast a rate **solely** to "the compiler is 
too damned slow" and make a public announcement about this 
epiphany?

The Zig compiler, which I've used a fair amount, including the 
new self-hosted non-llvm version, is not as fast as DMD, but it's 
not that far off. It is nowhere near as slow as the Rust compiler 
or GHC. Neither the Rust project nor the GHC project is 
accumulating bugs at the rate the Zig project is.
Jan 30
parent Matheus Catarino <matheus-catarino hotmail.com> writes:
On Wednesday, 31 January 2024 at 01:24:35 UTC, Don Allen wrote:

 On Tuesday, 30 January 2024 at 17:12:56 UTC, Walter Bright 
 wrote:

 It would certainly slow me down if the edit-compile-debug loop 
 of the compiler was longer than a few seconds.


 Yes, of course it would. But would you attribute bugs 
 accumulating at too fast a rate **solely** to "the compiler is 
 too damned slow" and make a public announcement about this 
 epiphany?

 The Zig compiler, which I've used a fair amount, including the 
 new self-hosted non-llvm version, is not as fast as DMD, but 
 it's not that far off. It is nowhere near as slow as the Rust 
 compiler or GHC. Neither the Rust project nor the GHC project 
 is accumulating bugs at the rate the Zig project is.


**DMD version:** DMD64 D Compiler v2.106.1 (linux x86_64)
**Zig version:** 0.12.0-dev.2341+92211135f [master] (linux x86_64)

both examples have:

```d
void main(){}
```

```zig
pub fn main() void{}
```

**Self-hosting compilers - peformance**

```bash
$> hyperfine --warmup 5 'dmd -i hello.d' 'zig build-exe -fno-llvm 
-fno-lld hello.zig'
Benchmark 1: dmd -i hello.d
   Time (mean ± σ):     109.9 ms ±   1.6 ms    [User: 52.8 ms, 
System: 56.7 ms]
   Range (min … max):   108.1 ms … 114.3 ms    26 runs

Benchmark 2: zig build-exe -fno-llvm -fno-lld hello.zig
   Time (mean ± σ):     334.3 ms ±   3.5 ms    [User: 246.5 ms, 
System: 155.6 ms]
   Range (min … max):   329.1 ms … 342.2 ms    10 runs

Summary
   dmd -i hello.d ran
     3.04 ± 0.05 times faster than zig build-exe -fno-llvm 
-fno-lld hello.zig

```

**Glossary flag:**

- `-fno-llvm`: replace llvm backend to zig backend [wip].
- `-fno-lld`: replace llvm-lld (builtin) to zld (self-hosted zig 
linker).
Jan 31
prev sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Jan 30, 2024 at 12:25:24PM +0000, deadalnix via Digitalmars-d wrote:
[...]

 The question can better be asked in the following form: if we want to
 reduce errors, do we slow down development speed, in such a way that
 we can be more careful to not introduce problems at every steps along
 the way, or do we speed things up, such as it is faster to fix bugs,
 and therefore more can be fixed.
 
 The usual answer most would give in the software industry is that one
 needs to slow down and be more careful. But this is not what the data
 ended up showing. Quite the opposite in fact!


[...]

My experience confirms this.  When your code-compile-test cycle is slow,
you tend to spend more time to write more code / make more changes
before compiling and running it.  It's simple practicality: making only
few changes means more compile cycles, which means more time spent
waiting.  Making more changes means less time spent waiting for the
compile cycle.

But since more changes are made, there's more room for bugs.  And the
more changes you make means the more combinations you need to test
before you discover failing cases.  Due to combinatorial explosion, the
chances of catching these cases decrease exponentially the longer the
compile cycle is.

When the compile cycle is fast, the incentives shift the other way: you
make less changes before compile + test, so you get faster feedback on
any obvious bugs in your changes. So problems get caught early and get
fixed before they accumulate.  Your mind is also fresher when it's only
a small amount of changes -- you still remember the details of what's
happening, so you can fix it faster and more accurately.  And since
there are less combinations to test with each small change, you're more
likely to find failing cases early.

tl;dr: DMD's fast compile times is a killer feature.  It's why I still
use it in spite of its suboptimal codegen.


T

-- 
Let X be the set not defined by this sentence...
Jan 30
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 30 January 2024 at 18:33:45 UTC, H. S. Teoh wrote:

 [snip]

 tl;dr: DMD's fast compile times is a killer feature.  It's why 
 I still use it in spite of its suboptimal codegen.


 T


That's also why version-ing unittests is good. It lets you just 
run the UTs that you need to run. Got a new feature? Put a unique 
version just for that and run tests on those.

It gets trickier when you're dealing with features that go across 
multiple modules and such, but nothing that's not do-able. You 
can also combine them hierarchically if needed.
Jan 30
prev sibling next sibling parent user1234 <user1234 12.de> writes:
On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

 I'm glad Andrew too has realized in what order to fix things - 
 we all should consider performance-problems bugs.

 See:

 https://youtu.be/5eL_LcxwwHg?t=565


They pay the debt of the initial joy. Too much done without 
discipline. Now little hands are required to fix that.
Jan 29
prev sibling parent reply cc <cc nevernet.com> writes:
On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

 I'm glad Andrew too has realized in what order to fix things - 
 we all should consider performance-problems bugs.

 See:

 https://youtu.be/5eL_LcxwwHg?t=565


Honestly the speed of dmd is a miracle I take for granted too 
often.  It's more than just a convenience, it contributes to a 
harmonious state of mind that I have no doubt improves the 
performance of my work and the motivation to continue it.  I 
don't doubt at all that, across a long enough period of time, 
bugs could statistically accumulate more in an environment with a 
painfully long build process than in a comparatively faster one.  
Even if you're a diligent coder and you always "do the job right" 
and make the appropriate tests and so on, there's always a point 
where you're getting up for coffee breaks on every CTRL-B, 
turning away from the screen, walking into a different room and 
resetting your mental frame, leading to ideas getting lost in the 
carpet instead of remaining fresh in your mind.
Jan 30
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Tuesday, 30 January 2024 at 20:29:02 UTC, cc wrote:

 On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

 I'm glad Andrew too has realized in what order to fix things - 
 we all should consider performance-problems bugs.

 See:

 https://youtu.be/5eL_LcxwwHg?t=565


 Honestly the speed of dmd is a miracle I take for granted too 
 often.  It's more than just a convenience, it contributes to a 
 harmonious state of mind that I have no doubt improves the 
 performance of my work and the motivation to continue it.  I 
 don't doubt at all that, across a long enough period of time, 
 bugs could statistically accumulate more in an environment with 
 a painfully long build process than in a comparatively faster 
 one.  Even if you're a diligent coder and you always "do the 
 job right" and make the appropriate tests and so on, there's 
 always a point where you're getting up for coffee breaks on 
 every CTRL-B, turning away from the screen, walking into a 
 different room and resetting your mental frame, leading to 
 ideas getting lost in the carpet instead of remaining fresh in 
 your mind.


I see a lot of posts about the speed of dmd. I've been basically 
using ldc exclusively when I switched to mac M1, and, I haven't 
been very disappointed.

I'll say this, compiling my work project with dmd is 100x slower 
than compiling my personal projects with ldc.

I don't know if it's LLVM, is all I'm saying.

-Steve
Jan 30
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 31 January 2024 at 02:34:34 UTC, Steven 
Schveighoffer wrote:

 On Tuesday, 30 January 2024 at 20:29:02 UTC, cc wrote:

 [...]


 I see a lot of posts about the speed of dmd. I've been 
 basically using ldc exclusively when I switched to mac M1, and, 
 I haven't been very disappointed.

 I'll say this, compiling my work project with dmd is 100x 
 slower than compiling my personal projects with ldc.

 I don't know if it's LLVM, is all I'm saying.

 -Steve


As dmd is x86_64, on Apple silicon it uses rosetta, so ldc which 
is aarch64 is faster as a compiler.
Jan 31
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Wednesday, 31 January 2024 at 08:54:36 UTC, Paolo Invernizzi 
wrote:

 On Wednesday, 31 January 2024 at 02:34:34 UTC, Steven 
 Schveighoffer wrote:

 On Tuesday, 30 January 2024 at 20:29:02 UTC, cc wrote:

 [...]


 I see a lot of posts about the speed of dmd. I've been 
 basically using ldc exclusively when I switched to mac M1, 
 and, I haven't been very disappointed.

 I'll say this, compiling my work project with dmd is 100x 
 slower than compiling my personal projects with ldc.

 I don't know if it's LLVM, is all I'm saying.


 As dmd is x86_64, on Apple silicon it uses rosetta, so ldc 
 which is aarch64 is faster as a compiler.


Work project is built with dmd on x86_64 linux.

My point really is that LDC is comparable, and still lightyears 
ahead (in speed) of the likes of C++ and Rust. I don't know what 
Zig is planning to achieve by removing LLVM, but I am comfortable 
with the time taken so far. It helps to have 2 things to compare 
such that you can judge what the true benefit will be. I wonder 
if Zig has gone through that exercise, or is just undergoing this 
large upheaval on the *hopes* that it makes things much faster 
(Disclaimer, I'm reacting to posts here, I haven't watched the 
video).

In my experience, the thing that slows down compilation is the 
complexity of the code, especially when using 
templates/generative code. That is all front-end stuff. I'd 
rather we work on fixing that.

-Steve
Jan 31