3 ms·

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

by dsfuoi 10y 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 10y 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 10y 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 10y ago
    No argument there. I'm a fan of strict-aliasing optimizations. :)
    - nkurz 10y 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 10y 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.

by dsfuoi 10y ago

pcwalton 10y 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 10y 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 10y ago
  No argument there. I'm a fan of strict-aliasing optimizations. :)
  - nkurz 10y 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 10y 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.