vector.resize() taking a short time on AMD, a long time on Intel

[Jim Langston]

I really am not sure if this question belongs in this newsgroup, but not
sure where else to ask it.

There is someone working on a game that I tested, and it was taking >30
seconds to load. He stated that everyone else was taking 2 or 3 seconds.
Then he found one other person taking >30 seconds, and it turns out the
common denominator was both of us have Intel chips (Celeron) where the other
people have AMD.

I had him send me his code and he was doing a lot of .resize() in nested
vectors.

surfmap->IDR[surfindex].resize(bpgmap->width);for(y=0;ywidth;++y) {
surfmap->IDR[surfindex][y].resize(bpgmap->height+2); }
surfmap->IDG[surfindex].resize(bpgmap->width);for(y=0;ywidth;++y) {
surfmap->IDG[surfindex][y].resize(bpgmap->height+2); }
surfmap->IDB[surfindex].resize(bpgmap->width);for(y=0;ywidth;++y) {
surfmap->IDB[surfindex][y].resize(bpgmap->height+2); }
surfmap->IDA[surfindex].resize(bpgmap->width);for(y=0;ywidth;++y) {
surfmap->IDA[surfindex][y].resize(bpgmap->height+2); }

I looked at this and had him display clock() times before and after, and
sometimes this block of code would take >200ms on our Intel chips, but
ususually ~30ms on AMD.

I wrote a class for him that allocated the block of memory with one call to
new and gave him accessors which he replaced this with and now clock is
reporting 0 ms on AMD (haven't tested it on Intel yet).

My question is, why would the .resize() take so much longer on Intel than
AMD? Is it something specific to the Celeron maybe?

Before I rewrote it as a class for him I had considered things such as
..clear() .reserve() but that didn't immediately update the .size() for the
vector, and I think the class is the best way to go after all.

 

[Ian Collins]

I really am not sure if this question belongs in this newsgroup, but not
sure where else to ask it.

There is someone working on a game that I tested, and it was taking >30
seconds to load. He stated that everyone else was taking 2 or 3 seconds.
Then he found one other person taking >30 seconds, and it turns out the
common denominator was both of us have Intel chips (Celeron) where the other
people have AMD.

I had him send me his code and he was doing a lot of .resize() in nested
vectors.

Have a look at the code generated for the constructors of whatever is in
the vector, resize defaults to the object's default constructor to
initialise the new elements.

Before I rewrote it as a class for him I had considered things such as
..clear() .reserve() but that didn't immediately update the .size() for the
vector, and I think the class is the best way to go after all.

reserve doesn't initialise the vector's elements, unlike resize which does.

 

[Jim Langston]

Have a look at the code generated for the constructors of whatever is in
the vector, resize defaults to the object's default constructor to
initialise the new elements.

reserve doesn't initialise the vector's elements, unlike resize which
does.

Yes, this I know, but right after he did the resize he was iterating through
all the vectors initializing them anyway. But the issue of the .size() not
being right caused problems such as this:

std::vector<int> MyVec;
MyVec.reserve(100);
MyVec[50] = 10;

This worked on my compiler with my settings but barfed on his machine
stating that it was an array overflow.

 

[Ian Collins]

reserve doesn't initialise the vector's elements, unlike resize which
does.

Yes, this I know, but right after he did the resize he was iterating through
all the vectors initializing them anyway. But the issue of the .size() not
being right caused problems such as this:

std::vector<int> MyVec;
MyVec.reserve(100);
MyVec[50] = 10;

This worked on my compiler with my settings but barfed on his machine
stating that it was an array overflow.

It probably should barf, reserve simply reserves memory, it doesn't
initialise anything else. size() will be unchanged, capacity() will
reflect the new allocation.