Can Rust optimise away the bit-wise copy during move of an object someday? -
consider snippet
struct foo { dummy: [u8; 65536], } fn bar(foo: foo) { println!("{:p}", &foo) } fn main() { let o = foo { dummy: [42u8; 65536] }; println!("{:p}", &o); bar(o); }
a typical result of program is
0x7fffc1239890 0x7fffc1229890
where addresses different.
apparently, large array dummy
has been copied, expected in compiler's move implementation. unfortunately, can have non-trivial performance impact, dummy
large array. impact can force people choose passing argument reference instead, when function "consumes" argument conceptually.
since foo
not derive copy
, object o
moved. since rust forbids access of moved object, preventing bar
"reuse" original object o
, forcing compiler generate potentially expensive bit-wise copy? there fundamental difficulty, or see compiler someday optimise away bit-wise copy?
given in rust (unlike c or c++) address of value not considered matter, there nothing in terms of language prevents elision of copy.
however, today rustc not optimize anything: optimizations delegated llvm, , seems have hit limitation of llvm optimizer here (it's unclear whether limitation due llvm being close c's semantics or omission).
so, there 2 avenues of improving code generation this:
- teaching llvm perform optimization (if possible)
- teaching rustc perform optimization (optimization passes coming rustc has mir)
but might want avoid such large objects being allocated on stack, can box
example.
Comments
Post a Comment