VisualStudio is making slow programs!

[zoran404]

I've wrote an algorithm for threaded IntroSort. I use winapi for threading.
I've developed it using CodeBlocks and it's pretty fast, but when I take the same source code and compile it in VisualStudio Express 2013 it executes nearly 4 times slower.
I've tested it and it doesn't have anything to do with threading, the program simply runs 4 times slower for any number of threads I give them.

What is going on here? How come visual studio's programs are so slow?

http://prntscr.com/5jy974

I'm using codeblocks and visualstudio 2013 with their default compilers and settings.

[poteto]

Its because codeblocks uses the mingw compiler, and visual studios uses their msvc compiler.

What if you tried to do a more formal benchmark and remove debug flags?( unless you have already done so )

It would also be nice if you showed your code.

[htirwin]

I'm using codeblocks and visualstudio 2013 with their default compilers and settings.

To do a meaningful comparison, you would have to make a release build and turn on optimizations.

[JLBorges]

> VisualStudio Express 2013 it executes nearly 4 times slower.

Depends on the specific code really; each compiler (optimiser) has its own strengths and weaknesses. On an average, my experience is that the Microsoft compiler generates code that is about 30 to 50 percent slower than the GNU compiler. While there is not much of a difference between the LLVM and GNU compilers.

If optimisations were turned on in both builds, it is possible that your code hit the sweet spot of the GNU optimiser, and the weaknesses of the Microsoft one.

It is quite easy to write code that addresses the strengths of one implementation and the weaknesses of another.
For instance, if I wanted to showcase LLVM, and show GNU as well below par and Microsoft as poor, I could write:

#include <iostream>
#include <vector>
#include <algorithm>
#include <random>
#include <ctime>
#include <cmath>
#include <iterator>

template < typename ITERATOR, typename PREDICATE >
void do_sort( ITERATOR begin, ITERATOR end, PREDICATE cmp )
{
    if( begin == end ) return ;
    std::iter_swap( begin, std::min_element( begin, end, cmp ) ) ;
    ++begin ;
    do_sort( begin, end, cmp ) ; // tail call
}

int main()
{
     const std::size_t N = 1024 * 32 ;
     std::vector<double> seq ;
     seq.reserve(N) ;

     std::mt19937 twister ; // deliberately not seeded
     std::normal_distribution<double> stdnormal ;
     while( seq.size() < N ) seq.push_back( stdnormal(twister) ) ;

     const auto start = std::clock() ;
     do_sort( std::begin(seq), std::end(seq), []( double a, double b ) { return std::abs(a) < std::abs(b) ; } ) ;
     const auto end = std::clock() ;

     std::cout << (end-start) * 1000.0 / CLOCKS_PER_SEC << " msecs.\n" ;
}

LLVM clang++/libc++ -O3: 708.142 msecs. http://rextester.com/QPGP74332

GNU g++/libstdc++ -O3: 2255.22 msecs. http://rextester.com/EIWZV45218

Microsoft C++ (2013) /O2: 3525 msecs. http://rextester.com/LYJYP27461

[zoran404]

Yea, that example has very different execution times, but you used a lot of library calls there.
My program, besides the call to CreateThread (from windows.h, which isn't called many times) is all hand written code, just loops and recursion. Besides that I've already used registers to store some often used variables, so I don't see how any optimization could have noticeable effects.
I've tried the release mode with no differences.