5 ms·

Note: Rust is designed to be as efficient as C++. Well, sort of, since we don't have all of the optimizations yet (we use llvm so we get most of them for free)

Note: Rust is designed to be as efficient as C++. Well, sort of, since we don't have all of the optimizations yet (we use llvm so we get most of them for free) But Minecraft itself is in Java. And it does get pretty slow even with low settings as compared to other games on high settings.

mrob 12y ago
Rust uses bounds checking in safe code, and despite idiomatic Rust allowing many bounds checks to be optimized out (eg. iterators instead of C style for loops), bounds checks are not free. It's possible that things like stricter aliasing rules in Rust will allow more optimizations and make up the speed difference, but the design of Rust does not guarantee the possibility of matching C++ performance unless you use unsafe code.
- steveklabnik 12y ago
  > Rust does not guarantee the possibility of matching C++ performance unless you use unsafe code. As with any performance question, this is hard to actually say in general. In the Benchmarks game(1), there are several benchmarks where Rust has no unsafe code and is still faster than C. 1: personal note: ugh, all usual caveats apply, etc.
  - igouy 12y ago
    If you think there's something wrong about the benchmarks game then don't point to the benchmarks game as evidence for what you wish to be true.
- saidajigumi 12y ago
  At some point the performance margin grows so close that it's irrelevant to almost any application. IMO, it's already there for a broad swath of application classes. For those inner-most-loop, optimizer-has-failed-me cases, Rust can still fall back on unsafe code. I'll note that this kind of skepticism has been going on since John Backus[1] was heckled over using (ahem, "wasting") then-precious CPU time on compiling code using the first versions of FORTRAN. His detractors (and everyone else) quickly learned the value of conserving programmer time vs. CPU time. [1] https://en.wikipedia.org/wiki/John_Backus https://en.wikipedia.org/wiki/John_Backus
  - Guvante 12y ago
    Games are one of the areas where it is a bit foggier as your rendering loop is incredibly sensitive to performance problems. You have a ton of work to do and cannot take more than 16.7ms (60Hz) to do it in period. Heck given the recent move some have made for 144Hz monitors it leaves you with less than half the time (6.9ms). Not to say that C++ is the only way to pull it off, just that games are a soft-real-time system which therefore have stricter requirements for performance.
    - pcwalton 12y ago
      Most inner loops in game code are iterating over collections, whether it be lists of actors, lists of vertices, skeletal animation data, or what have you. Rust does not incur bounds check overhead for iteration.
- dbaupp 12y ago
  On the other hand, you have no choice but to use unsafe code in C++; that is, there's no line between code that is guaranteed to be memory safe and code that risks corruption and undefined behaviour. In any case, the route people will hopefully take is to write the code in the obvious way, with bounds checks and all, and profile. Functions which take significant amounts of time can then be optimised more manually (and, bounds checks usually aren't the bottleneck).
- pcwalton 12y ago
  In my experience not being able to use iterators is rare in most Rust code. Inner loops that have array lookups are overwhelmingly iterating over collections. It's much more common to have to drop down to unsafe code because you need to implement some low-level data structure that Rust's ownership rules can't yet prove safe. I have personally never seen the bounds checks be a problem except in microbenchmark-like things, and those are almost always compiler bugs involving missed optimizations that the compiler could have done but does not presently. I think "the design of Rust does not guarantee the possibility of matching C++ performance unless you use unsafe code" is too strong a statement.
- geofft 12y ago
  Bounds checks are obviously not free in theory, but I've heard multiple stories of people who did the measurements on their codebase, and concluded that the cost was so tiny as to be statistically unmeasurable, compared to other noise in run-time measurements. Here's one: https://www.reddit.com/r/rust/comments/2nlis8/which_classes_of_errors_remain_with_rust/cmeqh47?context=2 https://www.reddit.com/r/rust/comments/2nlis8/which_classes_...
SamReidHughes 12y ago
It's not just a matter of optimizations, there are some things you can do in C++ that incur extra pointer indirections in Rust because you don't have move constructors.
- kibwen 12y ago
  Can you give an example?
  - SamReidHughes 12y ago
    Any time you would have backpointers that need to get updated when the pointee object moves. One example would be a pair of noncopyable promise send/receive objects, each with a pointer to the other. Or just one end could be copyable. Or take green threads single-core mutexes and their acquirers. The acquirers should be able to be moved around without getting "lost".

mrob 12y ago

Rust uses bounds checking in safe code, and despite idiomatic Rust allowing many bounds checks to be optimized out (eg. iterators instead of C style for loops), bounds checks are not free. It's possible that things like stricter aliasing rules in Rust will allow more optimizations and make up the speed difference, but the design of Rust does not guarantee the possibility of matching C++ performance unless you use unsafe code.

steveklabnik 12y ago
> Rust does not guarantee the possibility of matching C++ performance unless you use unsafe code. As with any performance question, this is hard to actually say in general. In the Benchmarks game(1), there are several benchmarks where Rust has no unsafe code and is still faster than C. 1: personal note: ugh, all usual caveats apply, etc.
- igouy 12y ago
  If you think there's something wrong about the benchmarks game then don't point to the benchmarks game as evidence for what you wish to be true.
saidajigumi 12y ago
At some point the performance margin grows so close that it's irrelevant to almost any application. IMO, it's already there for a broad swath of application classes. For those inner-most-loop, optimizer-has-failed-me cases, Rust can still fall back on unsafe code. I'll note that this kind of skepticism has been going on since John Backus[1] was heckled over using (ahem, "wasting") then-precious CPU time on compiling code using the first versions of FORTRAN. His detractors (and everyone else) quickly learned the value of conserving programmer time vs. CPU time. [1] https://en.wikipedia.org/wiki/John_Backus https://en.wikipedia.org/wiki/John_Backus
- Guvante 12y ago
  Games are one of the areas where it is a bit foggier as your rendering loop is incredibly sensitive to performance problems. You have a ton of work to do and cannot take more than 16.7ms (60Hz) to do it in period. Heck given the recent move some have made for 144Hz monitors it leaves you with less than half the time (6.9ms). Not to say that C++ is the only way to pull it off, just that games are a soft-real-time system which therefore have stricter requirements for performance.
  - pcwalton 12y ago
    Most inner loops in game code are iterating over collections, whether it be lists of actors, lists of vertices, skeletal animation data, or what have you. Rust does not incur bounds check overhead for iteration.
dbaupp 12y ago
On the other hand, you have no choice but to use unsafe code in C++; that is, there's no line between code that is guaranteed to be memory safe and code that risks corruption and undefined behaviour. In any case, the route people will hopefully take is to write the code in the obvious way, with bounds checks and all, and profile. Functions which take significant amounts of time can then be optimised more manually (and, bounds checks usually aren't the bottleneck).
pcwalton 12y ago
In my experience not being able to use iterators is rare in most Rust code. Inner loops that have array lookups are overwhelmingly iterating over collections. It's much more common to have to drop down to unsafe code because you need to implement some low-level data structure that Rust's ownership rules can't yet prove safe. I have personally never seen the bounds checks be a problem except in microbenchmark-like things, and those are almost always compiler bugs involving missed optimizations that the compiler could have done but does not presently. I think "the design of Rust does not guarantee the possibility of matching C++ performance unless you use unsafe code" is too strong a statement.
geofft 12y ago
Bounds checks are obviously not free in theory, but I've heard multiple stories of people who did the measurements on their codebase, and concluded that the cost was so tiny as to be statistically unmeasurable, compared to other noise in run-time measurements. Here's one: https://www.reddit.com/r/rust/comments/2nlis8/which_classes_of_errors_remain_with_rust/cmeqh47?context=2 https://www.reddit.com/r/rust/comments/2nlis8/which_classes_...

SamReidHughes 12y ago

It's not just a matter of optimizations, there are some things you can do in C++ that incur extra pointer indirections in Rust because you don't have move constructors.

kibwen 12y ago
Can you give an example?
- SamReidHughes 12y ago
  Any time you would have backpointers that need to get updated when the pointee object moves. One example would be a pair of noncopyable promise send/receive objects, each with a pointer to the other. Or just one end could be copyable. Or take green threads single-core mutexes and their acquirers. The acquirers should be able to be moved around without getting "lost".