7 ms·

GCC 10 supports Dlang directly. (The support is still immature and it's being updated to the newer version of Dlang.) Dlang compiles quickly not because the la

GCC 10 supports Dlang directly. (The support is still immature and it's being updated to the newer version of Dlang.) Dlang compiles quickly not because the language is simple, but because the compiler authors care about compilation speed: Lexer skips four spaces at once https://github.com/dlang/dmd/pull/11095 https://github.com/dlang/dmd/pull/11095 Optimize core logic to 7x compilation speed of language feature https://github.com/dlang/dmd/pull/11303 https://github.com/dlang/dmd/pull/11303 Cache rarely used types to improve memory locality https://github.com/dlang/dmd/pull/11363 https://github.com/dlang/dmd/pull/11363

PudgePacket 6y ago
Slightly off topic, I see D brought up incredibly consistently when Rust is mentioned on HN.. Is it just me?? (it's usually by walter themself but I digress..)
- Keyframe 6y ago
  A number of people (including myself) migrated from what was known as D1 onto Rust. Steve (Klabnik) was also one of the refugees. I can't speak for others, but Rust is kind of what I was expecting for D1 to go to.
  - aberba 6y ago
    Wow, didn't know Steve was rocking D.
- pjmlp 6y ago
  Some of us believe in systems programming languages with some form of GC, so it usually pops up as alternative. For me D is what .NET (thus C#) should have been if the Ext-VOS project (COM Runtime) decided to go native, instead of embracing J++ and then turning into .NET due to the lawsuit. But unfortunately D is a tiny community that gets by with small contributions and herding cats is hard.
VWWHFSfQ 6y ago
> but because the compiler authors care about compilation speed Is this meant to imply that the Rust compiler authors don't care about compilation speed?
- rat9988 6y ago
  Everybody cares about compilation speed. What would be interesting is how much time in percentage is spent optimizing it though. Does any one have any hard daya here?
  - steveklabnik 6y ago
    We don't track time of who works on what, so there's no way to answer this specific question with hard data.
- kungtotte 6y ago
  They haven't made it a priority until the last year or two, no efforts were made to improve it before then.
  - steveklabnik 6y ago
    This is simply not true. For example, here's the 2017 roadmap, which was authored in 2016 https://github.com/rust-lang/rfcs/blob/master/text/1774-roadmap-2017.md#rust-should-have-a-pleasant-edit-compile-debug-cycle https://github.com/rust-lang/rfcs/blob/master/text/1774-road... > The edit-compile-debug cycle in Rust takes too long, and it's one of the complaints we hear most often from production users. We've laid down a good foundation with MIR (now turned on by default) and incremental compilation (which recently hit alpha). But we need to continue pushing hard to actually deliver the improvements. And to fully address the problem, the improvement needs to apply to large Rust projects, not just small or mid-sized benchmarks. We didn't do these sorts of yearly plans before that, but note that it isn't just talking about what should be done then, but the work that was being done on this previously.
steveklabnik 6y ago
The Rust compiler folks care immensely about compile speed, and the language is a factor in both cases.
- crazypython 6y ago
  Walter Bright founded Dlang and continues to be the primary author of its compiler frontend. He is the sole author of dmc++/Zortech C++, the world's fastest C++03 compiler.
  - pdimitar 6y ago
    Such things are giving me hope that eventually all compilation to native CPU code will converge on a singular project. There's so much fragmented effort!
  - steveklabnik 6y ago
    Absolutely true. I'm not sure what you're implying though, none of that contradicts what I've said in any way.
  - tandr 6y ago
    Are you suggesting to hire Walter to work on Rust compiler/language itself?
- dragonwriter 6y ago
  I don't know about D, but a difference between Rust and Go, for instance, in this area might be that the Go language designers care about compilation speed, to the extent that it has influenced the language design, while in Rust that concern may be important in terms of implementing the compiler, but not enough to influence the language design.
  - steveklabnik 6y ago
    Yes, agreed fully. This is a good example of what I meant by the language being a factor :)
  - 6y ago
roca 6y ago
Nick Nethercote and others have done a lot of work with traditional profiling and optimization like that. They've done a great job, but for my project the fundamental problem seems to be limited parallelism, which I think requires more fundamental design changes (perhaps getting away from the crate-at-a-time approach of rustc). Though TBH I'm not an expert on the compiler and I'm not confident I know the root problems or the solutions.
- kzrdude 6y ago
  Performance of the generated code is always the #1 priority in both Rust and llvm, performance improvements are rarely declined, and this prioritization needs to change radically, to get a much faster compiler.
  - steveklabnik 6y ago
    Prioritization is not that straightforward. Every open source project has different sub-groups with different goals. While we do care a ton about generated code, there is also movement by other folks to work on the compiler speed problem. It has been a lot of work to come this far, and it will be even more work to get to a better place, but that work is underway. That's not even to mention that since rustc is written in Rust, work to make generated code faster can also make the compiler faster. I'm referring to the rust-analyzer work, which is effectively an outside-in re-write of the compiler, if you squint at it right. At the end of the day, rustc is a very large codebase, and has already undergone major architectural changes, and will be undergoing even more. It is not fast to steer a large ship in a new direction, but that is what is happening. See https://pbs.twimg.com/media/ENC1ls6XYAEdKkv?format=jpg&name=900x900 https://pbs.twimg.com/media/ENC1ls6XYAEdKkv?format=jpg&name=... for a time I ran https://github.com/erikbern/git-of-theseus https://github.com/erikbern/git-of-theseus on the rustc codebase. Thank goodness Rust is such a good refactoring language.
    - kzrdude 6y ago
      You are talking incremental improvements. Radical is needed not just using cranelift for debug builds, but something like that for all builds. Current llvm model does not work well for delivering a fast compiler (opt and non-debug)
erichdongubler 6y ago
It's important to note that run-time tradeoffs were made in the interest of fast compilation speed. When it comes to optimizing code emitted from D source, it's important to leverage the alternate implementations from GCC or the LLVM-based LDC...which don't sport nearly as fast compiles as DMD, the reference D compiler.
- crazypython 6y ago
  For DMD's backend, that is true. It's like Rust's MIR project, but finished. However, the commits I linked to describe front-end optimizations. LLVM-based D Compiler and GCC share DMD's front-end. I've seen some generated code optimizations for DMD's back-end as well, which could get one lightning fast compiles for decent code. (Maybe in the future one could write a JIT that first compiles with DMD then tiers up to LLVM D Compiler or GCC.)
  - erichdongubler 6y ago
    You're right, I didn't distinguish between overall compile times and the front-end time taken, which is what you were focusing on. For the Rust toolchain, the (vast IIRC) majority of compilation time is in LLVM's backend. So, to me, front-end optimizations are interesting, but not the highest priority for Rust specifically. LMD seems to be a great thing to compare against, so here's my follow-up question: What's the proportion of front-end to back-end time in LMD?
geofft 6y ago
The D language uses GC, so it's unlikely to be acceptable for the Linux kernel. (That's not to say that you can't write a kernel in D, just that the Linux kernel maintainers don't want to write a kernel that requires GC.) Rust's ownership model, which allows you to write straightforward, non-leaky, non-use-after-free-filled code without a GC, is quite complex at compile time. It's definitely possible to make it faster, but it's definitely a thing Rust does that D doesn't do.
- aberba 6y ago
  When you turn off D's GC then its no different from C or C++ . So yes, it can be done. At last D conference, someone presented on building kernel drivers in D.
- pjmlp 6y ago
  D is definitely trying to support it as well, how far they will get remains to be seen.
- CountHackulus 6y ago
  D has a nogc flag that can be used on methods and taints methods down the line. It's pretty neat. I'm a big fan of D, but I still think I wouldn't write a Kernel in D. I find it much more suited to quicker smaller programs, kind of like Python but with better typing. The script support for D is also really neat, and I've used that instead of Perl a few times.
zelly 6y ago
The push for Rust is coming from above, top-down. Watch what programmers do, not say. They prefer Go to Rust because it compiles fast.
- thayne 6y ago
  That depends on the programmer. Personally, I will choose rust ovet go almost every time, because I think it has a better type system, and is in many (but not all) ways more ergonomic. And that is more important to me than compile time, although I concede that other programmers (especially those with more experience with interpreted languages) prioritize compile time I over other language aspects. Besides which, my experience has been that when incrementally compiling during development, go compilation isn't actually that much faster.
  - zelly 6y ago
    Every language that goes all-in on type safety (Haskell, OCaml, F#, Scala) ends up being too hard to actually use in day-to-day programming. But people publicly say that they prefer it so as to not signal that they themselves find it too difficult. In an ideal world, I'd be writing everything in Coq, but I still live on earth and have deadlines, so I'll "do that some other day". All the code ends up being in some practical language, but when I get a developer survey I'll say I love the type safe hippie language.
    - thayne 6y ago
      I think the difficulty with those languagrs comes more from the pure functional paradigm than type safety. And I do use scala as a day-to-day language. Also, I'm not saying I prefer rust over go after reading some documentation and playing around with toy examples. I've written real code in both, and prefer the rust experience. I think go's main advantage is it is easy to learn. That is a real advantage in some cases (like onboarding new employees/contributors), but for me and many programmers I know it is not a sufficiently compelling reason to give up a more powerful type system.
      - 6y ago
marta_morena_25 6y ago
D was dead by all practical measures since its inception. It was never revolutionary enough to warrant the huge costs of migrating there. This is where Rust comes in...

PudgePacket 6y ago

Slightly off topic, I see D brought up incredibly consistently when Rust is mentioned on HN.. Is it just me?? (it's usually by walter themself but I digress..)

Keyframe 6y ago
A number of people (including myself) migrated from what was known as D1 onto Rust. Steve (Klabnik) was also one of the refugees. I can't speak for others, but Rust is kind of what I was expecting for D1 to go to.
- aberba 6y ago
  Wow, didn't know Steve was rocking D.
pjmlp 6y ago
Some of us believe in systems programming languages with some form of GC, so it usually pops up as alternative. For me D is what .NET (thus C#) should have been if the Ext-VOS project (COM Runtime) decided to go native, instead of embracing J++ and then turning into .NET due to the lawsuit. But unfortunately D is a tiny community that gets by with small contributions and herding cats is hard.

VWWHFSfQ 6y ago

> but because the compiler authors care about compilation speed Is this meant to imply that the Rust compiler authors don't care about compilation speed?

rat9988 6y ago
Everybody cares about compilation speed. What would be interesting is how much time in percentage is spent optimizing it though. Does any one have any hard daya here?
- steveklabnik 6y ago
  We don't track time of who works on what, so there's no way to answer this specific question with hard data.
kungtotte 6y ago
They haven't made it a priority until the last year or two, no efforts were made to improve it before then.
- steveklabnik 6y ago
  This is simply not true. For example, here's the 2017 roadmap, which was authored in 2016 https://github.com/rust-lang/rfcs/blob/master/text/1774-roadmap-2017.md#rust-should-have-a-pleasant-edit-compile-debug-cycle https://github.com/rust-lang/rfcs/blob/master/text/1774-road... > The edit-compile-debug cycle in Rust takes too long, and it's one of the complaints we hear most often from production users. We've laid down a good foundation with MIR (now turned on by default) and incremental compilation (which recently hit alpha). But we need to continue pushing hard to actually deliver the improvements. And to fully address the problem, the improvement needs to apply to large Rust projects, not just small or mid-sized benchmarks. We didn't do these sorts of yearly plans before that, but note that it isn't just talking about what should be done then, but the work that was being done on this previously.

steveklabnik 6y ago

The Rust compiler folks care immensely about compile speed, and the language is a factor in both cases.

crazypython 6y ago
Walter Bright founded Dlang and continues to be the primary author of its compiler frontend. He is the sole author of dmc++/Zortech C++, the world's fastest C++03 compiler.
- pdimitar 6y ago
  Such things are giving me hope that eventually all compilation to native CPU code will converge on a singular project. There's so much fragmented effort!
- steveklabnik 6y ago
  Absolutely true. I'm not sure what you're implying though, none of that contradicts what I've said in any way.
- tandr 6y ago
  Are you suggesting to hire Walter to work on Rust compiler/language itself?
dragonwriter 6y ago
I don't know about D, but a difference between Rust and Go, for instance, in this area might be that the Go language designers care about compilation speed, to the extent that it has influenced the language design, while in Rust that concern may be important in terms of implementing the compiler, but not enough to influence the language design.
- steveklabnik 6y ago
  Yes, agreed fully. This is a good example of what I meant by the language being a factor :)
- 6y ago

roca 6y ago

Nick Nethercote and others have done a lot of work with traditional profiling and optimization like that. They've done a great job, but for my project the fundamental problem seems to be limited parallelism, which I think requires more fundamental design changes (perhaps getting away from the crate-at-a-time approach of rustc). Though TBH I'm not an expert on the compiler and I'm not confident I know the root problems or the solutions.

kzrdude 6y ago
Performance of the generated code is always the #1 priority in both Rust and llvm, performance improvements are rarely declined, and this prioritization needs to change radically, to get a much faster compiler.
- steveklabnik 6y ago
  Prioritization is not that straightforward. Every open source project has different sub-groups with different goals. While we do care a ton about generated code, there is also movement by other folks to work on the compiler speed problem. It has been a lot of work to come this far, and it will be even more work to get to a better place, but that work is underway. That's not even to mention that since rustc is written in Rust, work to make generated code faster can also make the compiler faster. I'm referring to the rust-analyzer work, which is effectively an outside-in re-write of the compiler, if you squint at it right. At the end of the day, rustc is a very large codebase, and has already undergone major architectural changes, and will be undergoing even more. It is not fast to steer a large ship in a new direction, but that is what is happening. See https://pbs.twimg.com/media/ENC1ls6XYAEdKkv?format=jpg&name=900x900 https://pbs.twimg.com/media/ENC1ls6XYAEdKkv?format=jpg&name=... for a time I ran https://github.com/erikbern/git-of-theseus https://github.com/erikbern/git-of-theseus on the rustc codebase. Thank goodness Rust is such a good refactoring language.
  - kzrdude 6y ago
    You are talking incremental improvements. Radical is needed not just using cranelift for debug builds, but something like that for all builds. Current llvm model does not work well for delivering a fast compiler (opt and non-debug)

erichdongubler 6y ago

It's important to note that run-time tradeoffs were made in the interest of fast compilation speed. When it comes to optimizing code emitted from D source, it's important to leverage the alternate implementations from GCC or the LLVM-based LDC...which don't sport nearly as fast compiles as DMD, the reference D compiler.

crazypython 6y ago
For DMD's backend, that is true. It's like Rust's MIR project, but finished. However, the commits I linked to describe front-end optimizations. LLVM-based D Compiler and GCC share DMD's front-end. I've seen some generated code optimizations for DMD's back-end as well, which could get one lightning fast compiles for decent code. (Maybe in the future one could write a JIT that first compiles with DMD then tiers up to LLVM D Compiler or GCC.)
- erichdongubler 6y ago
  You're right, I didn't distinguish between overall compile times and the front-end time taken, which is what you were focusing on. For the Rust toolchain, the (vast IIRC) majority of compilation time is in LLVM's backend. So, to me, front-end optimizations are interesting, but not the highest priority for Rust specifically. LMD seems to be a great thing to compare against, so here's my follow-up question: What's the proportion of front-end to back-end time in LMD?

geofft 6y ago

The D language uses GC, so it's unlikely to be acceptable for the Linux kernel. (That's not to say that you can't write a kernel in D, just that the Linux kernel maintainers don't want to write a kernel that requires GC.) Rust's ownership model, which allows you to write straightforward, non-leaky, non-use-after-free-filled code without a GC, is quite complex at compile time. It's definitely possible to make it faster, but it's definitely a thing Rust does that D doesn't do.

aberba 6y ago
When you turn off D's GC then its no different from C or C++ . So yes, it can be done. At last D conference, someone presented on building kernel drivers in D.
pjmlp 6y ago
D is definitely trying to support it as well, how far they will get remains to be seen.
CountHackulus 6y ago
D has a nogc flag that can be used on methods and taints methods down the line. It's pretty neat. I'm a big fan of D, but I still think I wouldn't write a Kernel in D. I find it much more suited to quicker smaller programs, kind of like Python but with better typing. The script support for D is also really neat, and I've used that instead of Perl a few times.

zelly 6y ago

The push for Rust is coming from above, top-down. Watch what programmers do, not say. They prefer Go to Rust because it compiles fast.

thayne 6y ago
That depends on the programmer. Personally, I will choose rust ovet go almost every time, because I think it has a better type system, and is in many (but not all) ways more ergonomic. And that is more important to me than compile time, although I concede that other programmers (especially those with more experience with interpreted languages) prioritize compile time I over other language aspects. Besides which, my experience has been that when incrementally compiling during development, go compilation isn't actually that much faster.
- zelly 6y ago
  Every language that goes all-in on type safety (Haskell, OCaml, F#, Scala) ends up being too hard to actually use in day-to-day programming. But people publicly say that they prefer it so as to not signal that they themselves find it too difficult. In an ideal world, I'd be writing everything in Coq, but I still live on earth and have deadlines, so I'll "do that some other day". All the code ends up being in some practical language, but when I get a developer survey I'll say I love the type safe hippie language.
  - thayne 6y ago
    I think the difficulty with those languagrs comes more from the pure functional paradigm than type safety. And I do use scala as a day-to-day language. Also, I'm not saying I prefer rust over go after reading some documentation and playing around with toy examples. I've written real code in both, and prefer the rust experience. I think go's main advantage is it is easy to learn. That is a real advantage in some cases (like onboarding new employees/contributors), but for me and many programmers I know it is not a sufficiently compelling reason to give up a more powerful type system.
    - 6y ago

marta_morena_25 6y ago

D was dead by all practical measures since its inception. It was never revolutionary enough to warrant the huge costs of migrating there. This is where Rust comes in...