4 ms·

maybe there's a question here: If you really need the kind of performance afforded by that level of fine-grained optimization, shouldn't you instead consider e

maybe there's a question here: If you really need the kind of performance afforded by that level of fine-grained optimization, shouldn't you instead consider emitting better code, at least in hot loops? It seems less dangerous to have the code do semantically exactly what you tell it to in the 90% case, because otherwise you can unwittingly introduce difficult-to-reason-about code. For a GP programming language, this could be possibly deployed in mission-critical code where lives are at stake.

sanxiyn 6y ago
I am not sure what the question is. Are you proposing manual marking of hot code and applying pointers-are-integers model to all code but optimizable pointer model to marked code?
jcranmer 6y ago
To get an idea of the kind of performance degradation involved, make every variable and every pointer in your program volatile. Honestly, the actual pointer model of C is probably easier to understand than a everything-can-randomly-change-anything pointers-are-integers model. Undefined behavior gets a bit of a bad rap, and that's arguably largely because of unnecessarily gratuitous usage of it (signed integer overflow and strict aliasing being the biggies). But undefined behavior is actually a contract where the programmer promises not to do certain things. For pointers, the contract boils down to the following: * Do not violate strict aliasing (I'd call this an unnecessary rule, and it can be disabled in most compilers). * Do not read memory you haven't initialized. * Do not use memory after it's deallocated. * Do not look outside the bounds of the object you are given. * Do not look at memory you haven't been told about. There is very little reason to ever need to violate these rules. In fact, violating these rules tends to result in hard-to-reason semantics: suddenly, people can read things they shouldn't be able to, or decide to do things like execute random code.
- petergeoghegan 6y ago
  I agree with your points about undefined behavior. I'm pleasantly surprised that you didn't defend C's terrible strict aliasing rules. Your interpretation seems uncharitable. I imagine that you've interpreted the author's words literally, as somebody that has expert knowledge of compiler internals. Could the author really have meant to propose an "everything-can-randomly-change-anything pointers-are-integers" model?
  - sanxiyn 6y ago
    What is the author's model then? I agree everything-can-randomly-change-anything interpretation is uncharitable, but then I am confused what the model is. (As you pointed out, that's the literal interpretation.) I think there is no model, and the author is just vaguely complaining they are not satisfied with status quo. But then the tone is unbelievably arrogant and deserves all the derision. By the way, I am of the opinion C's pointer model can be greatly improved to be programmer friendly, beyond getting rid of strict aliasing rule. For example, I think comparing two unrelated pointers (for sorting, lock ordering, etc.) should be well defined and not UB. But claiming "pointers are easy" is not the way to go.
    - petergeoghegan 6y ago
      Why would you assume that the author must have a formal model? It's a short blog post. Perhaps the author really is deserving of derision to some degree - who can say? It should not be based on a straw man that nobody could possibly believe, though.
  - jcranmer 6y ago
    In my experience, the model that most people railing against undefined behavior tend to end up proposing is a vague, "read-my-mind" sort of model. Semantics are hard, and undefined behavior makes it especially so. See the voluminous threads on llvm-dev trying to pin down what "undef" actually means for an example. In the context here, the linked article is a response to someone who is describing why defining a memory model is actually more difficult than it seems. The linked article is basically saying "screw that, it doesn't have to be hard, just use the obvious model" without specifying what the obvious model actually is. After you've been in a couple of hour-long meetings where everyone is arguing over what the "obvious" model actually says, it's painfully obvious that "obvious" isn't obvious.
- saagarjha 6y ago
  > Do not look outside the bounds of the object you are given. Do not even try to look; computing a pointer that points outside the object it was created from is undefined.
  - sanxiyn 6y ago
    Yes in current C standard. As far as I know this is not necessary for optimizations and I want this to be fixed in the future C standard.
    - saagarjha 6y ago
      I'm not very sure this is a good idea–what exactly is the benefit of allowing the creation of off-by-one pointers that you can't do anything with?
      - sanxiyn 6y ago
        My motivation is to prevent accidental UB. Let p be array of length 10. Currently, p + 15 - 10 is UB so you must parenthesize p + (15 - 10). This seems preventable and unnecessary.
        saagarjha 6y ago
        That's a fairly convincing example. +1 to this change, then.
        jcranmer 6y ago
        Another related change I'd like to see is that &(foo * )(NULL)->bar - (foo * )NULL be made well-defined. Effectively, allowing a generalization of offset_of to be written in C/C++.

sanxiyn 6y ago

I am not sure what the question is. Are you proposing manual marking of hot code and applying pointers-are-integers model to all code but optimizable pointer model to marked code?

jcranmer 6y ago

To get an idea of the kind of performance degradation involved, make every variable and every pointer in your program volatile. Honestly, the actual pointer model of C is probably easier to understand than a everything-can-randomly-change-anything pointers-are-integers model. Undefined behavior gets a bit of a bad rap, and that's arguably largely because of unnecessarily gratuitous usage of it (signed integer overflow and strict aliasing being the biggies). But undefined behavior is actually a contract where the programmer promises not to do certain things. For pointers, the contract boils down to the following: * Do not violate strict aliasing (I'd call this an unnecessary rule, and it can be disabled in most compilers). * Do not read memory you haven't initialized. * Do not use memory after it's deallocated. * Do not look outside the bounds of the object you are given. * Do not look at memory you haven't been told about. There is very little reason to ever need to violate these rules. In fact, violating these rules tends to result in hard-to-reason semantics: suddenly, people can read things they shouldn't be able to, or decide to do things like execute random code.

petergeoghegan 6y ago
I agree with your points about undefined behavior. I'm pleasantly surprised that you didn't defend C's terrible strict aliasing rules. Your interpretation seems uncharitable. I imagine that you've interpreted the author's words literally, as somebody that has expert knowledge of compiler internals. Could the author really have meant to propose an "everything-can-randomly-change-anything pointers-are-integers" model?
- sanxiyn 6y ago
  What is the author's model then? I agree everything-can-randomly-change-anything interpretation is uncharitable, but then I am confused what the model is. (As you pointed out, that's the literal interpretation.) I think there is no model, and the author is just vaguely complaining they are not satisfied with status quo. But then the tone is unbelievably arrogant and deserves all the derision. By the way, I am of the opinion C's pointer model can be greatly improved to be programmer friendly, beyond getting rid of strict aliasing rule. For example, I think comparing two unrelated pointers (for sorting, lock ordering, etc.) should be well defined and not UB. But claiming "pointers are easy" is not the way to go.
  - petergeoghegan 6y ago
    Why would you assume that the author must have a formal model? It's a short blog post. Perhaps the author really is deserving of derision to some degree - who can say? It should not be based on a straw man that nobody could possibly believe, though.
- jcranmer 6y ago
  In my experience, the model that most people railing against undefined behavior tend to end up proposing is a vague, "read-my-mind" sort of model. Semantics are hard, and undefined behavior makes it especially so. See the voluminous threads on llvm-dev trying to pin down what "undef" actually means for an example. In the context here, the linked article is a response to someone who is describing why defining a memory model is actually more difficult than it seems. The linked article is basically saying "screw that, it doesn't have to be hard, just use the obvious model" without specifying what the obvious model actually is. After you've been in a couple of hour-long meetings where everyone is arguing over what the "obvious" model actually says, it's painfully obvious that "obvious" isn't obvious.
saagarjha 6y ago
> Do not look outside the bounds of the object you are given. Do not even try to look; computing a pointer that points outside the object it was created from is undefined.
- sanxiyn 6y ago
  Yes in current C standard. As far as I know this is not necessary for optimizations and I want this to be fixed in the future C standard.
  - saagarjha 6y ago
    I'm not very sure this is a good idea–what exactly is the benefit of allowing the creation of off-by-one pointers that you can't do anything with?
    - sanxiyn 6y ago
      My motivation is to prevent accidental UB. Let p be array of length 10. Currently, p + 15 - 10 is UB so you must parenthesize p + (15 - 10). This seems preventable and unnecessary.
      - saagarjha 6y ago
        That's a fairly convincing example. +1 to this change, then.
      - jcranmer 6y ago
        Another related change I'd like to see is that &(foo * )(NULL)->bar - (foo * )NULL be made well-defined. Effectively, allowing a generalization of offset_of to be written in C/C++.