Forum Groups
  All forums
    Help & Feedback
      Work in progress
      Finished Art
      Non-Max related

Maxunderground news unavailable

Any coder with a C++ compiler around? I need a hand.
show user profile  Garp
If you have a compiler supporting C++ 11, please try this piece of code in release mode and post the result (along with your compiler specs). I'm baffled by what I get from VC++12.0.


read 506 times
1/21/2015 2:12:35 AM (last edit: 1/21/2015 2:14:39 AM)
show user profile  Mr_Stabby
VC++ 12 here too, i get


hint: iterator is not really a pointer and takes an extra step to dereference.

read 497 times
1/21/2015 2:52:57 AM (last edit: 1/21/2015 2:52:57 AM)
show user profile  Garp
Thanks, Stabby :)
I'm exchanging emails as we speak with the maintainer of the STL for Microsoft. We've pinned down the issue to the compiler being able to vectorize the loop on the array but not on the vector (even though vector iterators are just wrappers around raw pointers).

I'd be curious to see result from other compilers (g++, clang, etc). Any takers?

read 490 times
1/21/2015 3:12:33 AM (last edit: 1/21/2015 3:12:33 AM)
show user profile  Boomer

I'm not following what the issue is that you're seeing. BTW, I'm not suprised that the second implementation is slower as you are doing a compare with end(v) - the value of which I would expect to require a calculation on each iteration to obtain.


  Mathew Kaustinen

read 447 times
1/22/2015 5:22:05 PM (last edit: 1/22/2015 5:22:05 PM)
show user profile  Nik Clark
Using online compilers because I'm bored:

C++ shell:
198 ms
1816 ms

Visual C++
574 ms
12847 ms

read 443 times
1/22/2015 5:37:16 PM (last edit: 1/22/2015 5:37:16 PM)
show user profile  Garp
@Nik: Thanks for the attempt :) Online compilers don't quite cut it, though.

@Boomer: Vector iterators are supposed to be simple wrappers, meaning that compilers flatten them out. You can find several threads on stackoverflow showing with various compilers that the assembly output is identical to code using pointers directly.
The issue is (or rather was) that with msvc I got 40ms and 64ms. That's an extra 60%! So my reaction was 'Damn Microsoft! They screwed it up again'.
After working it out with the STL maintainer, it turns out to be the other way around: it's not iterators that are 'slower', it's pointers that are 'faster', thanks to autovectorization. The compiler is able to vectorize the loops with pointers but not the ones with iterators (yet). They're working on it, so perhaps we'll have something better for VS2015.
My little benchmark made it look like there's a bug, but nope, all is fine. What I do in the meantime is either use vectors only as RAII handles or vectorize the loops myself.

Anyway, issue solved. Thanks, folks.

edit: actually, if anyone is using clang or g++ or else, I'd still be curious to see what you get.

read 423 times
1/22/2015 11:48:00 PM (last edit: 1/23/2015 1:41:56 AM)
show user profile  Garp
Dammit. I should learn to read posts better.

@Boomer again: You were referring to the asymetry between the loops, right?
The reason I cached a guard past the end of the array is that + n was recomputed each time around (even though I'm not adding elements and n is const).
The reason I didn't cache v.end() is that it didn't change anything. The compiler was able to see that the iterator stays the same.

read 401 times
1/23/2015 12:35:57 PM (last edit: 1/23/2015 12:35:57 PM)
#Maxforums IRC
Open chat window