4 ms·
In PyTorch `x = y + x` is actually semantically different from `x += y`, so you can't easily make the switch with a compiler. The difference is that `x += y` m
by thomasahle 4y ago
In PyTorch `x = y + x` is actually semantically different from `x += y`, so you can't easily make the switch with a compiler.
The difference is that `x += y` modifies `x` inplace, where `x = x + y` creates a new object. In other words, if anybody had a reference to `x` before the update, the "optimized" code would break things.
- WirelessGigabit 4y agoCompiler could use a pointer to pointer. I guess this is the kind of this stuff that drew me to Rust. This kind of behavior gives me the creeps. Just like Ruby’s conventions.
- fragmede 4y agoRust has the same behavior. https://news.ycombinator.com/item?id=32805756 https://news.ycombinator.com/item?id=32805756
- codeflo 4y agoNot to turn this into an evangelism subthread, but I think GP is right. The performance optimization could apply, but the bug as described should be prevented by the borrow checker. In fact you can do neither x = … nor x += … when anything else still references x, because assignment requires an exclusive reference (&mut), which is statistically checked.
- _flux 4y agoI'm not sure what you mean by "same behavior". I don't think you can externally distinguish between "x = x + x" and "x += x" in Rust, because while in the first case a new temporary value will be created, it will overwrite the left side value: x will be the "same object" as it's in the same address in both cases. In Python objects are stored indirectly, so after an assignment x will then point to a new object instead of the old one. But yes, not making copies is more efficient so the same optimization applies. Nevertheless, in Rust (or C++) the parameter x would not have been passed as a mutable reference into the function, so the value provided as input would not have been mutated.