| |||||||||||||
Implications of pure and constant functionsImplications of pure and constant functionsPosted Jun 10, 2008 21:31 UTC (Tue) by nix (subscriber, #2304)Parent article: Implications of pure and constant functions Good article. Just one point. You say [...] sometimes, doing the optimization "manually", directly in the source code, makes it more readable, and makes the code resemble the output of the compiler more.I don't really see any advantage of making the code resemble the output of the compiler. This seems more like a disadvantage to me. (Also, the output of the compiler necessarily differs between compiler versions and targets, so any resemblance will be transient at best.)
(Log in to post comments)
Possible advantage Posted Jun 11, 2008 0:38 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
I'd say, from a little experience that it's an advantage during debugging. The closer the
resemblance between source and executable, the more chance you have of understanding what
you're seeing in the debugger.
If, for example, you used an unnecessary temporary, the debugger cannot show you the value of
that temporary. If you call a side-effect free function like strlen() several times the actual
code may call it just once, meaning that breaking on entry to strlen() will not do what you
expect. I recently deleted some code which read something like as follows...
int cache[CACHE_WIDTH];
if (!cache) {
log_critical("Could not allocate cache");
}
A naive programmer might be quite surprised to see his debugger skip the last three of those
lines during single stepping, but in reality not a single byte of code was emitted or executed
for them due to a trivial optimisation.
Possible advantage Posted Jun 13, 2008 16:17 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I don't really see any advantage of making the code resemble the output of the compiler. Hear, hear. There are two distinct ways to look at a program: 1) instructions to a computer; 2) description of the solution of a computational problem. The primary audience for (1) is a computer; for (2) it's a human. In view (2), a compiler's job is to produce a machine program that computes the solution described by the source code. A lot of programmers like to do that work themselves, but I think that is an inefficient use of brain power (for everyone who works on that code). The closer the resemblance between source and executable, the more chance you have of understanding what you're seeing in the debugger. That's definitely my experience. But there is a middle ground. I write human-oriented code and let the compiler do its job normally. But when I debug at the machine level I add -O0 to the compile options. That's usually described as "don't optimize", but as I consider optimization to be an integral part of the compiler's job, I view it as, "Make the machine program track the source code as closely as possible."
Possible advantage Posted Jun 17, 2008 21:38 UTC (Tue) by roelofs (guest, #2599) [Link] But when I debug at the machine level I add -O0 to the compile options. That's usually described as "don't optimize", but as I consider optimization to be an integral part of the compiler's job, I view it as, "Make the machine program track the source code as closely as possible.""...and watch your bug go away." :-) That seems to happen to me more often than not. Most recently it turned out to be a gcc code-generation bug, 32-bit only, 3.4.x only. (Pretty sure not related to const, though C++ is a different beast, so I'm not 100% certain.) Greg
Possible advantage Posted Jun 18, 2008 2:00 UTC (Wed) by giraffedata (subscriber, #1954) [Link] Of all the bugs I've analyzed with GDB, I'd say about 5% stop manifesting when I disable optimization. One was a compiler optimizer bug, one was me lying to the compiler (unintentionally, of course), and the rest were wild pointers causing stack corruption.Of course, this is mostly with older compilers. (The new ones are too slow for me).
|
|||||||||||||