5 ms·

> The aim is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are use

> The aim is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used One question about this to people more versed in language compilation - wouldn't it be possible for SAFE Rust code to be faster than C code considering that the Rust compiler has much more syntax to play around and optimize? Cause many of those safe constructs are part of the language and can be taken into account

pkhuong 9y ago
The expressiveness of LLVM IR is very close to C. Given a high enough tolerance for pain, one could implement the same rewrite that the rust compiler would implement in C (without even going into inline assembly). In practice… maybe. However, I find we're more forgiving of unpredictable performance (either wrt analysis runtime or quality of analysis) in safety checking tools than in code generators. The ergonomics of bitblasting code generation questions to SAT aren't great.
CapacitorSet 9y ago
I wouldn't be too sure about that. Rust gives more compile-time guarantees, allowing the compiler not to emit code for otherwise plausible conditions (see eg. pointer aliasing); on the other hand, C compilers typically rely on undefined behaviour to apply optimisations, whereas Rust may not have as much undefined behaviour due to its safety.
- steveklabnik 9y ago
  Safe Rust has no UB, outside of some bugs, to be clear. That said, optimization is all about guarantees: this broad of a claim (UB vs info) because both are about what's guaranteed, and what's not. That is, they play similar roles, so you'd have to be comparing how much of each is in what amount in what code. We generally expect Rust to be roughly as fast as C, sometimes faster, sometimes slower. Modulo optimizer bugs in each case, of course.
chrismorgan 9y ago
In theory, yes, some Rust code can be faster than the C or C++ code people would write, especially as pertains to the guarantees offered by its aliasing control. In practice, LLVM hasn’t had any incentive to implement those sorts of optimisations at this stage (because before Rust came along nothing would benefit from them), so the benefits are generally theoretical only. It remains to be seen what this will effect.
- muizelaar 9y ago
  LLVM does implement these sorts of optimizations: C: int foo(int *x, int *y) { *x = 0; *y = 1; return *x; } gives: foo(int*, int*): # @foo(int*, int*) mov dword ptr [rdi], 0 mov dword ptr [rsi], 1 mov eax, dword ptr [rdi] ret where as in Rust: fn foo(x: &mut i32, y: &mut i32) -> i32 { *x = 0; *y = 1; *x } which compiles to: example::foo: mov dword ptr [rdi], 0 mov dword ptr [rsi], 1 xor eax, eax ret
  - andoma 9y ago
    For the record, gcc and clang does this as well when using the restrict keyword. (I'm still a big fan of Rust though) int foo(int *restrict x, int *restrict y) { *x = 0; *y = 1; return *x; } Compiles to: foo: movl $0, (%rdi) movl $1, (%rsi) xorl %eax, %eax ret
  - wolf550e 9y ago
    That optimization is useful to C and C++ code, they use "restrict": https://en.wikipedia.org/wiki/Restrict https://en.wikipedia.org/wiki/Restrict Does LLVM implement optimization that only Rust can use, or at least those that cannot be used from C/C++?
    - steveklabnik 9y ago
      &mut T pointers are basically restrict by default. LLVM is adding some semantics specific to non-C or C++ languages. I’m on my phone so I can’t link you, but they’re adding an intrinsic related to infinite loops because languages like Rust have different semantics here.
deleted 9y ago
[deleted]
fixermark 9y ago
I think it goes a bit further---it aims to produce software libraries that are safer than Go or Rust. For example, Go will cheerfully allow construction of an arithmetic operation that overflows integer size; the behavior is well-defined and not an exception, but if the developer is not anticipating it, it can result in some suprising code (as Go specifies, the compiler is not allowed to assume x < x + 1, but that's a very easy trap for a programmer to fall into). Puffs lets you specify in the code that you do not intend to allow arithmetic overflow at all. It also has types to distinguish pointers that may be null and pointers that must not be null.
- nigeltao 9y ago
  Exactly. In the announcement (https://groups.google.com/forum/#!topic/puffslang/2z61mNTAMns/discussion https://groups.google.com/forum/#!topic/puffslang/2z61mNTAMn...), I said "Rust can check for arithmetic overflow (at run time), but after some debate, the Rust team decided to disable such checks when building in release mode, for performance reasons. Obviously, though, we don't ship our users debug builds." Puffs enforces arithmetic overflow checks (it's not optional, and you don't have to specify that you intend to check overflow). It differs from Rust in that it's done entirely at compile time instead of at run time.
steveklabnik 9y ago
There's two more interesting ways to think about this: what's the average case, and what's maintainable? What's the comparison in speed between an average C programmer vs an average Rust programmer? Rust usually defaults to the fast thing, which can lead to performance surprises when it doesn't. But I think this question is more interesting than "what can the best C coder do vs the best Rust coder", the average is what is going to be the case for a much bigger segment of programmers. Secondly, what's maintainable? For example, take the Stylo and Firefox devs: you can absolutely do what Stylo does, but in C. But can you maintain it? Rust's safety guarantees let you do very aggressive things that are too tricky in C. Yes, you could write the code. When you come back three months later, and modify the code, will you make a mistake? The Rust compiler will catch you here, but the C compiler probably won't... A related version of this story: one of the core devs talks about working on some code that needed reference counting deep in the core. He used Rc, which is non-atomic, because the original case was not threaded. He came back a few months later, trying to paralellize it, and got a compile-time error, pointing to the guts that used the un-threadsafe code. He was able to immediately fix it, whereas if the compiler couldn't have checked this kind of thing, it would have been a subtle, hard to reproduce bug. TL;DR: these kinds of comparisons are very difficult and often anecdotal. We'll see empirically as time marches on :)
- margorczynski 9y ago
  That's also how I see it and that e.g. Rust can really increase the average quality of software and reduce the cost of maintaining/extending compared to C and C++. I wrote quite a bit of C and I like the language as it really fits its purpose (the thinnest and usable layer above Assembly) but I would never want to create/maintain a big application (especially threaded) in it
  - nitrogen 9y ago
    C is manageable if you use memory and concurrency checking tools like Valgrind, but Valgrind doesn't guarantee that your tests cover all possible behaviors of your code.
    - 9y ago
Manishearth 9y ago
> wouldn't it be possible for SAFE Rust code to be faster than C code considering that the Rust compiler has much more syntax to play around and optimize? Yes. Rust has TONS of aliasing info that optimizers essentially spend a lot of time recovering in other programs. However, LLVM doesn't support being told about all of it, and doesn't make use of it that much directly (we can at best tell LLVM that a whole bunch of things are `restrict`). In fact, we had to stop doing this for `&mut` because LLVM had too many bugs around that. C/C++ codebases don't benefit from this as much so LLVM doesn't prioritize this. Rust can do optimizations at the MIR level and I'm hoping we'll do more in that space in the future.
- vvanders 9y ago
  That's pretty depressing, restrict is killer when you really want to eek out performance and I've had an intuition that Rust had all the relevant info to automatically use it.
  - inimino 9y ago
    eke out
  - bjz_ 9y ago
    I dunno, it's actually exciting imo. Means we've got more speed to see yet from Rust! :)
  - kibwen 9y ago
    Rust does have the information to, but it has so much information that LLVM doesn't yet know what to do with it all. :P

pkhuong 9y ago

The expressiveness of LLVM IR is very close to C. Given a high enough tolerance for pain, one could implement the same rewrite that the rust compiler would implement in C (without even going into inline assembly). In practice… maybe. However, I find we're more forgiving of unpredictable performance (either wrt analysis runtime or quality of analysis) in safety checking tools than in code generators. The ergonomics of bitblasting code generation questions to SAT aren't great.

CapacitorSet 9y ago

I wouldn't be too sure about that. Rust gives more compile-time guarantees, allowing the compiler not to emit code for otherwise plausible conditions (see eg. pointer aliasing); on the other hand, C compilers typically rely on undefined behaviour to apply optimisations, whereas Rust may not have as much undefined behaviour due to its safety.

steveklabnik 9y ago
Safe Rust has no UB, outside of some bugs, to be clear. That said, optimization is all about guarantees: this broad of a claim (UB vs info) because both are about what's guaranteed, and what's not. That is, they play similar roles, so you'd have to be comparing how much of each is in what amount in what code. We generally expect Rust to be roughly as fast as C, sometimes faster, sometimes slower. Modulo optimizer bugs in each case, of course.

chrismorgan 9y ago

In theory, yes, some Rust code can be faster than the C or C++ code people would write, especially as pertains to the guarantees offered by its aliasing control. In practice, LLVM hasn’t had any incentive to implement those sorts of optimisations at this stage (because before Rust came along nothing would benefit from them), so the benefits are generally theoretical only. It remains to be seen what this will effect.

muizelaar 9y ago
LLVM does implement these sorts of optimizations: C: int foo(int *x, int *y) { *x = 0; *y = 1; return *x; } gives: foo(int*, int*): # @foo(int*, int*) mov dword ptr [rdi], 0 mov dword ptr [rsi], 1 mov eax, dword ptr [rdi] ret where as in Rust: fn foo(x: &mut i32, y: &mut i32) -> i32 { *x = 0; *y = 1; *x } which compiles to: example::foo: mov dword ptr [rdi], 0 mov dword ptr [rsi], 1 xor eax, eax ret
- andoma 9y ago
  For the record, gcc and clang does this as well when using the restrict keyword. (I'm still a big fan of Rust though) int foo(int *restrict x, int *restrict y) { *x = 0; *y = 1; return *x; } Compiles to: foo: movl $0, (%rdi) movl $1, (%rsi) xorl %eax, %eax ret
- wolf550e 9y ago
  That optimization is useful to C and C++ code, they use "restrict": https://en.wikipedia.org/wiki/Restrict https://en.wikipedia.org/wiki/Restrict Does LLVM implement optimization that only Rust can use, or at least those that cannot be used from C/C++?
  - steveklabnik 9y ago
    &mut T pointers are basically restrict by default. LLVM is adding some semantics specific to non-C or C++ languages. I’m on my phone so I can’t link you, but they’re adding an intrinsic related to infinite loops because languages like Rust have different semantics here.

deleted 9y ago

[deleted]

fixermark 9y ago

I think it goes a bit further---it aims to produce software libraries that are safer than Go or Rust. For example, Go will cheerfully allow construction of an arithmetic operation that overflows integer size; the behavior is well-defined and not an exception, but if the developer is not anticipating it, it can result in some suprising code (as Go specifies, the compiler is not allowed to assume x < x + 1, but that's a very easy trap for a programmer to fall into). Puffs lets you specify in the code that you do not intend to allow arithmetic overflow at all. It also has types to distinguish pointers that may be null and pointers that must not be null.

nigeltao 9y ago
Exactly. In the announcement (https://groups.google.com/forum/#!topic/puffslang/2z61mNTAMns/discussion https://groups.google.com/forum/#!topic/puffslang/2z61mNTAMn...), I said "Rust can check for arithmetic overflow (at run time), but after some debate, the Rust team decided to disable such checks when building in release mode, for performance reasons. Obviously, though, we don't ship our users debug builds." Puffs enforces arithmetic overflow checks (it's not optional, and you don't have to specify that you intend to check overflow). It differs from Rust in that it's done entirely at compile time instead of at run time.

steveklabnik 9y ago

There's two more interesting ways to think about this: what's the average case, and what's maintainable? What's the comparison in speed between an average C programmer vs an average Rust programmer? Rust usually defaults to the fast thing, which can lead to performance surprises when it doesn't. But I think this question is more interesting than "what can the best C coder do vs the best Rust coder", the average is what is going to be the case for a much bigger segment of programmers. Secondly, what's maintainable? For example, take the Stylo and Firefox devs: you can absolutely do what Stylo does, but in C. But can you maintain it? Rust's safety guarantees let you do very aggressive things that are too tricky in C. Yes, you could write the code. When you come back three months later, and modify the code, will you make a mistake? The Rust compiler will catch you here, but the C compiler probably won't... A related version of this story: one of the core devs talks about working on some code that needed reference counting deep in the core. He used Rc, which is non-atomic, because the original case was not threaded. He came back a few months later, trying to paralellize it, and got a compile-time error, pointing to the guts that used the un-threadsafe code. He was able to immediately fix it, whereas if the compiler couldn't have checked this kind of thing, it would have been a subtle, hard to reproduce bug. TL;DR: these kinds of comparisons are very difficult and often anecdotal. We'll see empirically as time marches on :)

margorczynski 9y ago
That's also how I see it and that e.g. Rust can really increase the average quality of software and reduce the cost of maintaining/extending compared to C and C++. I wrote quite a bit of C and I like the language as it really fits its purpose (the thinnest and usable layer above Assembly) but I would never want to create/maintain a big application (especially threaded) in it
- nitrogen 9y ago
  C is manageable if you use memory and concurrency checking tools like Valgrind, but Valgrind doesn't guarantee that your tests cover all possible behaviors of your code.
  - 9y ago

Manishearth 9y ago

> wouldn't it be possible for SAFE Rust code to be faster than C code considering that the Rust compiler has much more syntax to play around and optimize? Yes. Rust has TONS of aliasing info that optimizers essentially spend a lot of time recovering in other programs. However, LLVM doesn't support being told about all of it, and doesn't make use of it that much directly (we can at best tell LLVM that a whole bunch of things are `restrict`). In fact, we had to stop doing this for `&mut` because LLVM had too many bugs around that. C/C++ codebases don't benefit from this as much so LLVM doesn't prioritize this. Rust can do optimizations at the MIR level and I'm hoping we'll do more in that space in the future.

vvanders 9y ago
That's pretty depressing, restrict is killer when you really want to eek out performance and I've had an intuition that Rust had all the relevant info to automatically use it.
- inimino 9y ago
  eke out
- bjz_ 9y ago
  I dunno, it's actually exciting imo. Means we've got more speed to see yet from Rust! :)
- kibwen 9y ago
  Rust does have the information to, but it has so much information that LLVM doesn't yet know what to do with it all. :P