# 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.

## 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 on other sites
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 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 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 on other sites
Quote:
 Original post by ZQJThis 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 SiCraneConsidering 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 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 on other sites
Quote:
 Original post by doynaxConsidering 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 on other sites
Quote:
Original post by ZQJ
Quote:
 Original post by doynaxConsidering 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 on other sites
Moral: use for_each whenever feasable. Let the library authors worry about the proper way to bound your loops.

CM

• 18
• 11
• 20
• 9
• 52
• ### Forum Statistics

• Total Topics
631397
• Total Posts
2999812
×