Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I thought Rust left the optimization to LLVM. Is that not the case?


LLVM is great, and it's the reason why Rust is able to match C++ in performance on this workload, but it's not a magic-optimizer-of-everything: it's tuned to C and C++. We have added a couple of Rust-specific optimizations to it, but not a whole lot.

I suspect what the author was seeing was random performance differentials between iterators and loops, which often boils down to little missed optimizations in LLVM. If you find them, please file them in the Rust bug tracker--we've fixed many of them and will continue to do so in the future!

Note that when MIR lands, progress on which is well underway, we'll have the ability to do optimizations at the Rust IR level in addition to the LLVM level. This should make it easier to do these kinds of things.


Figured this might be the case. LLVM is great but C++ compilers have had a long time to mature.

It's impressive that the filter and map methods produced such good performance. The lazy evaluation scheme must be well setup, shout out to the Rust team!

Are the lazy iterators are combined and effectively stripped out at compile time?


Yes.


As I understand it, there are a number of potential optimizations based on Rust's implicit understanding of the lifetime of a memory region. LLVM doesn't know about those because they can't be represented in the IR. Last I heard, any kind of optimization work based on the extra information rustc has is waiting for the compiler refactor that's currently underway.


Note that there aren't any optimizations that C++ can do that Rust can't in this area.


Can Rust's aliasing rules lead to extra avenues of optimization compared C++ (along the lines of C vs. Fortran)?


Quite possibly yes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: