digitalmars.D - On Efficient Concurrency, Sharing, Move Semantics in Rust vs D
- =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (13/13) Apr 20 2014 The following solution
- =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (9/14) Apr 20 2014 I just realized that solving this in an elegant way (for
- =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (5/9) May 13 2014 I'm surprised that nobody has answered this discussion...
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (12/21) May 13 2014 In general, anything that involves optimization must by
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
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
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!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
May 13 2014
On Tuesday, 13 May 2014 at 11:04:18 UTC, Nordlöw wrote: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.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!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
May 13 2014