12 ms·

I'm not sure it's realistic to expect a safety focused compiler to compete with one that doesn't offer those checks. We should aspire to make it as fast but in

by cube00 4y ago

I'm not sure it's realistic to expect a safety focused compiler to compete with one that doesn't offer those checks. We should aspire to make it as fast but in the short term a slower compiler in exchange for less CVEs and random buffer overrun crashes seems like a reasonable trade off to me. Distributions such as Fedora offer build infrastructure[1] that you can use to compile packages to use in your system for testing if you feel your local hardware isn't powerful enough. [1]: https://copr.fedorainfracloud.org https://copr.fedorainfracloud.org

raverbashing 4y ago
I think it's more related to the grammatical complexity of the language than to safety itself (Same reason why C with typedefs is slower to compile than plain C, why C++ is slower, etc) (that and cargo dependencies, etc - also C compilers have some +30yrs of optimizations)
- akira2501 4y ago
  I've seen some Rust programs that look nice, but in the kernel, the code ends up making perl'ls propensity for line noise look competitive. I'm sure some of that is the need to shovel between languages, but it does make you wonder if the entire effort is a little misguided. A full Rust kernel might be neat. A compromised Rust driver inside of a C kernel is never going to be the default choice.
  - bonzini 4y ago
    Most of the code committed to the kernel is infrastructure for C<->Rust interoperability. It's the least readable of it all, and as fun to work on as watching paint dry. The actual driver code is pretty readable, see https://lwn.net/Articles/863459/ https://lwn.net/Articles/863459/.
  - coldacid 4y ago
    >A full Rust kernel might be neat. May I interest you in Redox? https://www.redox-os.org/ https://www.redox-os.org/
  - steveklabnik 4y ago
    If "embedded OS" counts as "full Rust kernel", you may want to check out https://hubris.oxide.computer/ https://hubris.oxide.computer/ Obviously very different than Linux.
- WastingMyTime89 4y ago
  More complexe languages are faster to compile. The issue is mostly the implementation. It could, should and will be better but it takes time.
- api 4y ago
  As others have pointed out most of the performance hit is in the optimization of the relatively verbose IR code the Rust compiler sends to LLVM, not the Rust compiler itself. There's been multiple passes at making the Rust compiler faster. It'll happen. There's a GCC-based Rust implementation in the works too.
goodpoint 4y ago
Nim is also memory safe and the compilation is really fast.
- codewithcheese 4y ago
  > No, Nim doesn't have stronger or weaker safety guarantees than Rust [1]. Rust's memory safety is nothing new, either. It is mostly that some older languages like C/C++ are the exceptions in not being memory-safe. There is nothing new or magical about memory safety. LISP was already memory-safe when it was invented in 1958. The only question is how much performance you need to trade away for it (the value is never zero for non-trivial programs, but can vary greatly, depending on whether the language was designed with it in mind or not). > The main difference between Rust and other languages is that it does some more (but not all [2]) safety checks at compile time rather than at runtime. It also allows you to avoid GC, but does not provide you any memory safety over GC. Rust's borrow checker allows you to statically prove that references are live [3]; a GC simply avoids deallocating any memory that has a live reference to it (on the other hand, a GC can ensure that references remain live even where this is hard or impossible to prove statically). The end result is the same with respect to memory safety (the reason some people want to avoid GC is for performance reasons, not memory safety). https://forum.nim-lang.org/t/1961 https://forum.nim-lang.org/t/1961
  - goodpoint 4y ago
    That's outdated information from 2016. Now Nim uses ARC/ORC. ARC implements memory management at compile time like Rust and it's still very fast at compiling.
    - codewithcheese 4y ago
      Cool, I wasn't aware, thanks. https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... > The main difference between ARC and Nim GCs is that ARC is fully deterministic - the compiler automatically injects destructors when it deems that some variable (a string, sequence, reference, or something else) is no longer needed. In this sense, it’s similar to C++ with its destructors (RAII). To illustrate, we can use Nim’s expandArc introspection (will be available in Nim 1.4). > This shows one of the main ARC features: scope-based memory management. A scope is a separate region of code in the program. Scope-based MM means that the compiler will automatically insert destructor calls for any variables which need a destructor after the scope ends. Many Nim constructs introduce new scopes: procs, funcs, converters, methods, block statements and expressions, for and while loops, etc. > ARC also has so-called hooks - special procedures that can be defined for types to override the default compiler behaviour when destroying/moving/copying the variable. These are particularly useful when you want to make custom semantics for your types, deal with low-level operations involving pointers, or do FFI.
rob74 4y ago
Actually C/C++ compilers are shooting themselves in the foot performance-wise with the header mechanism, so writing a compiler that's faster than C/C++ is not that hard. Not sure what the reasons of the Rust compiler being (even more?) slow are, maybe the ability to easily interface with C code has something to do with it?
- nine_k 4y ago
  Last time I checked [1], the Rust part of the Rust compiler is not the slowest. LLVM spends a lot of time processing relatively poor IR code which the Rust compiler emits. Rust compilation is not intrinsically slow; better IR and more incremental compilation can and will improve it. Incremental compilation (only changed files, not crates) is 7 years in making though. [1]: https://prev.rust-lang.org/en-US/faq.html#why-is-rustc-slow https://prev.rust-lang.org/en-US/faq.html#why-is-rustc-slow
  - rob74 4y ago
    Thanks for that link! That sounds like the really major factor is the decision to recompile the entire crate when a file in the crate changes. I'm sure that made sense at the time ;) And, if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision - incremental compilation might have its edge cases and pitfalls, but other compilers are doing it just fine, so it shouldn't be rocket science? Other reasons: - suboptimal LLVM IR code, as you mentioned, and other tech debt - the preferred strategy of monomorphising generics is fast at runtime, but slow to compile, using trait objects is faster - the complex type system of course also plays a part - LLVM itself is of course not optimized for Rust
    - rbanffy 4y ago
      > if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision Maybe we are giving Rust developers computers that are too fast. ;-) OTOH, it's always wise to design for the future, so it also makes sense to give Rust developers beefy server grade hardware so they can play with SIMD pipelines and all those extra cores and threads, because that's what workstations will be a couple years from now.
pjmlp 4y ago
There are languages with similar type safety, which are faster, because the authors have placed focus on having several ways available to compile the code. Ada, Delphi, OCaml, C#/F# (.NET Native / Native AOT), D, Nim,...
- 0dayz 4y ago
  I will admit I never understood why Ada never took off (is it only because of the tooling being propertiary for a long time?), but c# is not as memory safe as rust.
  - pjmlp 4y ago
    The only memory safety that C# lacks in comparisaion with Rust is one special case, data races for in-process data. For everything else regarding concurrent access to shared data out of process, they are on the same foot. Ada didn't took off, because of several reasons, price of compilers, on UNIX it was an additional SKU on top of the respective developers SDK that already offered C and C++ in the box, 1980's mainstream hardware wasn't able to cope with it, most OS vendors outside UNIX decide to migrate from their toolchains into C and C++, so again additional money on top of the OS SDK.
  - thesuperbigfrog 4y ago
    >> I will admit I never understood why Ada never took off (is it only because of the tooling being propertiary for a long time?) Early Ada compilers had expensive licensing and required expensive hardware to run. By the time GNAT was added to GCC, C++ had already taken over most of the spaces that were not Ada exclusive (meaning safety critical / defense / aerospace niches where either Ada was once mandated or has thrived in despite the original high costs).
- mejutoco 4y ago
  Does C# not have a GC? I thought that would immediately disqualify it for kernel work.
  - theta_d 4y ago
VikingCoder 4y ago
What's the old adage? It's easier to make a correct thing fast than it is to make a fast thing correct.

by cube00 4y ago

raverbashing 4y ago

I think it's more related to the grammatical complexity of the language than to safety itself (Same reason why C with typedefs is slower to compile than plain C, why C++ is slower, etc) (that and cargo dependencies, etc - also C compilers have some +30yrs of optimizations)

akira2501 4y ago
I've seen some Rust programs that look nice, but in the kernel, the code ends up making perl'ls propensity for line noise look competitive. I'm sure some of that is the need to shovel between languages, but it does make you wonder if the entire effort is a little misguided. A full Rust kernel might be neat. A compromised Rust driver inside of a C kernel is never going to be the default choice.
- bonzini 4y ago
  Most of the code committed to the kernel is infrastructure for C<->Rust interoperability. It's the least readable of it all, and as fun to work on as watching paint dry. The actual driver code is pretty readable, see https://lwn.net/Articles/863459/ https://lwn.net/Articles/863459/.
- coldacid 4y ago
  >A full Rust kernel might be neat. May I interest you in Redox? https://www.redox-os.org/ https://www.redox-os.org/
- steveklabnik 4y ago
  If "embedded OS" counts as "full Rust kernel", you may want to check out https://hubris.oxide.computer/ https://hubris.oxide.computer/ Obviously very different than Linux.
WastingMyTime89 4y ago
More complexe languages are faster to compile. The issue is mostly the implementation. It could, should and will be better but it takes time.
api 4y ago
As others have pointed out most of the performance hit is in the optimization of the relatively verbose IR code the Rust compiler sends to LLVM, not the Rust compiler itself. There's been multiple passes at making the Rust compiler faster. It'll happen. There's a GCC-based Rust implementation in the works too.

goodpoint 4y ago

Nim is also memory safe and the compilation is really fast.

codewithcheese 4y ago
> No, Nim doesn't have stronger or weaker safety guarantees than Rust [1]. Rust's memory safety is nothing new, either. It is mostly that some older languages like C/C++ are the exceptions in not being memory-safe. There is nothing new or magical about memory safety. LISP was already memory-safe when it was invented in 1958. The only question is how much performance you need to trade away for it (the value is never zero for non-trivial programs, but can vary greatly, depending on whether the language was designed with it in mind or not). > The main difference between Rust and other languages is that it does some more (but not all [2]) safety checks at compile time rather than at runtime. It also allows you to avoid GC, but does not provide you any memory safety over GC. Rust's borrow checker allows you to statically prove that references are live [3]; a GC simply avoids deallocating any memory that has a live reference to it (on the other hand, a GC can ensure that references remain live even where this is hard or impossible to prove statically). The end result is the same with respect to memory safety (the reason some people want to avoid GC is for performance reasons, not memory safety). https://forum.nim-lang.org/t/1961 https://forum.nim-lang.org/t/1961
- goodpoint 4y ago
  That's outdated information from 2016. Now Nim uses ARC/ORC. ARC implements memory management at compile time like Rust and it's still very fast at compiling.
  - codewithcheese 4y ago
    Cool, I wasn't aware, thanks. https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... > The main difference between ARC and Nim GCs is that ARC is fully deterministic - the compiler automatically injects destructors when it deems that some variable (a string, sequence, reference, or something else) is no longer needed. In this sense, it’s similar to C++ with its destructors (RAII). To illustrate, we can use Nim’s expandArc introspection (will be available in Nim 1.4). > This shows one of the main ARC features: scope-based memory management. A scope is a separate region of code in the program. Scope-based MM means that the compiler will automatically insert destructor calls for any variables which need a destructor after the scope ends. Many Nim constructs introduce new scopes: procs, funcs, converters, methods, block statements and expressions, for and while loops, etc. > ARC also has so-called hooks - special procedures that can be defined for types to override the default compiler behaviour when destroying/moving/copying the variable. These are particularly useful when you want to make custom semantics for your types, deal with low-level operations involving pointers, or do FFI.

rob74 4y ago

Actually C/C++ compilers are shooting themselves in the foot performance-wise with the header mechanism, so writing a compiler that's faster than C/C++ is not that hard. Not sure what the reasons of the Rust compiler being (even more?) slow are, maybe the ability to easily interface with C code has something to do with it?

nine_k 4y ago
Last time I checked [1], the Rust part of the Rust compiler is not the slowest. LLVM spends a lot of time processing relatively poor IR code which the Rust compiler emits. Rust compilation is not intrinsically slow; better IR and more incremental compilation can and will improve it. Incremental compilation (only changed files, not crates) is 7 years in making though. [1]: https://prev.rust-lang.org/en-US/faq.html#why-is-rustc-slow https://prev.rust-lang.org/en-US/faq.html#why-is-rustc-slow
- rob74 4y ago
  Thanks for that link! That sounds like the really major factor is the decision to recompile the entire crate when a file in the crate changes. I'm sure that made sense at the time ;) And, if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision - incremental compilation might have its edge cases and pitfalls, but other compilers are doing it just fine, so it shouldn't be rocket science? Other reasons: - suboptimal LLVM IR code, as you mentioned, and other tech debt - the preferred strategy of monomorphising generics is fast at runtime, but slow to compile, using trait objects is faster - the complex type system of course also plays a part - LLVM itself is of course not optimized for Rust
  - rbanffy 4y ago
    > if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision Maybe we are giving Rust developers computers that are too fast. ;-) OTOH, it's always wise to design for the future, so it also makes sense to give Rust developers beefy server grade hardware so they can play with SIMD pipelines and all those extra cores and threads, because that's what workstations will be a couple years from now.

pjmlp 4y ago

There are languages with similar type safety, which are faster, because the authors have placed focus on having several ways available to compile the code. Ada, Delphi, OCaml, C#/F# (.NET Native / Native AOT), D, Nim,...

0dayz 4y ago
I will admit I never understood why Ada never took off (is it only because of the tooling being propertiary for a long time?), but c# is not as memory safe as rust.
- pjmlp 4y ago
  The only memory safety that C# lacks in comparisaion with Rust is one special case, data races for in-process data. For everything else regarding concurrent access to shared data out of process, they are on the same foot. Ada didn't took off, because of several reasons, price of compilers, on UNIX it was an additional SKU on top of the respective developers SDK that already offered C and C++ in the box, 1980's mainstream hardware wasn't able to cope with it, most OS vendors outside UNIX decide to migrate from their toolchains into C and C++, so again additional money on top of the OS SDK.
- thesuperbigfrog 4y ago
  >> I will admit I never understood why Ada never took off (is it only because of the tooling being propertiary for a long time?) Early Ada compilers had expensive licensing and required expensive hardware to run. By the time GNAT was added to GCC, C++ had already taken over most of the spaces that were not Ada exclusive (meaning safety critical / defense / aerospace niches where either Ada was once mandated or has thrived in despite the original high costs).
mejutoco 4y ago
Does C# not have a GC? I thought that would immediately disqualify it for kernel work.
- theta_d 4y ago

VikingCoder 4y ago

What's the old adage? It's easier to make a correct thing fast than it is to make a fast thing correct.