A tale of two compilers
-
Recently I've been doing some cross platform development for a client on Windows, Linux and Solaris. So the code is pretty plain vanilla with (lots of) splashings of boost and stl. The point of the app is to process and report on transactions each night, and there are in the order of millions of transactions to process each night - so speed was of the escence. For Win32 I chose the good old VS.NET 2003 compiler, and for *nix I chose GCC. I also downloaded CodeBlocks (with GCC 3.4.4) on Win32 to do the port work. My point, and I'm getting there slowly I know :doh:, was the difference produced by the compilers speed optimisations. So basically I set the compilers speed optimisations "full on" without any preference for processor affinity and the difference was quite surprising; - GCC on Win32 produced release code about 10x as large as VS.NET but which executed 1/3rd faster!! - A GCC build on *nix ran pretty much the same speed (in tx throughput) as GCC on Win32, showing an improvement (on *nix) of around 10% The tests were done on the same hardware, using the same test data, all extraneous processes shutdown etc. I didn't do whole program optimisation in VS.NET, not sure if that would have made much difference. I guess there's a lot of optimisations GCC does but VS.NET doesn't, GCC certainly has enough switches for speed optimisations :) Phil Harding.
myBlog [^] | mySite [^]Phil Harding wrote:
GCC on Win32 produced release code about 10x as large as VS.NET but which executed 1/3rd faster!!
Didi you try stripping it (strip should be in the GCC toolset), and if so, how big was it after that ? I recently had to build an executable with Haskell[^] using GHC[^]. It compiled to 12MB, but to around 4 when stirpped...
-
Phil Harding wrote:
- GCC on Win32 produced release code about 10x as large as VS.NET but which executed 1/3rd faster!! - A GCC build on *nix ran pretty much the same speed (in tx throughput) as GCC on Win32, showing an improvement (on *nix) of around 10%
Good stuff, Phil - thanks for sharing. This is doubly interesting because of how much GCC usually gets dumped on in benchmark tests. Just goes to show how much the real world can deviate. Would love to see how much the results differ when using whole program optimization.
Now taking suggestions for the next release of CPhog...
-
That's neat to hear. Out of curiosity though was this the plain old vanilla gcc or the one of the optimized versions (note, they can appear the same) with favoritism towards a CPU (for instance, the Pentium optimized gcc)? If that's the case, what kinda comparability would you get if you optimized VS8 for the Pentium CPU (is there a way for that?) and tried again? I'm not a Microsoftie at all (Unix nut and proud of it); I just want to make sure we're comparing apples to apples. Jeremy Falcon
-
If you set the VS compiler for all optimizations, you're probably making it schitzo trying to figure out whether it should optimize for size or speed. Try one or the other, but not both. They tend to be mutually exclusive. And comparing optimizations between compilers without understand what each optimization does is like comparing moon dust with a fine Brie and saying they're both cheese. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures -- modified at 21:14 Thursday 9th March, 2006
Marc Clifton wrote:
If you set the VS compiler for all optimizations
I only set options for speed optimisation not size.
Marc Clifton wrote:
And comparing optimizations between compilers without understand what each optimization does...
Too true, there are alot of speed optimisations in GCC which aren't present (at least not advertised) in VS, my point was using the tools provided and setting all the speed optimisations available, the fastest code was produced by GCC. There was no tinkering involved, just a quick consultation of the compiler docs to see which switches were described as providing the most speed optimisations. Not scientific I know, but then I'm not a scientist :) Phil Harding.
myBlog [^] | mySite [^] -
Did you optimize vs.net for size or speed? I think the default optimizations are for size which cuts down on code size and reduces things like inlining. This reduces loading time and page faults from swapping out code, but those optimizations probably don't help your app very much when data probably dominates most of the memory access.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
Phil Harding wrote:
GCC on Win32 produced release code about 10x as large as VS.NET but which executed 1/3rd faster!!
Didi you try stripping it (strip should be in the GCC toolset), and if so, how big was it after that ? I recently had to build an executable with Haskell[^] using GHC[^]. It compiled to 12MB, but to around 4 when stirpped...
-
Recently I've been doing some cross platform development for a client on Windows, Linux and Solaris. So the code is pretty plain vanilla with (lots of) splashings of boost and stl. The point of the app is to process and report on transactions each night, and there are in the order of millions of transactions to process each night - so speed was of the escence. For Win32 I chose the good old VS.NET 2003 compiler, and for *nix I chose GCC. I also downloaded CodeBlocks (with GCC 3.4.4) on Win32 to do the port work. My point, and I'm getting there slowly I know :doh:, was the difference produced by the compilers speed optimisations. So basically I set the compilers speed optimisations "full on" without any preference for processor affinity and the difference was quite surprising; - GCC on Win32 produced release code about 10x as large as VS.NET but which executed 1/3rd faster!! - A GCC build on *nix ran pretty much the same speed (in tx throughput) as GCC on Win32, showing an improvement (on *nix) of around 10% The tests were done on the same hardware, using the same test data, all extraneous processes shutdown etc. I didn't do whole program optimisation in VS.NET, not sure if that would have made much difference. I guess there's a lot of optimisations GCC does but VS.NET doesn't, GCC certainly has enough switches for speed optimisations :) Phil Harding.
myBlog [^] | mySite [^]Without profiling it is hard to tell, but I would bet money it was the use of STL that made the difference. Dinkumware STL that ships with VC++ is simply pathetic when it comes to speed, and getting worse from one version to another. On the other hand, GNU library that ships with g++ 3.x and up is really well optimized. I would try to use STLPort with both compilers and then see the results.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
Recently I've been doing some cross platform development for a client on Windows, Linux and Solaris. So the code is pretty plain vanilla with (lots of) splashings of boost and stl. The point of the app is to process and report on transactions each night, and there are in the order of millions of transactions to process each night - so speed was of the escence. For Win32 I chose the good old VS.NET 2003 compiler, and for *nix I chose GCC. I also downloaded CodeBlocks (with GCC 3.4.4) on Win32 to do the port work. My point, and I'm getting there slowly I know :doh:, was the difference produced by the compilers speed optimisations. So basically I set the compilers speed optimisations "full on" without any preference for processor affinity and the difference was quite surprising; - GCC on Win32 produced release code about 10x as large as VS.NET but which executed 1/3rd faster!! - A GCC build on *nix ran pretty much the same speed (in tx throughput) as GCC on Win32, showing an improvement (on *nix) of around 10% The tests were done on the same hardware, using the same test data, all extraneous processes shutdown etc. I didn't do whole program optimisation in VS.NET, not sure if that would have made much difference. I guess there's a lot of optimisations GCC does but VS.NET doesn't, GCC certainly has enough switches for speed optimisations :) Phil Harding.
myBlog [^] | mySite [^]> GCC on Win32 produced release code about 10x as large as VS.NET but which executed 1/3rd faster!! Out of curiosity, is that because Visual Studio expects and run with other dlls ? I mean MSVCRT.DLL for example. Did you try to compare the dll that the program link to ? BTW: I like this sort of article where we discuss facs and not 'near religious' programming beliefs.
-
> GCC on Win32 produced release code about 10x as large as VS.NET but which executed 1/3rd faster!! Out of curiosity, is that because Visual Studio expects and run with other dlls ? I mean MSVCRT.DLL for example. Did you try to compare the dll that the program link to ? BTW: I like this sort of article where we discuss facs and not 'near religious' programming beliefs.
Pascal Ganaye2 wrote:
Out of curiosity, is that because Visual Studio expects and run with other dlls
Not really, MSVCRT.DLL (on Win32) is loaded at startup (not using delay loading or any other DLL's), and the performance was measured at the application level by monitoring transaction throughput levels. One thing I didn't bottom out, as mentioned by a previous poster, is the STL implementations are different on both platforms - a better indication would be if I was using , say, STLPort on both platforms. This agrees somewhat with the profiling I did using the Compuware Devpartner Profiler Community Edition[^], which is a great [free] tool by the way, easily comparable to Rational Quantify. Phil Harding.
myBlog [^] | mySite [^] -
Pascal Ganaye2 wrote:
Out of curiosity, is that because Visual Studio expects and run with other dlls
Not really, MSVCRT.DLL (on Win32) is loaded at startup (not using delay loading or any other DLL's), and the performance was measured at the application level by monitoring transaction throughput levels. One thing I didn't bottom out, as mentioned by a previous poster, is the STL implementations are different on both platforms - a better indication would be if I was using , say, STLPort on both platforms. This agrees somewhat with the profiling I did using the Compuware Devpartner Profiler Community Edition[^], which is a great [free] tool by the way, easily comparable to Rational Quantify. Phil Harding.
myBlog [^] | mySite [^]I was speaking about the size sorry I meant Is that because Visual Studio expects and run with other dlls that the objects code is smaller. For the speed aspect, I am not worried by a 10% difference in speed. I would be more if it was memory waste. Algorithm makes the difference. http://www.codeproject.com/dotnet/macmahon.asp[^]