5 ms·

A related comment: http://blog.regehr.org/archives/1287 http://blog.regehr.org/archives/1287

jabl 11y ago
Indeed. The only realistic way out of this conundrum AFAICS is some kind of consensus around "friendly C"/"boring C" or such that compilers then can implement, whether it's an annex to the official C standard or some other kind of spec. That, or then everybody switches to Rust. :) (hey, I can daydream can I?).
- pcwalton 11y ago
  And everyone will have to accept the performance loss--and there will be performance loss. This is acceptable for many applications, don't get me wrong. But it will be a tough sell. If you want to get people using a Friendly C, you need to start convincing the biggest users of C and C++ that they should give up performance for a simpler dialect of the language. Like politicians responding to voters, compiler authors respond to what their customers demand. Up to now, their customers have demanded performance. It's not their fault for listening to them.
  - dsfuoi 11y ago
    Performance of real code, not micro-benchmarks, won't change. And this can work both ways. Friendly C would almost certainly forbid non-compatible type pointer castings, which would actually enable additional optimizations.
    - pcwalton 11y ago
      > Performance of real code, not micro-benchmarks, won't change. I doubt that. Autovectorization certainly does help performance of real code, for example. > And this can work both ways. Friendly C would almost certainly forbid non-compatible type pointer castings, which would actually enable additional optimizations. I'm not sure what that means; could you elaborate? That sounds like strict aliasing, which is one of the things "Friendly C" is opposed to…
      - dsfuoi 11y ago
        I believe you have been using a definition of Friendly C, as seen here: http://blog.regehr.org/archives/1180 http://blog.regehr.org/archives/1180. I wasn't aware of that and my idea of it is different. Aliasing rules help the compiler decide what values have to be reloaded. The stricter those rules less chance there is for pointers to alias the same memory.
        pcwalton 11y ago
        No argument there. I'm a fan of strict-aliasing optimizations. :)
        nkurz 11y ago
        For possible clarity, despite arguing against "unwanted" optimizations, I'll mention that I'm also in favor of strict aliasing. That's the sort of optimization I like, especially if it's "opt-in" by specifying -std=c99 or -std=c11. It's unlikely to happen and probably not wise, but my personal preference for future standards would be to invert the "restrict" paradigm, and assume that even same-type writes never alias unless "may_alias" or some-such is specified.
      - colin_mccabe 11y ago
        A lot of real-world projects turn off strict aliasing, such as the Linux kernel. It is just too difficult to think about every possible issue that could happen when doing a typecast. Autovectorization doesn't tend to work well anyway. In most cases where it truly matters, people use inline assembly... for example, in CRC calculations code, tight inner loops in math libraries, etc. If you really want autovectorization, "restrict" is a better solution which doesn't require breaking the world to implement.
  - nkurz 11y ago
    If you want to get people using a Friendly C, you need to start convincing the biggest users of C and C++ that they should give up performance for a simpler dialect of the language. Why would would C++ programmers have to give up anything? You may notice that the frequent complaint (and title of the article) is "undefined behavior in C", and the hypothetical replacement language is "Friendly C", not "Friendly C++". From the point of view of most who are troubled, rightly or wrongly, C++ isn't considered relevant to the problem or the solution. I think part of the "divide" is that compiler writers (and probably C++ programmers) are more likely to lump C and C++ together. This makes sense, as C++ is mostly a superset of C, and since many of the optimizations being questioned operate at the level of internal intermediate language that's the same for both. But many C programmers don't view them as being the same language at all, and have no opinion on how C++ compilers should operate. Perhaps what needs to be questioned is assumption that the needs of C and C++ programmers can effectively be served by the same compiler? (I realize I've responded strongly to two of your comments in a row. I care strongly about the issue, but don't intend this to be an attack. Rather trying to convince you that you're wrong, my goal is just to understand what produces the gap between our viewpoints.)
    - pcwalton 11y ago
      Do you have any UB-sensitive optimizations in mind that affect only C but not C++, or vice versa? I can't really think of any.
      - nkurz 11y ago
        Do you have any UB-sensitive optimizations in mind that affect only C but not C++, or vice versa? I presume there are some, but they aren't the sort of thing I have in mind. I'm talking more about the expectations that the users of each language have. For whatever reason, C programmers are much more likely to complain about "broken" optimizations than are C++ programmers. Of course this isn't absolute, but I think it's undeniably a pattern. I'd guess this is because C has a heritage of being "portable assembly", and thus many programmers have an expectation of a 1:1 correspondence between the code they write and the finished product, and are startled when it doesn't. In the case of explicit null checks being removed and loops being removed resulting in memory not being zeroed, I think they have a point. Perhaps there is some way to apply different levels of optimization to the code that the programmer writes versus code "generated" code?
  - jabl 11y ago
    I don't think it's realistic for friendly C to replace the current C outright. At best I guess one would get -std=friendly or -Ofriendly or such. And HPC users could continue using tbaa, loose fp semantics etc. as before.
  - fanf2 11y ago
    It is already common for serious C programs to use -fno-strict-aliasing and less commonly -fwrapv. The programmers are already convinced.
  - pslam 11y ago
    > Up to now, their customers have demanded performance. It's not their fault for listening to them. I disagree - it is almost entirely their fault for listening to them. Customers usually don't know what they really want. "Faster horses". The whole point of having an oversight committee is to steer the language, and they failed at the task. Rather than steering towards sanity - which C/C++ badly need - it was steered towards performance at pretty much all costs. The result is a broken language: it is extraordinarily difficult to write correct programs, and assure that a program will continue to compile as intended many years in the future. Sanity, correctness and fragility are exactly the kind of things which oversight should have tackled, but instead we got the opposite. I say this as a decades-long user and fan of C/C++. But I've come to realize recently that it's a lost cause, because those in the position to fix the language are powerless against the wishes of their customers.
- yaur 11y ago
  Won't -O0 pretty much solve this for anyone willing to trade performance for a higher tolerance for UB, though if you are in that group there are probably better language choices than C.
- omginternets 11y ago
  I'm in way over my head and skimming comments to see what I can learn, so my question is a bit tangential: why can't everybody switch to Rust? Are you commenting on the difficulty of convincing everybody to rewrite their entire code-base or on some technical aspect of the language? Thanks!
  - jabl 11y ago
    With the largish disclaimer that so far I'm quite a Rust n00b, I'm loving it so far! So per se I don't think there are any technical deficiencies in the language itself compared to C.
    - omginternets 11y ago
      Okay, cool, that answers my question :) What resources are you using to get into Rust? I've been curious for a while, but I'm not sure where to start.
      - jabl 11y ago
        Nothing special I guess. Mostly the rust book and reference manual + duckduckgo search which bring up the odd blog post or SO question. But I think it depends a lot on your previous experience. If you have experience of other languages, particularly c/c++ and some functional style thing like Haskell there isn't that much of a mental barrier IMHO.

jabl 11y ago

Indeed. The only realistic way out of this conundrum AFAICS is some kind of consensus around "friendly C"/"boring C" or such that compilers then can implement, whether it's an annex to the official C standard or some other kind of spec. That, or then everybody switches to Rust. :) (hey, I can daydream can I?).

pcwalton 11y ago
And everyone will have to accept the performance loss--and there will be performance loss. This is acceptable for many applications, don't get me wrong. But it will be a tough sell. If you want to get people using a Friendly C, you need to start convincing the biggest users of C and C++ that they should give up performance for a simpler dialect of the language. Like politicians responding to voters, compiler authors respond to what their customers demand. Up to now, their customers have demanded performance. It's not their fault for listening to them.
- dsfuoi 11y ago
  Performance of real code, not micro-benchmarks, won't change. And this can work both ways. Friendly C would almost certainly forbid non-compatible type pointer castings, which would actually enable additional optimizations.
  - pcwalton 11y ago
    > Performance of real code, not micro-benchmarks, won't change. I doubt that. Autovectorization certainly does help performance of real code, for example. > And this can work both ways. Friendly C would almost certainly forbid non-compatible type pointer castings, which would actually enable additional optimizations. I'm not sure what that means; could you elaborate? That sounds like strict aliasing, which is one of the things "Friendly C" is opposed to…
    - dsfuoi 11y ago
      I believe you have been using a definition of Friendly C, as seen here: http://blog.regehr.org/archives/1180 http://blog.regehr.org/archives/1180. I wasn't aware of that and my idea of it is different. Aliasing rules help the compiler decide what values have to be reloaded. The stricter those rules less chance there is for pointers to alias the same memory.
      - pcwalton 11y ago
        No argument there. I'm a fan of strict-aliasing optimizations. :)
        nkurz 11y ago
        For possible clarity, despite arguing against "unwanted" optimizations, I'll mention that I'm also in favor of strict aliasing. That's the sort of optimization I like, especially if it's "opt-in" by specifying -std=c99 or -std=c11. It's unlikely to happen and probably not wise, but my personal preference for future standards would be to invert the "restrict" paradigm, and assume that even same-type writes never alias unless "may_alias" or some-such is specified.
    - colin_mccabe 11y ago
      A lot of real-world projects turn off strict aliasing, such as the Linux kernel. It is just too difficult to think about every possible issue that could happen when doing a typecast. Autovectorization doesn't tend to work well anyway. In most cases where it truly matters, people use inline assembly... for example, in CRC calculations code, tight inner loops in math libraries, etc. If you really want autovectorization, "restrict" is a better solution which doesn't require breaking the world to implement.
- nkurz 11y ago
  If you want to get people using a Friendly C, you need to start convincing the biggest users of C and C++ that they should give up performance for a simpler dialect of the language. Why would would C++ programmers have to give up anything? You may notice that the frequent complaint (and title of the article) is "undefined behavior in C", and the hypothetical replacement language is "Friendly C", not "Friendly C++". From the point of view of most who are troubled, rightly or wrongly, C++ isn't considered relevant to the problem or the solution. I think part of the "divide" is that compiler writers (and probably C++ programmers) are more likely to lump C and C++ together. This makes sense, as C++ is mostly a superset of C, and since many of the optimizations being questioned operate at the level of internal intermediate language that's the same for both. But many C programmers don't view them as being the same language at all, and have no opinion on how C++ compilers should operate. Perhaps what needs to be questioned is assumption that the needs of C and C++ programmers can effectively be served by the same compiler? (I realize I've responded strongly to two of your comments in a row. I care strongly about the issue, but don't intend this to be an attack. Rather trying to convince you that you're wrong, my goal is just to understand what produces the gap between our viewpoints.)
  - pcwalton 11y ago
    Do you have any UB-sensitive optimizations in mind that affect only C but not C++, or vice versa? I can't really think of any.
    - nkurz 11y ago
      Do you have any UB-sensitive optimizations in mind that affect only C but not C++, or vice versa? I presume there are some, but they aren't the sort of thing I have in mind. I'm talking more about the expectations that the users of each language have. For whatever reason, C programmers are much more likely to complain about "broken" optimizations than are C++ programmers. Of course this isn't absolute, but I think it's undeniably a pattern. I'd guess this is because C has a heritage of being "portable assembly", and thus many programmers have an expectation of a 1:1 correspondence between the code they write and the finished product, and are startled when it doesn't. In the case of explicit null checks being removed and loops being removed resulting in memory not being zeroed, I think they have a point. Perhaps there is some way to apply different levels of optimization to the code that the programmer writes versus code "generated" code?
- jabl 11y ago
  I don't think it's realistic for friendly C to replace the current C outright. At best I guess one would get -std=friendly or -Ofriendly or such. And HPC users could continue using tbaa, loose fp semantics etc. as before.
- fanf2 11y ago
  It is already common for serious C programs to use -fno-strict-aliasing and less commonly -fwrapv. The programmers are already convinced.
- pslam 11y ago
  > Up to now, their customers have demanded performance. It's not their fault for listening to them. I disagree - it is almost entirely their fault for listening to them. Customers usually don't know what they really want. "Faster horses". The whole point of having an oversight committee is to steer the language, and they failed at the task. Rather than steering towards sanity - which C/C++ badly need - it was steered towards performance at pretty much all costs. The result is a broken language: it is extraordinarily difficult to write correct programs, and assure that a program will continue to compile as intended many years in the future. Sanity, correctness and fragility are exactly the kind of things which oversight should have tackled, but instead we got the opposite. I say this as a decades-long user and fan of C/C++. But I've come to realize recently that it's a lost cause, because those in the position to fix the language are powerless against the wishes of their customers.
yaur 11y ago
Won't -O0 pretty much solve this for anyone willing to trade performance for a higher tolerance for UB, though if you are in that group there are probably better language choices than C.
omginternets 11y ago
I'm in way over my head and skimming comments to see what I can learn, so my question is a bit tangential: why can't everybody switch to Rust? Are you commenting on the difficulty of convincing everybody to rewrite their entire code-base or on some technical aspect of the language? Thanks!
- jabl 11y ago
  With the largish disclaimer that so far I'm quite a Rust n00b, I'm loving it so far! So per se I don't think there are any technical deficiencies in the language itself compared to C.
  - omginternets 11y ago
    Okay, cool, that answers my question :) What resources are you using to get into Rust? I've been curious for a while, but I'm not sure where to start.
    - jabl 11y ago
      Nothing special I guess. Mostly the rust book and reference manual + duckduckgo search which bring up the odd blog post or SO question. But I think it depends a lot on your previous experience. If you have experience of other languages, particularly c/c++ and some functional style thing like Haskell there isn't that much of a mental barrier IMHO.