3 ms·

If we understand "straightforward" in the sense that small changes in the input lead to predictable and small changes in the output, then I can't see how this i

If we understand "straightforward" in the sense that small changes in the input lead to predictable and small changes in the output, then I can't see how this is reasonably true for pretty much any optimizing compiler. Just today we had this nice example on the front page where initializing a variable differently completely changed the codegen for large parts of the program: https://jpieper.com/2022/08/05/debugging-bare-metal-stm32-from-the-seventh-level-of-hell/ https://jpieper.com/2022/08/05/debugging-bare-metal-stm32-fr...

j-pb 4y ago
Rust screams UB much quicker when it comes to memory semantics than any other language that I know. Rusts lower bounds of code mangling are also much higher than in other languages. I don't expect to have a good mental model of an optimising compiler in "gotta go fast"-mode, but a mental model of what the memory layout looks like is pretty darn relevant when designing or working with ABIs and binary data representations.
- ralfj 4y ago
  > Rust screams UB much quicker when it comes to memory semantics than any other language that I know. If you only use raw pointers, Rust has significantly less UB that C does. But if you use references, then yeah we have those aliasing rules and they can be quite restrictive.
  - j-pb 4y ago
    My brain isn't cached into the issue anymore, because I've since solved the same problem with Zig, but about a year ago there was no way to have a reference counted tagged pointer that points to a boxed DST with the minimum number of bytes. Every path lead through UB or "not yet defined" somewhere. You wrote a PHD on it so you might have a better idea of the issues that past me ran into, than what present me can still recall ;)
    - ralfj 4y ago
      It might still be tricky or even impossible to do that, that sounds very specific. If it is truly impossible we in the UCG would love to hear that. :) We don't want to rule out any legitimate use-case without reasonable alternatives (and yes those are deliberately fuzzy terms), but we do want to guarantee some baseline of optimizations that almost all code can benefit from, and it is okay for us if niche code then becomes harder to write. If we accidentally make it impossible to write though, that would be an issue we'd love to know about.
      - j-pb 4y ago
        I have it on my todo list to revisit the Rust implementation at some point. Now that const generics have landed at least some parts of the code should be easier to write. I'll throw you folks an issue over the fence, should I run into the same problems again, pinky swear ;) Whats the current state of the art for unsafe code? The guidelines?(https://rust-lang.github.io/unsafe-code-guidelines/ https://rust-lang.github.io/unsafe-code-guidelines/) I found the Rustonomicon, despite it's mythological status, to be quite thin. ^^'
        ralfj 4y ago
        UCG and their Zulip are a good place for thorny "is this UB" questions, yeah. We're thin on documentation indeed. First need to figure out all the rules, then find enough people to write all the educational material to teach them to everyone else. ;)
- Rusky 4y ago
  > I don't expect to have a good mental model of an optimising compiler in "gotta go fast"-mode, but a mental model of what the memory layout looks like is pretty darn relevant when designing or working with ABIs and binary data representations. I'm not sure where you got the idea otherwise, but Rust supports the same memory layouts and ABIs as C on a given platform. You don't get a specific layout by default because that allows for the implementation to improve over time, but that's not really relevant when working with binary data representations, where you simply specify which one to use.
SAI_Peregrinus 4y ago
It's also worth noting that (at least for C), the way the standard is worded an optimizing compiler and a non-optimizing compiler can generate exactly the same output in every situation. NONE of the unpredictability actually depends on optimization, it's just that optimization can (sometimes, if you're lucky) expose it. If you're not lucky, the code gen changes based on something harder to control than a single compiler option.

j-pb 4y ago

Rust screams UB much quicker when it comes to memory semantics than any other language that I know. Rusts lower bounds of code mangling are also much higher than in other languages. I don't expect to have a good mental model of an optimising compiler in "gotta go fast"-mode, but a mental model of what the memory layout looks like is pretty darn relevant when designing or working with ABIs and binary data representations.

ralfj 4y ago
> Rust screams UB much quicker when it comes to memory semantics than any other language that I know. If you only use raw pointers, Rust has significantly less UB that C does. But if you use references, then yeah we have those aliasing rules and they can be quite restrictive.
- j-pb 4y ago
  My brain isn't cached into the issue anymore, because I've since solved the same problem with Zig, but about a year ago there was no way to have a reference counted tagged pointer that points to a boxed DST with the minimum number of bytes. Every path lead through UB or "not yet defined" somewhere. You wrote a PHD on it so you might have a better idea of the issues that past me ran into, than what present me can still recall ;)
  - ralfj 4y ago
    It might still be tricky or even impossible to do that, that sounds very specific. If it is truly impossible we in the UCG would love to hear that. :) We don't want to rule out any legitimate use-case without reasonable alternatives (and yes those are deliberately fuzzy terms), but we do want to guarantee some baseline of optimizations that almost all code can benefit from, and it is okay for us if niche code then becomes harder to write. If we accidentally make it impossible to write though, that would be an issue we'd love to know about.
    - j-pb 4y ago
      I have it on my todo list to revisit the Rust implementation at some point. Now that const generics have landed at least some parts of the code should be easier to write. I'll throw you folks an issue over the fence, should I run into the same problems again, pinky swear ;) Whats the current state of the art for unsafe code? The guidelines?(https://rust-lang.github.io/unsafe-code-guidelines/ https://rust-lang.github.io/unsafe-code-guidelines/) I found the Rustonomicon, despite it's mythological status, to be quite thin. ^^'
      - ralfj 4y ago
        UCG and their Zulip are a good place for thorny "is this UB" questions, yeah. We're thin on documentation indeed. First need to figure out all the rules, then find enough people to write all the educational material to teach them to everyone else. ;)
Rusky 4y ago
> I don't expect to have a good mental model of an optimising compiler in "gotta go fast"-mode, but a mental model of what the memory layout looks like is pretty darn relevant when designing or working with ABIs and binary data representations. I'm not sure where you got the idea otherwise, but Rust supports the same memory layouts and ABIs as C on a given platform. You don't get a specific layout by default because that allows for the implementation to improve over time, but that's not really relevant when working with binary data representations, where you simply specify which one to use.

SAI_Peregrinus 4y ago

It's also worth noting that (at least for C), the way the standard is worded an optimizing compiler and a non-optimizing compiler can generate exactly the same output in every situation. NONE of the unpredictability actually depends on optimization, it's just that optimization can (sometimes, if you're lucky) expose it. If you're not lucky, the code gen changes based on something harder to control than a single compiler option.