3 ms·

I'm saying if you made a complier that made reduced that expected 50% to roughly 0%, it wouldn't matter to the user if it was 1E-10 or exactly 0%. Both could be

I'm saying if you made a complier that made reduced that expected 50% to roughly 0%, it wouldn't matter to the user if it was 1E-10 or exactly 0%. Both could be undesirable for exactly the same reason. Again: you can complain that the 1E-10 compiler is still "correct" because there was never a 50% guarantee, but in doing that you're completely missing the point. Here's an exaggerated example to get the point across. Imagine your Tesla autopilot's accuracy suddenly dropped from >99.9999% to <0.00001% overnight because of some stupid optimization (maybe this one) that was technically correct. Assume there was never a guarantee provided to the user that it would stay this accurate. Now if your 99.9999% became 99.9998% overnight, OK, I think a sane user would completely anticipate that and live with it. But when it drops orders of magnitude lower, do you really think you could shift the blame to the user because you were "technically" not guaranteeing anything? Is it really the user's fault that your optimization reduced that accuracy to 0.00001% and killed them? Can you walk away with your conscience clear at that point that you did everything 'right'? At what point do you feel like some kinds of changes just blatantly unfair and uncalled for, even if they're technically "by the book"?

deleted 5y ago
[deleted]
chrisseaton 5y ago
I guess I don't know why the user would be betting on interleavings which I never said I could guarantee. If you build your car with a part that isn't rated for what you use it for that's your fault not the manufacturer of the part - even if it worked every time when they tested it and they never saw it fail before one time it kills someone. I'm open to ideas on how to create understanding both ways on what the user wants and the compiler is able to provide?
- dataflow 5y ago
  > I guess I don't know why the user would be betting on interleavings which I never said I could guarantee. Same reason people walk outside without bodyguards and "bet" on coming back home alive despite the fact that nobody ever gave them such a guarantee. It's not insane to expect the future to bear some kind of resemblance to the past without some contract to guarantee it, is it?
  - chrisseaton 5y ago
    > It's not insane to expect the future to bear some kind of resemblance to the past without some contract to guarantee it, is it? Well you used the example of a car and I think it would be insane to use a component in a car when the manufacturer tells you it's not designed to do that and I can't possibly guarantee that's going to work just because you think you tested it and it seemed fine.
    - dataflow 5y ago
      Sigh. What about my subsequent example? About walking outside with a bodyguard despite the lack of a guarantee you'd stay safe?
      - chrisseaton 5y ago
        I don't get why you're sighing at me when I'm answering your questions politely. If you don't like my replies feel free to stop asking me questions. Your example about going outside isn't covered by a technical specification with a long list of guarantees formally agreed between two parties so I don't really see how it's comparable.
        dataflow 5y ago
        The question was about whether the original designer deserves any blame for making a sudden change like that. Not about whether the manufacturer is at fault vs. the user vs. a bunch of other middlemen that weren't in the story. That twist just derailed the discussion, and it's frustrating to discuss something when the other person is so keen to avoid the crux of the question. So much so that you didn't even try to address everything else I wrote.
        chrisseaton 5y ago
        > The question was about whether the original designer deserves any blame for making a sudden change like that. I don't believe so - as long as there is a version change and it's documented in the change log, which I aim to do with optimisations I write. If you're using undocumented apparent behaviour, please check the change log when upgrading, or ask us to document the behaviour. But as already described, we may not be able to guarantee what you want while keeping other things you depend on like performance!
gizmo686 5y ago
Tesla's autopilot has a guarantee for its accuracy. If that drops to 0.00001%, then that is a problem, because the autopilot functionality is failing to meet its requirements. If that drop in accuracy happens because of a technically correct change, then that just means the actual bug was somewhere else and just happened to work previously. It also means that there is a flaw in Testla's quality control process that allowed such a change to ship to customers. If your program breaks because the compiler no longer interleaves atomics, then your program was always broken, and you have just been getting lucky until now. Normally when this type of situation comes up, the programmers perspective is at least understandable, since what they were doing was somewhat reasonable, even if not allowed by the standard. In this case, the point is that I (and, I presume chrisseaton) cannot come up with any reasonable program that would rely on an interleaving happening 50% of the time. If the interleaving were originally observed 99.999999% of the time, I could imagine a program relying on it happening. However, if the writes are close enough that the compiler could optimize them together, chances are the pre-optmiztion chance of it happening was already much closer to 0% than to 100%; which, again, begs the question 'what was your program possibly doing that relied on the original behaviour?'
- dataflow 5y ago
  > Tesla's autopilot has a guarantee for its accuracy. Which (if true) is completely beside my the point. Just pick something that doesn't have a guarantee. The comment wasn't about Tesla. It was about empirical performance vs. written guarantees. > Normally when this type of situation comes up, the programmers perspective is at least understandable, since what they were doing was somewhat reasonable, even if not allowed by the standard. Okay great, we agree on that. > In this case, the point is that I cannot come up with any reasonable program that would rely on an interleaving happening 50% of the time. That's easily explained by our lack of imagination. No need to assume the person relying on it is being unreasonable. Hypothetical example: suppose two threads are trying to alternate running some specific instructions with minimal latency. Maybe there are hardware requirements (e.g. they want to avoid overheating come specific components of a CPU core for too long?), so they try to alternate work via an atomically increasing counter? That's a starting point at least, feel free to improve the scenario.

deleted 5y ago

[deleted]

chrisseaton 5y ago

I guess I don't know why the user would be betting on interleavings which I never said I could guarantee. If you build your car with a part that isn't rated for what you use it for that's your fault not the manufacturer of the part - even if it worked every time when they tested it and they never saw it fail before one time it kills someone. I'm open to ideas on how to create understanding both ways on what the user wants and the compiler is able to provide?

dataflow 5y ago
> I guess I don't know why the user would be betting on interleavings which I never said I could guarantee. Same reason people walk outside without bodyguards and "bet" on coming back home alive despite the fact that nobody ever gave them such a guarantee. It's not insane to expect the future to bear some kind of resemblance to the past without some contract to guarantee it, is it?
- chrisseaton 5y ago
  > It's not insane to expect the future to bear some kind of resemblance to the past without some contract to guarantee it, is it? Well you used the example of a car and I think it would be insane to use a component in a car when the manufacturer tells you it's not designed to do that and I can't possibly guarantee that's going to work just because you think you tested it and it seemed fine.
  - dataflow 5y ago
    Sigh. What about my subsequent example? About walking outside with a bodyguard despite the lack of a guarantee you'd stay safe?
    - chrisseaton 5y ago
      I don't get why you're sighing at me when I'm answering your questions politely. If you don't like my replies feel free to stop asking me questions. Your example about going outside isn't covered by a technical specification with a long list of guarantees formally agreed between two parties so I don't really see how it's comparable.
      - dataflow 5y ago
        The question was about whether the original designer deserves any blame for making a sudden change like that. Not about whether the manufacturer is at fault vs. the user vs. a bunch of other middlemen that weren't in the story. That twist just derailed the discussion, and it's frustrating to discuss something when the other person is so keen to avoid the crux of the question. So much so that you didn't even try to address everything else I wrote.
        chrisseaton 5y ago
        > The question was about whether the original designer deserves any blame for making a sudden change like that. I don't believe so - as long as there is a version change and it's documented in the change log, which I aim to do with optimisations I write. If you're using undocumented apparent behaviour, please check the change log when upgrading, or ask us to document the behaviour. But as already described, we may not be able to guarantee what you want while keeping other things you depend on like performance!

gizmo686 5y ago

Tesla's autopilot has a guarantee for its accuracy. If that drops to 0.00001%, then that is a problem, because the autopilot functionality is failing to meet its requirements. If that drop in accuracy happens because of a technically correct change, then that just means the actual bug was somewhere else and just happened to work previously. It also means that there is a flaw in Testla's quality control process that allowed such a change to ship to customers. If your program breaks because the compiler no longer interleaves atomics, then your program was always broken, and you have just been getting lucky until now. Normally when this type of situation comes up, the programmers perspective is at least understandable, since what they were doing was somewhat reasonable, even if not allowed by the standard. In this case, the point is that I (and, I presume chrisseaton) cannot come up with any reasonable program that would rely on an interleaving happening 50% of the time. If the interleaving were originally observed 99.999999% of the time, I could imagine a program relying on it happening. However, if the writes are close enough that the compiler could optimize them together, chances are the pre-optmiztion chance of it happening was already much closer to 0% than to 100%; which, again, begs the question 'what was your program possibly doing that relied on the original behaviour?'

dataflow 5y ago
> Tesla's autopilot has a guarantee for its accuracy. Which (if true) is completely beside my the point. Just pick something that doesn't have a guarantee. The comment wasn't about Tesla. It was about empirical performance vs. written guarantees. > Normally when this type of situation comes up, the programmers perspective is at least understandable, since what they were doing was somewhat reasonable, even if not allowed by the standard. Okay great, we agree on that. > In this case, the point is that I cannot come up with any reasonable program that would rely on an interleaving happening 50% of the time. That's easily explained by our lack of imagination. No need to assume the person relying on it is being unreasonable. Hypothetical example: suppose two threads are trying to alternate running some specific instructions with minimal latency. Maybe there are hardware requirements (e.g. they want to avoid overheating come specific components of a CPU core for too long?), so they try to alternate work via an atomically increasing counter? That's a starting point at least, feel free to improve the scenario.