Quotes of the week [LWN.net]

Telling the computer vs telling the reader

Posted Mar 22, 2012 10:44 UTC (Thu) by elanthis (guest, #6227) [Link]

In a purely academic sense, I agree with you, and wish that were the way of the world. Unfortunately, sometimes those two views just do have to be one and the same. At sufficiently human-friendly high levels of abstraction, general solutions to computational problems do not directly map to the way that computers actually work, and any form of automatable translation from that solution to computer instructions with today's technologies (much last yesterday's) will be inherently inefficient. For use cases where even small linear efficiency improvements matter, it's critical to write code that a computer can execute efficiently, and for trained programmers to be able to both write and read that code.

That of course includes much/most kernel code.

Note that there's still a big difference between unmaintainable efficient code and readable sane efficient code. In cases where it's hard to make code both, use comments and heavily describe the black magic in the code.

Telling the computer vs telling the reader

Posted Mar 23, 2012 2:14 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

It's more of a direction than a destination, so other factors such as runtime efficiency do weigh in.

But if you looked at my C code and typical C code where both do the same thing, even if there is no appreciable difference in execution cost, you would see an obvious pervasive difference. The author of the typical code was thinking of von Neumann CPUs when he wrote it; you can almost see the program counter turning in your head as the lines of C go by. It treats variables like registers, you can clearly see branching going on, and you won't see "const" anywhere, since that doesn't affect generated code.

const absolutely affects generated code

Posted Mar 30, 2012 21:03 UTC (Fri) by cbf123 (guest, #74020) [Link]

Declaring something as const allows the compiler to make assumptions about it that it would otherwise not be able to make. This can result in more efficient object code.

That said, I'm firmly in the "comment why you are doing something, not what you are doing" unless the mechanics of what is being done is non-obvious enough to need explanation. It needs to be readable by the next person to look at it (which may be yourself in ten years by which time you've forgotten all the details).

const absolutely affects generated code

Posted Mar 31, 2012 2:31 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

I know the theory that the compiler can do better optimization with const, but I've never been able to isolate a particular case where it does. In any case, I know the vast majority of my consts won't affect generated code, and the main reason is that they are on variables private to the compilation unit, so the compiler can see without my help whether the variable gets set or not.

"assert" is similar. The original theory behind a coded assertion is that it could help the compiler generate better code, but I'm pretty sure that has never been realized. I use lots of asserts and the purpose is neither to generate better code nor to make the program crash when the assertion fails. Like const, it's to help the reader read the code.

const absolutely affects generated code

Posted Apr 2, 2012 13:08 UTC (Mon) by jwakely (subscriber, #60262) [Link]

In a few rare cases, yes. But usually adding const doesn't change anything.

If the variable definition and everything you do to the variable is visible to the compiler (either because it's all in one file or you have global optimisation) then the compiler knows if it's modified or not, adding const doesn't help optimisation. If the definition is in one translation unit but most operations on it are in different translation units which get a pointer-to-const (or reference-to-const) those other TUs can't know whether the variable was really declared const, adding const to the definition doesn't help optimisation.

http://www.gotw.ca/gotw/081.htm