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

Popular posts from this blog

jOOQ update returning clause with Oracle -

java - Warning equals/hashCode on @Data annotation lombok with inheritance -

java - BasicPathUsageException: Cannot join to attribute of basic type -