Hacker News Reader

Comment by pcwalton | Hacker News Reader

> 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…

View on HN

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.

I believe you have been using a definition of Friendly C, as seen here: 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.

No argument there. I'm a fan of strict-aliasing optimizations. :)

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.

Reply on news.ycombinator.com