7 ms·
Let me paraphrase this differently, on a more pragmatic level. From the perspecitve of a compiler user, rather than a compiler author: How likely do you think i
by 1ris 5y ago
Let me paraphrase this differently, on a more pragmatic level. From the perspecitve of a compiler user, rather than a compiler author: How likely do you think is it that a program that contains memset and has this optimisation applied how diverts from the indented behaviour and now has a serious flaw in it? The answer to this question is the answer to your question "Why not?".
When people write C, they often do so for specific domains. Crypto, embedded, device drivers. They choose C for these domains because they think, and they are taught that C is some kind of macro assembler, because in these domains they care deeply about the "how". If they wouldn't, they would write java or any current top 20 programming languages. So almost all optimization off looks ok. Reasonable compared to this, anyhow.
- rowanG077 5y agoI would assume it doesn't divert because the user cannot tell from the output of the program if a memset is optimized away. If you want the memset itself to be observable you need to use volatile or memset_s. Else you are not describing your intent properly If people truly still think C is a macro assembler then that's the problem. Besides if you care deeply about how modern high performance architectures won't cut it anyway.
- Gibbon1 5y agoI think the thing is users of C compilers generally care about raw performance much much less than compiler maintainers who are universally using C++. Compiler writers are stuck in a trap. C++ compilation model is broken. Which makes compiling C++ programs very slow. Which means compiler writers care a lot about how fast compilers are. So they desperately add more optimizations to speed up the compiler program. But which adds more work to the process of compiling a program. Most of the other users, especially C programmers don't care about speed nearly as much. Notably because while the compilation model for C is also broken, it's not nearly so. So their programs compile in a few seconds, not minutes to hours.
- MauranKilom 5y agoI submit that this viewpoint is very mistaken. If it were true, "users of C compilers" would just compile with optimizations off and there would not be any problem. Evidently, "most of the other users" do care about performance. Unsurprisingly, I might add.
- Gibbon1 5y agoIf I am mistaken why do most programmers prefer slower to vastly slower languages such as JavaScript, Java, C#, Go, Python, PHP, or Lua? If they really thought that speed was the most important thing wouldn't that abandon those languages for C++. Explain yourself.
- rowanG077 5y agoIt's the opposite. People use C and C++ because of their speed. If you don't need the speed then there is little reason to use C or C++. This makes these optimization absolutely vital for C and C++.
- dmz73 5y agoI think a lot (not all) of people will use C and C++ because they need good performance, compile time checks, portability across OS/CPU architectures and reasonable memory usage. Most of the people who use C and C++ are average programmers who think their programs will do exactly what they wrote in the source code. The issue is that optimizations are required to get expected performance but some optimizations will result in programs not doing what user specified in the source code. Compiler should offer a clear split between "safe" optimizations that will not change what source code says and "unsafe" optimizations that will do their best to create fastest code. I don't use C or C++ very often and I don't know how optimizations are currently structured but if a lot of people are constantly caught unaware of what optimizations are in use and how they affect the output then this is obviously either a documentation issue or compiler interface issue - both of these are up to compiler writers to fix.
- MauranKilom 5y agoI am deeply confused by your argument, for the simple reason that you can just turn off optimizations. In fact, it's literally the default in most compilers to have no optimization, you have to explicitly request them. Are you actually complaining that a compiler told to optimize is... optimizing? > How likely do you think is it that a program that contains memset and has this optimisation applied how diverts from the indented behaviour and now has a serious flaw in it? What if this optimization happens after three levels of inlining and some other dead code elimination? Is that "diverting from intended behavior"?
- marcosdumay 5y ago> How likely do you think is it that a program that contains memset and has this optimisation applied how diverts from the indented behaviour and now has a serious flaw in it? Almost every time. Yeah, the times when it leads to problems are more important individually. And I have no idea of the overall picture. But looking purely at the frequency, those you enumerate basically never happen. C really needs a "I mean this!" marker that one can use on those cases. Rust also would gain from some kind of predictable region similar to unsafe, but C would have to gain it first.
- kllrnohj 5y ago> When people write C, they often do so for specific domains. The article is about C++ which people choose because they want to go fast. Which is also the dominant reason people choose C (embedded & device drivers both absolutely care about performance & efficiency, too, after all). You can't have both "C is fast" and also "compilers can't optimize." That's not how that works. Similarly if you're just starting out in crypto and you're reaching for C you're already in a bad place and atomic optimizations are the least of your concerns. C is a terrible language for crypto.