4 ms·

Fully agree. I have heard claims that Rust would be performance-equivalent so many times and each time I bothered to check it turned out to be wrong. Especiall

Fully agree. I have heard claims that Rust would be performance-equivalent so many times and each time I bothered to check it turned out to be wrong. Especially in video game AI, indirection, pointers and linked lists are common. They are usually used in the performance-critical input-to-frame part of the game and there fitting things nicely into CPU cache lines is crucial for performance. The end result is that I now have this vague feeling that Rust is a religious cult and I shouldn't take their claims at face value.

api 5y ago
C++ is better for performance because it’s old and tremendous effort has been put into optimizing it. Rust is a very young language. It benefits from the clang tool chain and gets some of that optimization for free, but there is a lot of room to make Rust faster. Unlike GC’d or dynamic languages, there is nothing intrinsic about Rust that makes it a fundamentally harder language to optimize. It’s really like a modern provably safe C++. It also depends on how you code. If you make heavy use of functional constructs and complex types your Rust code will probably not end up being optimized as well. For tight algorithms it’s good to write “thin” Rust. The exact same is true for C++. You would not want to use a lot of STL or functional stuff in a rendering pipeline core. High performance C++ looks like C.
- gpderetta 5y ago
  Which optimizations is the rust compiler missing? A lot of the optimizations required for fast code, like manual layout of custom datastructures are done by the programmers, not by the compiler. I don't doubt that rust can also express this optimizations given the similar low level control provided by the language, but what the OP and the parent are saying is that some of these are not idiomatic in rust and harder or impossible to express in the safe subset of the language. > You would not want to use a lot of STL or functional stuff in a rendering pipeline core. High performance C++ looks like C. FWIW that's not at all my experience.
  - BenFrantzDale 5y ago
    Agreed. My favorite example of C++ vs C performance is C++’s `std::sort` which is intrinsically faster than anything similar in C because C lacks the language features (templates) to support performant code reuse like that.
  - volta83 5y ago
    TBH, while I can think of many layout optimizations that Rust does and C does not, I can't think of any that C or C++ do that Rust does not. In particular when it comes to unions which are heavily used in low-level code, Rust does optimizations that C and C++ can't even dream of (like all the niche optimizations).
    - gpderetta 5y ago
      which optimizations on unions does rust do?
      - volta83 5y ago
        In C++, you have `std::optional<T>`. That's a type that either contains a `T` or contains nothing. In C++, sizeof(optional<T>) > sizeof(T) because the discriminat has to be stored somewhere. This is true even if, e.g., you do something like `optional<T&>`. You know that T& is a non-null pointer, and you only have two variants, and one of the variants has no state, so you technically can encode this as 0x0 is the "no reference" variant, and the != 0x0 is the reference variant, and have `optional<T&>` have the same size as `T&`. Rust does these layout optimizations of compressing the discriminant into gaps in the values of discriminated unions automatically. So: enum Option<T> { Some(T), None } for `Option<T&>` has the same size as `T&` in Rust, as opposed to C++. In C, an example would be: struct DU { enum { A, B } discriminant; union { bool A; bool B; } }; You could encode that into 3 bits (i.e. have sizeof(DU) == 1), but instead you'll have at least sizeof(DU) == 2, because you need one byte for the discriminant, and one byte for the payload. It is very easy to create values with gaps in Rust, but C doesn't really support doing this. Another optimization are alignment optimizations. In C, if you write: struct S { uint8_t a; uint32_t b; uint8_t c; }; that ends up being 12 bytes long. In Rust, by default, that gets reordered as uint32_t, uint8_t, uint8_t, so it only ends up being 8 bytes. If you want that instead to be laid out like in C, you can write: #[repr(C)] struct S { a: u8, b: u32, c: u8 } and then you get the same 12 bytes as in C. There are many supported `repr(...)` options supported for algebraic data types, e.g., you can use repr(u32) for the Rust enum above to store the discriminant in a u32, and get the same layout as DU in C.
- osigurdson 5y ago
  Rust uses LLVM so optimizations occur at the AST level. Therefore it should be able to take advantage of the same optimizations as Clang C++ which uses the same approach.
  - steveklabnik 5y ago
    They happen at a lower level than an AST, but you're right that any front end can in theory generate the same IR and therefore get the same optimizations. The trick is if the language semantics allow for it; this bites both ways.
- nuerow 5y ago
  > Rust is a very young language. It benefits from the clang tool chain and gets some of that optimization for free, but there is a lot of room to make Rust faster. I feel that this sort of belief relies too heavily on a presumption that performance is somehow proportional to the age of a programming language, and in the process ignores the fact that a) it's already using a highly optimized toolchain that benefits from decades of research and development, and b) there is absolutely no suggestion that any potential performance gains are relevant or exclusive to the Rust's front-end.
  - api 5y ago
    There is always a long tail of optimizations and tweaks that must be done to get a language that last 5% of the way to parity with a language like C. Building on LLVM gets them 95% of the way. BTW Rust has some features that make optimization a lot easier, like the ability to assume strict aliasing in more cases. It’s safety features also make it easier to write zero copy, copy on write, and other optimization patterns without making mistakes. This enables some bold performance optimizations at the code level that would require serious bravery in C. Long term I expect that Rust will be faster in some cases.
pca006132 5y ago
You can also align data to cache lines if you want to in Rust, without unsafe [1]. It is not C/C++ specific. For linked list, you can use an unsafe implementation if that is performance critical. Unsafe implementation can be wrapped in a safe API for others to use, and this is how the standard library is implemented. There is also a new paper about structures with internal sharing such as graphs without runtime overhead that Rc/RefCell would cause [2]. [1]: https://doc.rust-lang.org/reference/type-layout.html#the-c-representation https://doc.rust-lang.org/reference/type-layout.html#the-c-r... [2]: http://plv.mpi-sws.org/rustbelt/ghostcell/ http://plv.mpi-sws.org/rustbelt/ghostcell/
tasogare 5y ago
> I now have this vague feeling that Rust is a religious cult I had this feeling from the very beginning just by the tone of its zealots here and elsewhere. My theory is that since the language is very hard to learn but doesn't provide a lot of tangible benefits (memory safety exists in most mainstream languages fot decades), the sunk cost fallacy hits very hard. Then the only way to get some benefits for the time spent is to recruit new comers in a sort of pyramidal scheme structured around experience in the language. This way the zealots become priests and are compensated in form of social status. Of course, the whole scheme cramble if nobody joins, which is why the community is so aggressive (RIIR, vocal advocating, etc.) with the non-believers.
- sanderjd 5y ago
  People like rust for a lot of different reasons; that is, different people see different tangible benefits to it, and that has resulted in both a large and fast growing community of people who like it, and (predictably) backlash to that. On the side of people coming from other memory safe languages, the benefit is much like Go, which has also become very widely used very quickly, so it seems worth taking seriously that the existing memory safe languages were maybe not satisfying people in some way. I think the popularity of both languages in this space can be boiled down to lowering the amount of abstraction without giving up memory safety, and simplifying the toolchain. Both Go and Rust do both of those things (in my view). I prefer rust because I don't like how the Go type system requires so much repetition of implementation due to lacking generics, but both languages make some amount of sense in this niche IMO. Other people like rust because they came from C or C++ and got tired of some of their weaknesses but did not want to give up many of their strengths. Of course whether rust requires giving up the strengths of this languages is debatable and this where most of the backlash comes from. But rust is one of a very very few languages (maybe also D and Zig?) that can plausibly make this claim at all, and I think is has become the most actively developed and attracted the largest community of those, which does matter. For me, it's a huge advantage to be able to plausibly use the same language for everything, from kernel drivers to giant applications. The only real competitor in that space is C++, and I think its cracks show more on both extremes, that is, I think rust is both a better C replacement at the very low end (see people like Linus Torvalds and Bryan Cantrill who are C diehards who dislike C++ but are interested or all in on rust) and is much better at the high level because of easy memory safety. So I dunno, maybe there's a cult, but there are also very straightforward reasons why a lot of people are attracted to the language.
geodel 5y ago
> I now have this vague feeling that Rust is a religious cult I'd say even if many of technical claims about Rust are true. It still seems very much like a cult.
volta83 5y ago
I've also heard your claim many times, and every time I checked, replacing a doubly-linked list with something else improved performance by orders of magnitude. Particularly in video games. --- > The end result is that I now have this vague feeling that Rust is a religious cult and I shouldn't take their claims at face value. Also, you realize that Rust allows writing efficient doubly-linked lists right ? And that the Rust standard library provides one for you right? The whole argument of the OP is that people learning programming need to start doing so by learning how to write doubly linked lists because performance trumps all and therefore all children, elderly, and even university students that learn programming with javascript are lesser human beings and don't deserve our respect.
- platinumrad 5y ago
  The linked list provided by the standard library is unfortunately not very useful. It doesn't provide O(1) operations on the middle of the list, making it more or less a worse VecDeque. Of course there are crates that provide better implementations but people really need to stop pointing people toward the one in std.
lenkite 5y ago
The lack of goto also bars it from the domain of very fast interpreters. Computed gotos are a common technique used in C/C++ interpreters which aren't possible in Rust.
- quotemstr 5y ago
  To be fair, the last time I checked, LLVM was doing an okay job of generating jump tables from big switches and threading the cases for best jump target prediction --- same thing you'd do with computed goto. But yes, lack of goto and computed goto are deficiencies, not strengths.

api 5y ago

C++ is better for performance because it’s old and tremendous effort has been put into optimizing it. Rust is a very young language. It benefits from the clang tool chain and gets some of that optimization for free, but there is a lot of room to make Rust faster. Unlike GC’d or dynamic languages, there is nothing intrinsic about Rust that makes it a fundamentally harder language to optimize. It’s really like a modern provably safe C++. It also depends on how you code. If you make heavy use of functional constructs and complex types your Rust code will probably not end up being optimized as well. For tight algorithms it’s good to write “thin” Rust. The exact same is true for C++. You would not want to use a lot of STL or functional stuff in a rendering pipeline core. High performance C++ looks like C.

gpderetta 5y ago
Which optimizations is the rust compiler missing? A lot of the optimizations required for fast code, like manual layout of custom datastructures are done by the programmers, not by the compiler. I don't doubt that rust can also express this optimizations given the similar low level control provided by the language, but what the OP and the parent are saying is that some of these are not idiomatic in rust and harder or impossible to express in the safe subset of the language. > You would not want to use a lot of STL or functional stuff in a rendering pipeline core. High performance C++ looks like C. FWIW that's not at all my experience.
- BenFrantzDale 5y ago
  Agreed. My favorite example of C++ vs C performance is C++’s `std::sort` which is intrinsically faster than anything similar in C because C lacks the language features (templates) to support performant code reuse like that.
- volta83 5y ago
  TBH, while I can think of many layout optimizations that Rust does and C does not, I can't think of any that C or C++ do that Rust does not. In particular when it comes to unions which are heavily used in low-level code, Rust does optimizations that C and C++ can't even dream of (like all the niche optimizations).
  - gpderetta 5y ago
    which optimizations on unions does rust do?
    - volta83 5y ago
      In C++, you have `std::optional<T>`. That's a type that either contains a `T` or contains nothing. In C++, sizeof(optional<T>) > sizeof(T) because the discriminat has to be stored somewhere. This is true even if, e.g., you do something like `optional<T&>`. You know that T& is a non-null pointer, and you only have two variants, and one of the variants has no state, so you technically can encode this as 0x0 is the "no reference" variant, and the != 0x0 is the reference variant, and have `optional<T&>` have the same size as `T&`. Rust does these layout optimizations of compressing the discriminant into gaps in the values of discriminated unions automatically. So: enum Option<T> { Some(T), None } for `Option<T&>` has the same size as `T&` in Rust, as opposed to C++. In C, an example would be: struct DU { enum { A, B } discriminant; union { bool A; bool B; } }; You could encode that into 3 bits (i.e. have sizeof(DU) == 1), but instead you'll have at least sizeof(DU) == 2, because you need one byte for the discriminant, and one byte for the payload. It is very easy to create values with gaps in Rust, but C doesn't really support doing this. Another optimization are alignment optimizations. In C, if you write: struct S { uint8_t a; uint32_t b; uint8_t c; }; that ends up being 12 bytes long. In Rust, by default, that gets reordered as uint32_t, uint8_t, uint8_t, so it only ends up being 8 bytes. If you want that instead to be laid out like in C, you can write: #[repr(C)] struct S { a: u8, b: u32, c: u8 } and then you get the same 12 bytes as in C. There are many supported `repr(...)` options supported for algebraic data types, e.g., you can use repr(u32) for the Rust enum above to store the discriminant in a u32, and get the same layout as DU in C.
osigurdson 5y ago
Rust uses LLVM so optimizations occur at the AST level. Therefore it should be able to take advantage of the same optimizations as Clang C++ which uses the same approach.
- steveklabnik 5y ago
  They happen at a lower level than an AST, but you're right that any front end can in theory generate the same IR and therefore get the same optimizations. The trick is if the language semantics allow for it; this bites both ways.
nuerow 5y ago
> Rust is a very young language. It benefits from the clang tool chain and gets some of that optimization for free, but there is a lot of room to make Rust faster. I feel that this sort of belief relies too heavily on a presumption that performance is somehow proportional to the age of a programming language, and in the process ignores the fact that a) it's already using a highly optimized toolchain that benefits from decades of research and development, and b) there is absolutely no suggestion that any potential performance gains are relevant or exclusive to the Rust's front-end.
- api 5y ago
  There is always a long tail of optimizations and tweaks that must be done to get a language that last 5% of the way to parity with a language like C. Building on LLVM gets them 95% of the way. BTW Rust has some features that make optimization a lot easier, like the ability to assume strict aliasing in more cases. It’s safety features also make it easier to write zero copy, copy on write, and other optimization patterns without making mistakes. This enables some bold performance optimizations at the code level that would require serious bravery in C. Long term I expect that Rust will be faster in some cases.

pca006132 5y ago

You can also align data to cache lines if you want to in Rust, without unsafe [1]. It is not C/C++ specific. For linked list, you can use an unsafe implementation if that is performance critical. Unsafe implementation can be wrapped in a safe API for others to use, and this is how the standard library is implemented. There is also a new paper about structures with internal sharing such as graphs without runtime overhead that Rc/RefCell would cause [2]. [1]: https://doc.rust-lang.org/reference/type-layout.html#the-c-representation https://doc.rust-lang.org/reference/type-layout.html#the-c-r... [2]: http://plv.mpi-sws.org/rustbelt/ghostcell/ http://plv.mpi-sws.org/rustbelt/ghostcell/

tasogare 5y ago

> I now have this vague feeling that Rust is a religious cult I had this feeling from the very beginning just by the tone of its zealots here and elsewhere. My theory is that since the language is very hard to learn but doesn't provide a lot of tangible benefits (memory safety exists in most mainstream languages fot decades), the sunk cost fallacy hits very hard. Then the only way to get some benefits for the time spent is to recruit new comers in a sort of pyramidal scheme structured around experience in the language. This way the zealots become priests and are compensated in form of social status. Of course, the whole scheme cramble if nobody joins, which is why the community is so aggressive (RIIR, vocal advocating, etc.) with the non-believers.

sanderjd 5y ago
People like rust for a lot of different reasons; that is, different people see different tangible benefits to it, and that has resulted in both a large and fast growing community of people who like it, and (predictably) backlash to that. On the side of people coming from other memory safe languages, the benefit is much like Go, which has also become very widely used very quickly, so it seems worth taking seriously that the existing memory safe languages were maybe not satisfying people in some way. I think the popularity of both languages in this space can be boiled down to lowering the amount of abstraction without giving up memory safety, and simplifying the toolchain. Both Go and Rust do both of those things (in my view). I prefer rust because I don't like how the Go type system requires so much repetition of implementation due to lacking generics, but both languages make some amount of sense in this niche IMO. Other people like rust because they came from C or C++ and got tired of some of their weaknesses but did not want to give up many of their strengths. Of course whether rust requires giving up the strengths of this languages is debatable and this where most of the backlash comes from. But rust is one of a very very few languages (maybe also D and Zig?) that can plausibly make this claim at all, and I think is has become the most actively developed and attracted the largest community of those, which does matter. For me, it's a huge advantage to be able to plausibly use the same language for everything, from kernel drivers to giant applications. The only real competitor in that space is C++, and I think its cracks show more on both extremes, that is, I think rust is both a better C replacement at the very low end (see people like Linus Torvalds and Bryan Cantrill who are C diehards who dislike C++ but are interested or all in on rust) and is much better at the high level because of easy memory safety. So I dunno, maybe there's a cult, but there are also very straightforward reasons why a lot of people are attracted to the language.

geodel 5y ago

> I now have this vague feeling that Rust is a religious cult I'd say even if many of technical claims about Rust are true. It still seems very much like a cult.

volta83 5y ago

I've also heard your claim many times, and every time I checked, replacing a doubly-linked list with something else improved performance by orders of magnitude. Particularly in video games. --- > The end result is that I now have this vague feeling that Rust is a religious cult and I shouldn't take their claims at face value. Also, you realize that Rust allows writing efficient doubly-linked lists right ? And that the Rust standard library provides one for you right? The whole argument of the OP is that people learning programming need to start doing so by learning how to write doubly linked lists because performance trumps all and therefore all children, elderly, and even university students that learn programming with javascript are lesser human beings and don't deserve our respect.

platinumrad 5y ago
The linked list provided by the standard library is unfortunately not very useful. It doesn't provide O(1) operations on the middle of the list, making it more or less a worse VecDeque. Of course there are crates that provide better implementations but people really need to stop pointing people toward the one in std.

lenkite 5y ago

The lack of goto also bars it from the domain of very fast interpreters. Computed gotos are a common technique used in C/C++ interpreters which aren't possible in Rust.

quotemstr 5y ago
To be fair, the last time I checked, LLVM was doing an okay job of generating jump tables from big switches and threading the cases for best jump target prediction --- same thing you'd do with computed goto. But yes, lack of goto and computed goto are deficiencies, not strengths.