4 ms·

Do you have any examples where unoptimized rust is in the ballpark of interpreted Python? That seems extremely slow even for carelessly written code.

deleted 5y ago
[deleted]
kibwen 5y ago
I've been teaching people to use Rust since 2011. It is quite common for someone coming from an interpreted language background to not realize that they have to manually ask for optimizations when building their code. In such circumstances they often come asking for help saying "I must be doing something wrong, I rewrote this Python code in Rust and it appears to be slower somehow?" For a long time on the /r/rust sidebar we even had a note saying "before asking for help, have you tried compiling with --release?" And indeed, once they turn on optimizations their code goes from as slow as Python to as fast as C. The OP's case is completely representative; a 14x improvement merely by compiling in release mode is entirely in line with what I have observed. This may be surprising to people coming from C or C++, where unoptimized code is slower but not that slow. But the point of Rust is that it's selectively provided as many zero-cost abstractions as it can, which when paired with a modern sufficiently-smart backend like LLVM boils away those abstractions into nothing. It's a great feeling the first time that you crack open the assembly output for a highly abstract chain of iterator/closure chains only to find that the whole shebang has been reduced to a handful of fixed-form arithmetic operations without a loop or a function call in sight. But the tradeoff is that you do have to perform the step of boiling those abstractions away.
- pjmlp 5y ago
  This is not new problem actually, when IBM did their PL.8 research compiler for RISC, and safe systems programming, they took exactly the same approach as Rust, just in 1982. Quite interesting paper, in case you haven't read it, "An Overview of the PL.8 Compiler" https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.453.5277&rank=4&q=an%20overview%20of%20pl.8%20compiler&osm=&ossid= https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.453... Unfortunately despite its internal success they decided to go with Aix for RISC.
- dralley 5y ago
  I like Rust a lot but this is a big frustration with it. I have a hard time seriously imagining Rust taking off in game development when debug code is so bad, at least without some style guidelines that avoid the worst problems with it. I'm glad Zig is providing some competition here that's more in line with what one would expect from C.
  - kibwen 5y ago
    One promising avenue of Rust development is that, while --release implies -O2 and --debug (the default) implies -O0, the -O1 case hasn't received a lot of attention. In the future it seems like the contexts you mention would benefit from such a sweet spot.
  - ReactiveJelly 5y ago
    There is also a trick to compile your own program without optimizations, but optimize all dependencies. I too had the "Un-optimized Rust code is slow!" experience when I started out, because my first project required PNG encoding and decoding, and the png crate was incredibly slow without optimizations. But it's typical for C and C++ to be un-optimized at the level of `main`, but calling into heavily-optimized system libraries like ffmpeg.
- Someone 5y ago
  I don’t think there are C compilers out there that do not optimize at all. AFAIK, all of them will do some register assignment, some constant folding, etc. For example, if you write void f(int a) { int b = a; b = b + b; g(b); } are there compilers out there that compile that to - load a - store into b - load b - load b into another register - add - store into b - load b - call g - return ? Languages that do overflow and range checks such as Julia and Rust in debug mode would have to add lots of them there if they do not do any optimization.
dralley 5y ago
One of the early advent of code challenges triggered this situation for many people (including myself). The same program compiled in release mode was more than 4000x faster than debug mode. https://media.discordapp.net/attachments/386246790565068811/917659835854643220/Screenshot_from_2021-12-07_01-06-51.png https://media.discordapp.net/attachments/386246790565068811/... Although it's worth mentioning that LLVM understands math and might be replacing an inefficient sum calculation with an efficient algorithm, so it might not be all down to codegen.

deleted 5y ago

[deleted]

kibwen 5y ago

I've been teaching people to use Rust since 2011. It is quite common for someone coming from an interpreted language background to not realize that they have to manually ask for optimizations when building their code. In such circumstances they often come asking for help saying "I must be doing something wrong, I rewrote this Python code in Rust and it appears to be slower somehow?" For a long time on the /r/rust sidebar we even had a note saying "before asking for help, have you tried compiling with --release?" And indeed, once they turn on optimizations their code goes from as slow as Python to as fast as C. The OP's case is completely representative; a 14x improvement merely by compiling in release mode is entirely in line with what I have observed. This may be surprising to people coming from C or C++, where unoptimized code is slower but not that slow. But the point of Rust is that it's selectively provided as many zero-cost abstractions as it can, which when paired with a modern sufficiently-smart backend like LLVM boils away those abstractions into nothing. It's a great feeling the first time that you crack open the assembly output for a highly abstract chain of iterator/closure chains only to find that the whole shebang has been reduced to a handful of fixed-form arithmetic operations without a loop or a function call in sight. But the tradeoff is that you do have to perform the step of boiling those abstractions away.

pjmlp 5y ago
This is not new problem actually, when IBM did their PL.8 research compiler for RISC, and safe systems programming, they took exactly the same approach as Rust, just in 1982. Quite interesting paper, in case you haven't read it, "An Overview of the PL.8 Compiler" https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.453.5277&rank=4&q=an%20overview%20of%20pl.8%20compiler&osm=&ossid= https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.453... Unfortunately despite its internal success they decided to go with Aix for RISC.
dralley 5y ago
I like Rust a lot but this is a big frustration with it. I have a hard time seriously imagining Rust taking off in game development when debug code is so bad, at least without some style guidelines that avoid the worst problems with it. I'm glad Zig is providing some competition here that's more in line with what one would expect from C.
- kibwen 5y ago
  One promising avenue of Rust development is that, while --release implies -O2 and --debug (the default) implies -O0, the -O1 case hasn't received a lot of attention. In the future it seems like the contexts you mention would benefit from such a sweet spot.
- ReactiveJelly 5y ago
  There is also a trick to compile your own program without optimizations, but optimize all dependencies. I too had the "Un-optimized Rust code is slow!" experience when I started out, because my first project required PNG encoding and decoding, and the png crate was incredibly slow without optimizations. But it's typical for C and C++ to be un-optimized at the level of `main`, but calling into heavily-optimized system libraries like ffmpeg.
Someone 5y ago
I don’t think there are C compilers out there that do not optimize at all. AFAIK, all of them will do some register assignment, some constant folding, etc. For example, if you write void f(int a) { int b = a; b = b + b; g(b); } are there compilers out there that compile that to - load a - store into b - load b - load b into another register - add - store into b - load b - call g - return ? Languages that do overflow and range checks such as Julia and Rust in debug mode would have to add lots of them there if they do not do any optimization.

dralley 5y ago

One of the early advent of code challenges triggered this situation for many people (including myself). The same program compiled in release mode was more than 4000x faster than debug mode. https://media.discordapp.net/attachments/386246790565068811/917659835854643220/Screenshot_from_2021-12-07_01-06-51.png https://media.discordapp.net/attachments/386246790565068811/... Although it's worth mentioning that LLVM understands math and might be replacing an inefficient sum calculation with an efficient algorithm, so it might not be all down to codegen.