5 ms·

VC++ generates significantly better code than GCC. Enough so that performance-minded projects usually wouldn't consider MinGW/GCC for Windows code.

by TwoBit 15y ago

viraptor 15y ago
Does it matter during development though? You could always develop on GNU toolchain and then make a final build in VC once the feature code is complete.
- dagw 15y ago
  Only if you are careful to only use the subset of the C++ spec supported by both compilers and avoid all gcc specific features.
  - viraptor 15y ago
    I mentioned that in a context of application which is crossplatform already and when something is being developed, it affects (in most cases anyways) all platforms in the same way - so this limitation is "built-in" already.
  - 16s 15y ago
    In my experience, you don't have to be careful. I've written lot's of C++ that compile fine on Windows (using mingw/msys) or Linux/Mac using gcc. Can you provide an example of where gcc specific features are included w/o the developer explicitly doing so?
  - Impossible 15y ago
    This is pretty common and not particularly difficult. Most large cross-platform C++ projects (ie most browsers and game engines) compile in both gcc and msvc. It is easy to naively write code in one compiler that won't build in another, but it's also easy to fix said code once you try to build it with another compiler.
  - groby_b 15y ago
    Which might be a good choice for working on Chromium anyways, what with it being cross-platform :) (Granted, there might be windows-specific stuff. I haven't checked the windows code)
  - jlarocco 15y ago
    They would be doing this anyway.
- TwoBit 15y ago
  I actually don't understand the original poster's slowness with Windows. We use Perforce and VC++ .slns, sometimes with apps split into DLLs and get none of the slowness the poster talks about. Actually we get significantly better performance with this than under Unix with GCC. No-change or small change rebuilds take a few seconds, with the time being dominated by the link and proportional to the link size.
gillianseed 15y ago
Please show me something to back this nonsense up.
- hemancuso 15y ago
  How about you back up calling it nonsense?
  - gillianseed 15y ago
    We've done compiler tests between VC express 2010 and GCC (Mingw gcc 4.6.x branch) at work with GCC beating VC express at '-O3 -ffast-math -march=corei7' vs '/O2 /arch:SSE2' for our code on Intel Core i7 nehalem. GCC even beat ICC on certain tests on that same Intel hardware. What we weren't able to compare between the compilers was link-time optimization and profile-guided optimization since Microsoft crippled VC express by removing these optimizations. So when someone makes claims that 'VC++ generates significantly better code than GCC' I want to see something backing that up. Had I made a blanket statement that 'GCC generates significantly better code than VC++' someone would call me on backing up that aswell, and rightly so.
    - CurtHagenlocher 15y ago
      So when you didn't use the two most important perf features in MSC, its performance was underwhelming. This is no surprise. Also, if you were doing anything heavily floating-point, MSC 2010 would be a bad choice because it doesn't vectorize. Even internally at Microsoft, we were using ICC for building some math stuff. The next release of MSC fixes this.
      - gillianseed 15y ago
        Well we obviously didn't enable PGO/LTO for GCC either when doing these tests as that would have been pointless. It would have been interesting to compare the quality of the respective compiler's PGO/LTO optimizations (particularly PGO given that for GCC and ICC code is sometimes up to 20% faster with that optimization) but not interesting enough for us to purchase a Visual Studio licence. And yes we use floating point math in most of our code, and if MSC doesn't vectorize then that would certainly explain worse performance. However this further denies the blanket statement of 'VC++ generates significantly better code than GCC.' which I was responding to.

VC++ generates significantly better code than GCC. Enough so that performance-minded projects usually wouldn't consider MinGW/GCC for Windows code.

by TwoBit 15y ago

VC++ generates significantly better code than GCC. Enough so that performance-minded projects usually wouldn't consider MinGW/GCC for Windows code.

viraptor 15y ago

Does it matter during development though? You could always develop on GNU toolchain and then make a final build in VC once the feature code is complete.

dagw 15y ago
Only if you are careful to only use the subset of the C++ spec supported by both compilers and avoid all gcc specific features.
- viraptor 15y ago
  I mentioned that in a context of application which is crossplatform already and when something is being developed, it affects (in most cases anyways) all platforms in the same way - so this limitation is "built-in" already.
- 16s 15y ago
  In my experience, you don't have to be careful. I've written lot's of C++ that compile fine on Windows (using mingw/msys) or Linux/Mac using gcc. Can you provide an example of where gcc specific features are included w/o the developer explicitly doing so?
- Impossible 15y ago
  This is pretty common and not particularly difficult. Most large cross-platform C++ projects (ie most browsers and game engines) compile in both gcc and msvc. It is easy to naively write code in one compiler that won't build in another, but it's also easy to fix said code once you try to build it with another compiler.
- groby_b 15y ago
  Which might be a good choice for working on Chromium anyways, what with it being cross-platform :) (Granted, there might be windows-specific stuff. I haven't checked the windows code)
- jlarocco 15y ago
  They would be doing this anyway.
TwoBit 15y ago
I actually don't understand the original poster's slowness with Windows. We use Perforce and VC++ .slns, sometimes with apps split into DLLs and get none of the slowness the poster talks about. Actually we get significantly better performance with this than under Unix with GCC. No-change or small change rebuilds take a few seconds, with the time being dominated by the link and proportional to the link size.

gillianseed 15y ago

Please show me something to back this nonsense up.

hemancuso 15y ago
How about you back up calling it nonsense?
- gillianseed 15y ago
  We've done compiler tests between VC express 2010 and GCC (Mingw gcc 4.6.x branch) at work with GCC beating VC express at '-O3 -ffast-math -march=corei7' vs '/O2 /arch:SSE2' for our code on Intel Core i7 nehalem. GCC even beat ICC on certain tests on that same Intel hardware. What we weren't able to compare between the compilers was link-time optimization and profile-guided optimization since Microsoft crippled VC express by removing these optimizations. So when someone makes claims that 'VC++ generates significantly better code than GCC' I want to see something backing that up. Had I made a blanket statement that 'GCC generates significantly better code than VC++' someone would call me on backing up that aswell, and rightly so.
  - CurtHagenlocher 15y ago
    So when you didn't use the two most important perf features in MSC, its performance was underwhelming. This is no surprise. Also, if you were doing anything heavily floating-point, MSC 2010 would be a bad choice because it doesn't vectorize. Even internally at Microsoft, we were using ICC for building some math stuff. The next release of MSC fixes this.
    - gillianseed 15y ago
      Well we obviously didn't enable PGO/LTO for GCC either when doing these tests as that would have been pointless. It would have been interesting to compare the quality of the respective compiler's PGO/LTO optimizations (particularly PGO given that for GCC and ICC code is sometimes up to 20% faster with that optimization) but not interesting enough for us to purchase a Visual Studio licence. And yes we use floating point math in most of our code, and if MSC doesn't vectorize then that would certainly explain worse performance. However this further denies the blanket statement of 'VC++ generates significantly better code than GCC.' which I was responding to.