4 ms·

Your compiler does not hallucinate registers or JMP instructions

by weikju 1y ago

osti 1y ago
I bet they did at one point in time, then they stopped doing that, but still not bug free.
- weikju 1y ago
  lol are you serious? I bet compilers are less deterministic now than before what with all the CPUs and their speculative executions and who knows what else. But all that stuff is still documented and not made out of thin air randomly…
zdragnar 1y ago
Doesn't it? Many compilers offer all sorts of novel optimizations for operations that end up producing the same result with entirely different runtime characteristics than the source code would imply. Going further, turn on gcc fast math and your code with no undefined behavior suddenly has undefined behavior. I'm not much of a user of LLMs for generating code myself, but this particular analogy isn't a great fit. The one redeeming quality is that compiler output is deterministic or at least repeatable, whereas LLMs have some randomness thrown in intentionally. With that said, both can give you unexpected behavior, just in different ways.
- MobiusHorizons 1y ago
  I suppose you are talking about UB? I don't think that is anything like Halucination. It's just tradeoffs being made (speed vs specified instructions) with more ambiguity (UB) than one might want. fast math is basically the same idea. You should probably never turn on fast math unless you are willing to trade speed for accuracy and accept a bunch of new UB that your libraries may never have been designed for. It's not like the compiler is making up new instructions that the hardware doesn't support or claiming the behavior of an instruction is different than documented. If it ever did anything like that, it would be a bug, and would be fixed.
  - Dylan16807 1y ago
    > or claiming the behavior of an instruction is different than documented When talking about undefined behavior, the only documentation is a shrug emoticon. If you want a working program, arbitrary undocumented behavior is just as bad as incorrectly documented behavior.
    - MobiusHorizons 1y ago
      UB is not undocumented. It is documented to not be defined. In fact any given hardware reacts deterministically in the majority of UB cases, but compilers are allowed to assume UB was not possible for the purposes of optimization.
      - Dylan16807 1y ago
        The trigger for UB is documented, the result is not documented. And despite the triggers being documented, they're very very hard to avoid completely.
- skydhash 1y ago
  > With that said, both can give you unexpected behavior, just in different ways. Unexpected as in "I didn't know" is different than unexpected as in "I can't predict". GCC optimizations is in the former camp and if you care to know, you just need to do a deep dive in your CPU architecture and the gcc docs and codebase. LLMs is a true shot in the dark with a high chance miss and a slightly lower chance of friendly fire.
  - Dylan16807 1y ago
    And every single developer is supposed to memorize GCC's optimizations so they never make a change that will optimize wrong? Nah, treating undefined behavior as predictable is a fool's errand. It's also a shot in the dark.
    - skydhash 1y ago
      What is that about memorization? I just need to know where the information is so I can refer to it later when I need it (and possibly archive them if they're that important).
      - Dylan16807 1y ago
        If you're not trying to memorize the entirety of GCC's behavior (and keeping up with its updates), then you need to check if your UB is still doing what you expect every single time you change your function. Or other functions near it. Or anything that gets linked to it. It's effectively impossible to rely on. Checking at the time of coding, or occasionally spot checking, still leaves you at massive risk of bugs or security flaws. It falls under "I can't predict".
        skydhash 1y ago
        In C, strings are just basic arrays which themselves are just pointers. There’s no safeguards there like we have in Java, so we need to write the guardrails ourselves, because failure to do so result in errors. If you didn’t know about it, a buffer overflow may be unexpected, but you don’t need to go and memorize the entire gcc codebase to know. Just knowing the semantics is enough. The same thing happens with optimization. They usually warns about the gotchas, and it’s easy to check if the errors will bother you or not. You dont have to do an exhaustive list of errors when the classes are neatly defined.

Your compiler does not hallucinate registers or JMP instructions

by weikju 1y ago

Your compiler does not hallucinate registers or JMP instructions

osti 1y ago

I bet they did at one point in time, then they stopped doing that, but still not bug free.

weikju 1y ago
lol are you serious? I bet compilers are less deterministic now than before what with all the CPUs and their speculative executions and who knows what else. But all that stuff is still documented and not made out of thin air randomly…

zdragnar 1y ago

Doesn't it? Many compilers offer all sorts of novel optimizations for operations that end up producing the same result with entirely different runtime characteristics than the source code would imply. Going further, turn on gcc fast math and your code with no undefined behavior suddenly has undefined behavior. I'm not much of a user of LLMs for generating code myself, but this particular analogy isn't a great fit. The one redeeming quality is that compiler output is deterministic or at least repeatable, whereas LLMs have some randomness thrown in intentionally. With that said, both can give you unexpected behavior, just in different ways.

MobiusHorizons 1y ago
I suppose you are talking about UB? I don't think that is anything like Halucination. It's just tradeoffs being made (speed vs specified instructions) with more ambiguity (UB) than one might want. fast math is basically the same idea. You should probably never turn on fast math unless you are willing to trade speed for accuracy and accept a bunch of new UB that your libraries may never have been designed for. It's not like the compiler is making up new instructions that the hardware doesn't support or claiming the behavior of an instruction is different than documented. If it ever did anything like that, it would be a bug, and would be fixed.
- Dylan16807 1y ago
  > or claiming the behavior of an instruction is different than documented When talking about undefined behavior, the only documentation is a shrug emoticon. If you want a working program, arbitrary undocumented behavior is just as bad as incorrectly documented behavior.
  - MobiusHorizons 1y ago
    UB is not undocumented. It is documented to not be defined. In fact any given hardware reacts deterministically in the majority of UB cases, but compilers are allowed to assume UB was not possible for the purposes of optimization.
    - Dylan16807 1y ago
      The trigger for UB is documented, the result is not documented. And despite the triggers being documented, they're very very hard to avoid completely.
skydhash 1y ago
> With that said, both can give you unexpected behavior, just in different ways. Unexpected as in "I didn't know" is different than unexpected as in "I can't predict". GCC optimizations is in the former camp and if you care to know, you just need to do a deep dive in your CPU architecture and the gcc docs and codebase. LLMs is a true shot in the dark with a high chance miss and a slightly lower chance of friendly fire.
- Dylan16807 1y ago
  And every single developer is supposed to memorize GCC's optimizations so they never make a change that will optimize wrong? Nah, treating undefined behavior as predictable is a fool's errand. It's also a shot in the dark.
  - skydhash 1y ago
    What is that about memorization? I just need to know where the information is so I can refer to it later when I need it (and possibly archive them if they're that important).
    - Dylan16807 1y ago
      If you're not trying to memorize the entirety of GCC's behavior (and keeping up with its updates), then you need to check if your UB is still doing what you expect every single time you change your function. Or other functions near it. Or anything that gets linked to it. It's effectively impossible to rely on. Checking at the time of coding, or occasionally spot checking, still leaves you at massive risk of bugs or security flaws. It falls under "I can't predict".
      - skydhash 1y ago
        In C, strings are just basic arrays which themselves are just pointers. There’s no safeguards there like we have in Java, so we need to write the guardrails ourselves, because failure to do so result in errors. If you didn’t know about it, a buffer overflow may be unexpected, but you don’t need to go and memorize the entire gcc codebase to know. Just knowing the semantics is enough. The same thing happens with optimization. They usually warns about the gotchas, and it’s easy to check if the errors will bother you or not. You dont have to do an exhaustive list of errors when the classes are neatly defined.