6 ms·

> Hmmm... that sounds like exposed provenance I hadn't heard of that before, cool. That sounds similar, yeah. (At a quick glance at least. I can't tell if it's

> Hmmm... that sounds like exposed provenance I hadn't heard of that before, cool. That sounds similar, yeah. (At a quick glance at least. I can't tell if it's exactly equivalent but it certainly seems close.) > I would assume that that would also lead to massive slowdowns in runtime performance. My responses are: 1. I am amused that the implication of this would be that Rust is slower than C/C++. 2. I would not assume such a thing purely on faith. It may be true, but there have been lots of poor specifications in the standards based on erroneous presumptions about the performance cost/benefit trade-offs that subsequently didn't hold. I won't even go into the ones that touch UB -- just look at the argument evaluation order that they finally caved on and made stricter from C++14 to C++17. I find the standards are overzealous w.r.t. optimization in a lot of cases, and it takes them a long time to admit that. 3. If that's actually true in this particular case, the correct solution to that would've been to provide an opt-in flag to break programs (think -ffast-math) rather than laying incorrectness as the foundation.

Lvl999Noob 2y ago
1. Rust has proper references with much stricter aliasing requirements. So no, it would be C that would slow down. Rust would still be able to take advantage of these optimisations. 2. In this case, I would say the effects are much more obvious. Just take the example in the article. The compiler cannot replace a pointer access with its value if there has been any other pointers access in between. The compiler also cannot reorder any statements with pointer accesses. They would basically behave as memory barriers (if I understand them correctly). That will cause slow downs in runtime (the compile time will speed up though). 3. Sure. Perhaps that is an option. I wouldn't call it a flag to "break program" though. Maybe a config file that tells the compiler which assumptions can be made (strict aliasing, associative floats, threading safe, etc). EDIT: In point 3, I would also add assumptions like whether the code can be changed at runtime, etc (take a pointer to a function then write your own code there).
- dataflow 2y ago
  > In this case, I would say the effects are much more obvious. Just take the example in the article. The compiler cannot replace a pointer access with its value if there has been any other pointers access in between. I have no idea what you mean. The whole point of this discussion is that the example in the article should not be optimized in the manner they're describing, because it would be wrong. That is... a good thing. Not a bad thing. And the compiler certainly could replace a pointer access with its value if there has been other pointer access in between, as long as that pointer wasn't leaked away into some opaque place via an integer. > The compiler also cannot reorder any statements with pointer accesses. They would basically behave as memory barriers (if I understand them correctly). No, I don't think you understood what I'm saying. See above. It would still be perfectly legal for the compiler to transform char p[1] = {0}; opaque(); return p[0]; to opaque(); return 0; under what I wrote above, the intervening statement notwithstanding.

Lvl999Noob 2y ago

1. Rust has proper references with much stricter aliasing requirements. So no, it would be C that would slow down. Rust would still be able to take advantage of these optimisations. 2. In this case, I would say the effects are much more obvious. Just take the example in the article. The compiler cannot replace a pointer access with its value if there has been any other pointers access in between. The compiler also cannot reorder any statements with pointer accesses. They would basically behave as memory barriers (if I understand them correctly). That will cause slow downs in runtime (the compile time will speed up though). 3. Sure. Perhaps that is an option. I wouldn't call it a flag to "break program" though. Maybe a config file that tells the compiler which assumptions can be made (strict aliasing, associative floats, threading safe, etc). EDIT: In point 3, I would also add assumptions like whether the code can be changed at runtime, etc (take a pointer to a function then write your own code there).

dataflow 2y ago
> In this case, I would say the effects are much more obvious. Just take the example in the article. The compiler cannot replace a pointer access with its value if there has been any other pointers access in between. I have no idea what you mean. The whole point of this discussion is that the example in the article should not be optimized in the manner they're describing, because it would be wrong. That is... a good thing. Not a bad thing. And the compiler certainly could replace a pointer access with its value if there has been other pointer access in between, as long as that pointer wasn't leaked away into some opaque place via an integer. > The compiler also cannot reorder any statements with pointer accesses. They would basically behave as memory barriers (if I understand them correctly). No, I don't think you understood what I'm saying. See above. It would still be perfectly legal for the compiler to transform char p[1] = {0}; opaque(); return p[0]; to opaque(); return 0; under what I wrote above, the intervening statement notwithstanding.