Hacker News Reader

Comment by pcwalton | Hacker News Reader

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.

View on HN

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.)

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.

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?

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

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.

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

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.

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.

It is already common for serious C programs to use -fno-strict-aliasing and less commonly -fwrapv. The programmers are already convinced.

Reply on news.ycombinator.com