[jblow]

This is true (especially: breaking vectorization). But premature optimization is not a good idea, and if you are doing real optimization, you are going to rewrite that piece of code 10 times anyway, so it is in a different class of problem and the putty stuff I was saying before does not apply (i.e. this code is in the 1% or so of the codebase that is highly performance-sensitive).

Optimized code is just a different thing from general code (if one is a productive programmer).

[dchichkov]

And again it depends. I would return to a simple example of passing a parameter by a const reference.

When you are writing this const in the "const std::string &name" you are 1) constraining developers from breaking things 2) making the code more efficient 3) providing clues to other developers 4) providing clues to optimizer.

All of these points are important to some degree. And it is just the same, when you are writing this assignment.

And writing efficient code that provides all these clues in every way possible (including consistently and meaningfully arranging the white spaces) is certainly a good idea. Funny thing, that with experience it doesn't take extra time to do that. You just write it, and it comes out in the right way: readable, efficient and optimal down to CPU microcode and aligned memory accesses.

[jblow]

I think we have different ideas about what constitutes optimization.

Sure, putting const in parameter declarations is easy to do. It may even buy you a little bit of speed because the compiler is a little bit clearer about pointer aliasing and whatever. But it's not going to make a difference in the equivalence classes of slow code / fast code / Really Fast Code.

Serious hardcore optimization usually involves changing the way the problem is solved to something different than the way the old code thought about it: either constraining the problem space further, or attacking it from a different direction. This usually involves rewriting everything since there are so many cross-cutting concerns. Sometimes one has to do this several times to figure out which way is really fastest. Microoptimization things, like whether you used const somewhere or not, are much smaller details that have correspondingly small effects.

For code that one isn't specifically optimizing, speed probably doesn't matter. There was an exception to this, where we hit a little bit of a bump in the late-2000s on platforms with in-order CPUs like the PlayStation 3 and Xbox 360, because they have such a high penalty on cache misses; this tended to make general-purpose code slower and result in much flatter profiles. But now we are pretty much out of that era.

In general, const is more of a protection than an optimization. This is especially true heading into the massively parallel future, where const just sort of tells you whether some code is known for sure to run safely in parallel or not... and running safely in parallel matters tremendously more to overall speed than the number of instructions in that bit of code, or whatever. (Anyway, C++ is not at all a viable language in the massively parallel future... so that is going to be interesting.)

[dchichkov]

Thanks. I've really enjoyed that discussion with you. And by the way, your comment mentioning several decades of experience was certainly appropriate.

[jblow]

Yeah, this discussion went a lot better than the other one! Certainly more enjoyable, anyway.

[gsg]

Constness of parameters has zero effect on optimisation. Const declarations may provide a small benefit.

Go ahead and apply const as you see fit, but don't expect better code out of it.

[dchichkov]

Would you guarantee that for every implementation of every C++ compiler ever? Especially considering that constexpr is already there?

So, I'd rather leave these clues to the compiler/optimizer.

[gsg]

Constness of pointer or reference parameters has no optimisation effect because it doesn't convey any reliable information. It doesn't indicate whether the thing is written to in the body of the function (the compiler already has that information). It doesn't indicate whether the thing can be written to through another pointer (const parameters may be aliased). And it doesn't indicate whether the thing is written to through the same pointer by a callee (because the language contains const_cast).

Since the very thing that const is supposed to indicate is "no writes", and it doesn't do that, const annotations provide zero information. Thus they add no scope for optimisation.

constexpr isn't relevant to this issue. Since sane programs don't spend any appreciable time calculating constants, it's also rather uninteresting for the purpose of making programs run fast. As far as I can see its only practical purpose is to expand the set of fixed terms allowed as template arguments.

[dchichkov]

Would you guarantee that optimizers wouldn't use heuristics at IPO stage?

Either way, you are right, and my comment should have been: 1) constraint 2) providing clues to developers 3) providing clues to optimizer.

[gsg]

Without yielding useful information, const annotations can't hope to have any positive effect on compiler optimisations, fancy or not.

I agree that const is useful for the other reasons you mention.

[georgeorwell]

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

[lttlrck]

Who's to say that code isn't the tenth iteration? Especially given the context of the discussion...