I feel pretty good about it. For one, we have significantly better aliasing information than C++, and we use most of the guts, including all the optimizations and code generation, of a C++ compiler (clang/LLVM). There are also some optimizations around move semantics that are open to us but not for C++ as standardized.
That said, there are definitely performance bugs that have yet to be fixed. But I would definitely say most Rust code, if well-written, can be competitive with C++ today.
Aligning memory is pretty important for high-performance apps using SSE/AVX (archs after SB don't need alignment any more, but still benefit from it) - and generally anyway - cacheline alignement, etc, and while it's often possible to force structs / classes to be aligned by padding them, this doesn't always work.
Does Rust allow using memory allocated by specific external allocators? i.e. libnuma or something?
> Aligning memory is pretty important for high-performance apps using SSE/AVX
Er… yes? Did I say it was unimportant anywhere? (also please note that I'm not a Rust developer)
> Does Rust allow using memory allocated by specific external allocators? i.e. libnuma or something?
I'm not quite sure what you're asking
* if you're asking if it's possible to use arbitrary memory returned by a third party? Then yes.
* if you're asking whether user-defined allocators or boxes are supported and you can ask the runtime to put its stuff in memory you get from e.g. a bundled jemalloc, then that's planned but not in I believe: https://github.com/mozilla/rust/issues/12038
No, but that link seemed to indicate it wasn't being planned for the first release and pcwalton seems to think it's possible to get Rust programs to run as fast as C++ programs in most cases.
It can easily be added backward-compatibly, so could appear in, e.g., a 1.1 release. Or... someone who really wants it scratches their itch and gets it implemented. :)
(The speed of a language isn't determined by the speed of it's "first release".)
I would imagine that "most cases" don't require this kind of alignment, because most cases don't involve vector instructions.
There is certainly a set of performance-critical problems where making optimal use of vector instructions is essential. It does seem that Rust is unlikely to be competitive for those today. But i think it's a minority of all problems.
https://github.com/mozilla/rust/issues/5016 is the main optimization (and we have more discussed but not written up). Since we have a very strict notion of liveness, we don't have to zero out moved data since the compiler can just not run the destructor.
That said, there are definitely performance bugs that have yet to be fixed. But I would definitely say most Rust code, if well-written, can be competitive with C++ today.