Jump to content
  • Advertisement
Sign in to follow this  
Mawww

are c++ optimizers stl-aware ?

This topic is 4624 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

well, for example, when looping through a vector you do something like that : for (std::vector<thing>::iterator iter = v.begin(); iter != v.end(); ++v) {...} my question is, does optimizers look at the code in the "for" in order to see if v.end() may change between iterations ? If v.end() do not change, we can save a function call per iteration...

Share this post


Link to post
Share on other sites
Advertisement
Considering that end() is a template function, the result of the expansion of end() is usually examined during the optimization of the loop, so will often be optimized. A stupid compiler, a bad vector implementation or a too deeply nested loop may cause the end() call not to be optimzied out.

Share this post


Link to post
Share on other sites
It depends on what you do with the vector. If you've shared the vector with any non-inlined functions as a non-constant reference prior to the loop and call any more such functions from the middle of the inner loop then the compiler is forced to assume that it will change. And since you're never updating the iterator when the vector actually changes you may as well cache it if it's a performance consern.

Something like this is virtually guaranteed to check the end each iteration (I know it's a bad example, but still..):
for(std::vector<Actor>::iterator i = gActors.begin(); i != gActors.end(); ++i) {
i.update();
}

Share this post


Link to post
Share on other sites
This isn't that different to a lot of C loops, e.g.:

int i;
for (i = 0; i < data->length; ++i) {...}

Since the compiler will expand end() as an inline function hopefully the result will be pretty much the same and so it will make the same assumptions as it would about a similar C loop. gcc doesn't seem to do things like this perfectly however (according to my timing measurements at least).

Share this post


Link to post
Share on other sites
Quote:
Original post by ZQJ
This isn't that different to a lot of C loops, e.g.:

int i;
for (i = 0; i < data->length; ++i) {...}

Since the compiler will expand end() as an inline function hopefully the result will be pretty much the same and so it will make the same assumptions as it would about a similar C loop. gcc doesn't seem to do things like this perfectly however (according to my timing measurements at least).
True, but what's C got to do with anything?
In both languages the "solution" is to simply cache the end-point in a local variable prior to the loop.

Quote:
Original post by SiCrane
Considering that end() is a template function, the result of the expansion of end() is usually examined during the optimization of the loop, so will often be optimized. A stupid compiler, a bad vector implementation or a too deeply nested loop may cause the end() call not to be optimzied out.
Considering that the vast majority of my code isn't inlined and use virtual functions and that most loops (although often not the critical inner loops) call such functions I'd say that the compiler can, in practice, rarely make such assumptions.
It does depend a lot on your coding style however..

Share this post


Link to post
Share on other sites
Actually some might say the question should perhaps be the other way around - "Are STL writers optimiser-aware?"
And the answer is most certainly yes.

Share this post


Link to post
Share on other sites
Quote:
Original post by doynax
Considering that the vast majority of my code isn't inlined and use virtual functions and that most loops (although often not the critical inner loops) call such functions I'd say that the compiler can, in practice, rarely make such assumptions.
It does depend a lot on your coding style however..


If you're calling virtual functions (or any function really) I'd say one memory load (probably from cache) is the least of your worries performance-wise.

Share this post


Link to post
Share on other sites
Quote:
Original post by ZQJ
Quote:
Original post by doynax
Considering that the vast majority of my code isn't inlined and use virtual functions and that most loops (although often not the critical inner loops) call such functions I'd say that the compiler can, in practice, rarely make such assumptions.
It does depend a lot on your coding style however..


If you're calling virtual functions (or any function really) I'd say one memory load (probably from cache) is the least of your worries performance-wise.
Probably, but it all adds up. And there's a whole lot of iteration going on in most games..
Consider things like small math functions optimized for multiple instruction sets called through virtual functions, or a very similar 32 to 16-bit color converter used in most of the image loaders of my current project.

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!