Jump to content
  • Advertisement
Sign in to follow this  
ccanan

Is const good for efficiency?

This topic is 4126 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Besides telling the compiler "don't modify me"? Does the compiler will do more optimization work for const? Thx in advance;

Share this post


Link to post
Share on other sites
Advertisement
What Herb Sutter has to say on the subject

Having a const pointer/reference to an object doesn't mean it is constant, it means you can't modify it, so there aren't as many opportunities for optimisation as might seem.


int x = 0;

void f(const int* p)
{
std::cout << *p << std::endl;
++x;
std::cout << *p << std::endl;
}

int main()
{
f(&x);
}

Share this post


Link to post
Share on other sites
If something is const, mark it as const. Don't bend over backwards to make stuff const when it really isn't.

const-correctness is a very good thing for code quality, and (at least in VS 2003) there _are_ places that the compiler optimizes better when you use const, but in general the compiler will figure things out whether you use const or not.

const is good for efficiency because it will reduce development time by pointing out some kinds of programming mistakes. Less development time means more time left over for profiler-guided optimization at the end.

Share this post


Link to post
Share on other sites
Quote:
Original post by SamLowry
What Herb Sutter has to say on the subject

Having a const pointer/reference to an object doesn't mean it is constant, it means you can't modify it, so there aren't as many opportunities for optimisation as might seem.


int x = 0;

void f(const int* p)
{
std::cout << *p << std::endl;
++x;
std::cout << *p << std::endl;
}

int main()
{
f(&x);
}


Of course, this code is truly terrible. Aliasing like this is, in my humble experience, bad. Assuming I saw no reason to flush the stream twice in f(), I would see no reason, looking at f(), that I couldn't write:
void f(cont int*p)
{
++x;
std::cout << *p << "\n" << *p << std::endl;
}

If I were being a good boy, I'd probably spend a couple hours tracking down why the original author placed the ++x; in between the two outputs. If I was being naughty, I'd just change it and get really confused when the results changed.

But that's beside the point since that's perfectly legal code that the compiler must handle correctly. More relevantly, I remember once turning on icc's "tell me why you didn't vectorize everything" option and in many cases it was because it couldn't prove there was no aliasing even though I knew there wasn't. This is why C99 introduced the "restrict" keyword.

Share this post


Link to post
Share on other sites
Declaring actual variables as const rather than pointers or references gives the compiler more opportunities for optimization and is a good idea for code quality reasons as well. Compilers can definitely take advantage of const declarations on local variables for optimization.

Share this post


Link to post
Share on other sites
Quote:
Original post by mattnewport
Declaring actual variables as const rather than pointers or references gives the compiler more opportunities for optimization and is a good idea for code quality reasons as well. Compilers can definitely take advantage of const declarations on local variables for optimization.


For a local variable, couldn't the compiler just see that it was never modified and do the optimizations regardless of whether or not the variable was const?

Share this post


Link to post
Share on other sites
Quote:
Original post by Deyja
[...]Const isn't an optimization.
except in rare cases.
It doesn't matter either way, though, because you should use it wherever it is appropriate and no more or less.

Share this post


Link to post
Share on other sites
Quote:
Original post by Way Walker
Quote:
Original post by mattnewport
Declaring actual variables as const rather than pointers or references gives the compiler more opportunities for optimization and is a good idea for code quality reasons as well. Compilers can definitely take advantage of const declarations on local variables for optimization.


For a local variable, couldn't the compiler just see that it was never modified and do the optimizations regardless of whether or not the variable was const?


// Evil might cast away the constness of its argument.
void evil (const Vector & p);

void good ()
{
Vector x;
const Vector y;
for (int i = 0; i < std::eleventy_billion; ++i) {
// The compiler cannot assume that "x" won't be modified just because it is
// passed as const; casting the const away here has defined behaviour.
evil(x);
// But here the compiler *can* assume that "y" won't be modified because,
// even if the constness is cast away and it *is* modified, the
// consequences of doing so are undefined.
evil(y);
// The compiler can't move this addition out of the loop because "x" might
// legitimately have its value changed.
do_something(x + y);
// OTOH, this multiplication can be moved out of the loop because even if
// evil changes the value of "y", the consequences are undefined.
do_something_else(y * y);
}
}




(Assuming Vector contains no mutable members.)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!