www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - On Efficient Concurrency, Sharing, Move Semantics in Rust vs D

reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
The following solution

http://static.rust-lang.org/doc/master/intro.html#owning-concurrency

is partially a good start...

but I believe it would be better to let the (D) compiler 
optimization stage figure out _automatically_ if it needs to make 
a copy of the variable `numbers` or not depending on whether 
`numbers` is used or not further down the body of `main`.

Are there currently any semantic passes in DMD that checks where 
reference data are read/written that could be utilized here?

Also Walter has talked about loads of data flow optimizations 
pending in DMD that for example automatically make new 
expressions immutable (and in turn shareable without locks) when 
possible.
Apr 20 2014
next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 but I believe it would be better to let the (D) compiler 
 optimization stage figure out _automatically_ if it needs to 
 make a copy of the variable `numbers` or not depending on 
 whether `numbers` is used or not further down the body of 
 `main`.

I just realized that solving this in an elegant way (for reference types) would require some kind of new builtin property, say, r.isUnique The compiler could, when possible, do this check at compile-time, and avoid any run-time (GC) or reference counting overheads done in isUnique. I just found that this is highly related: http://wiki.dlang.org/DIP29
Apr 20 2014
prev sibling next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 but I believe it would be better to let the (D) compiler 
 optimization stage figure out _automatically_ if it needs to 
 make a copy of the variable `numbers` or not depending on 
 whether `numbers` is used or not further down the body of


I'm surprised that nobody has answered this discussion... Isn't this an important question/possibility now that we soon have inference of uniqueness/immutability in DMD from Walters work? Ping!
May 13 2014
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 13 May 2014 at 11:04:18 UTC, Nordlöw wrote:
 but I believe it would be better to let the (D) compiler 
 optimization stage figure out _automatically_ if it needs to 
 make a copy of the variable `numbers` or not depending on 
 whether `numbers` is used or not further down the body of


I'm surprised that nobody has answered this discussion... Isn't this an important question/possibility now that we soon have inference of uniqueness/immutability in DMD from Walters work? Ping!

In general, anything that involves optimization must by definition not change program behavior. Copying vs. not copying usually has visible consequences, and therefore cannot be decided by the optimizer. Furthermore, I think it is too fragile to (silently) base a decision about copying on what happens further down the program. You could too easily change something by accident. The uniqueness changes in DMD are different, although I believe they are not yet properly documented. Uniqueness is only decided from the the expression that produced the value, but not from what further happens with the value.
May 13 2014