Printable View
I want to try out the Microsoft compiler since I heard it can sometimes produce faster binaries than GCC on Windows, but am not planning to use the VS IDE. I am trying to figure out what I need to download, but the Microsoft website doesn't seem too helpful. If I only want to use the compiler from the command line (cl.exe), do I only need the Windows SDK? Can it compile 64-bit binaries? or does it have same restrictions as VS Express? and does it support PGO?
I suppose you could always download the entire package and just use the compiler. I think the Windows SDK affects what you can build, not how you build it, so you probably won't need it if you only intend to write command line programs using just the standard library, whether you use the VS IDE or not.
The reason I am asking is that according to some sources (including Wikipedia), VS Express doesn't support building 64-bit binaries (which is important for my chess program), but it's possible using cl.exe from the command line from Windows SDK, which seemed odd to me, since Windows SDK is included in VS Express? VS Express also doesn't support PGO, but that's of lesser concern to me.
At my last company, they were forever stuck in the 90's and using VC++ 6.0, and I remember when I needed to build a 64-bit DLL I had to use a makefile with the Windows SDK instead of VC++. So as for the 64-bit part of the question, yes, the SDK will let you build in 64-bit. As for whether you need VC++ at all, that would depend on whether the SDK comes with all the standard header files..., which I don't see why it would, since it's an SDK.
The Server 2008 SDK only installs the IA64 version of the PGO dll, however you can compile pgo enabled apps for any platform.
Ah I see. Thanks.
I don't need the win32 headers, though. Just the standard ones (and I will be compiling Boost).
Hmm I downloaded and installed the latest Windows SDK, and I don't see a cl.exe in there...
Apparently the compiler is installed into
C:\Program Files\Microsoft Visual Studio 9.0
instead of
C:\Program Files\Microsoft SDKs\Windows
Compiling Boost atm. It's taking forever for some reason (at least 30 minutes now). Only took 10-15 minutes with MinGW (GCC 4.4.0 SVN) IIRC.
What's MSVC's equivalent to GCC's "-O3"? The documentation seems confusing, with all those options for /O.
I triedCode:-OPTIMIZATION-
/O1 minimize space
/O2 maximize speed
/Ob<n> inline expansion (default n=0)
/Od disable optimizations (default)
/Og enable global optimization
/Oi[-] enable intrinsic functions
/Os favor code space
/Ot favor code speed
/Ox maximum optimizations
/Oy[-] enable frame pointer omission
Is that optimal?Code:cl /EHsc /Ox asdf.cpp
The resulting binary is a little bit (~5-10%) slower than the one produced by GCC 4.4.0 SVN (-O3), for my program.
How about...
Compiler: /Ox /Ob2 /Oi /Oy /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_CRT_SECURE_NO_WARNINGS" /D "_AFXDLL" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /GS- /Gy /arch:SSE2 /Za /Fo"Release\\" /Fd"Release\vc90.pdb" /W4 /nologo /c /Zi /TP /errorReport:prompt
Linker: /OUT:"D:\w00t\Documents\Visual Studio 2008\Projects\Temp\Release\Temp.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Release\Temp.exe.intermediate.manife st" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"d:\w00t\Documents\Visual Studio 2008\Projects\Temp\Release\Temp.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /LTCG /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT winmm.lib
Hmm okay thanks!
Time to go read the documentation...
Does anyone know how to build 64-bit Boost for MSVC?
I tried
As per some random page that came up from Google.Code:bjam --toolset=msvc-9.0_64 --build-type=complete msvc stage
Everything worked, but it still only produced 32-bit libraries.
Ah figured it out.
"address-model=64" is needed in addition to setting the toolset.
Code:bjam --toolset=msvc-9.0_64 --build-type=complete address-model=64 msvc stage
I did some benchmarking using my program (a chess engine), using its own benchmarking function (search 100 randomly pre-selected positions to a fixed depth, completely deterministic). Every "run" is run twice, and higher of the 2 taken (differences between runs were all within 1%). The numbers are Mnps (million nodes per second) searched. Higher the better.
I used 4 compilers - MSVC 9 64-bit, MSVC 9 32-bit, GCC 4.4.0 SVN 64-bit, GCC 4.2.1 32-bit.
For MSVC, I adopted relevant (optimization-related) options from the list Elysia posted.
The program does a lot of low level twiddling with 64-bit integers (called bitboards in computer chess), and is heavily recursive.
All the tests are run inside a VMware virtual machine running 64-bit XP Pro. Host is 64-bit Linux.
64-bit MinGW is my own build of GCC with mingw-w64 -
http://sourceforge.net/forum/forum.p...orum_id=723797
Code:MSVC 64-bit
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.21022.08 for x64
no optimization -
0.486265
/Ox -
1.52933
/Ox /Ob2 /Oi /Oy (Elysia's suggestion) -
1.55582
Code:MSVC 32-bit
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
no optimization -
0.392031
/Ox -
0.953033
/Ox /Ob2 /Oi /Oy (Elysia's suggestion) -
0.951351
Code:GCC (MinGW 64-bit)
gcc version 4.4.0 20081101 (experimental) (GCC)
-O3 -
1.74929
-O3 -march=native -
1.76843
For (unfair) comparison, on the Linux host, I get 2.585 Mnps. Didn't think virtualization would matter this much since this program is quite CPU-intensive.Code:GCC (MinGW 32-bit)
gcc version 4.2.1-dw2 (mingw32-2)
no optimization -
0.405505
-O3 -
1.04415
-O3 -march=native -
1.01338
As it appears, gcc 4.2.1 was only slightly (6%) faster than MSVC (both 32-bit), but gcc 4.4.0 SVN was quite a bit (14%) faster than MSVC (both 64-bits). Guess GCC people haven't been slacking off :). But I think even GCC 4.2.1 was released after MSVC 9, and GCC 4.4.0 is not even released yet. Too bad we can't get MSVC SVN.
BTW, does MSVC have something like "-march" for GCC (optimize for a specific target)? I can't seem to find it in the documentation.
None that I know of, really. Also keep in mind that both compilers can perform differently on different code.
And you did not seem to optimize with any SSE code either...
You are right of course. This is just one very specific case, not a general statement.
SSE probably won't help. I do almost no floating point computations in the code. Didn't help for GCC, either ("-march=native" means optimize for the platform GCC is running on, and for a Core 2, which I am using, that should include SSE).
*shrug*
Well, just remember that I had enabled every optimization I can find in the options and copied the command line.
Not quite every optimization, depending on if you use the STL or not. If you do, you'll want to define _SECURE_SCL equal to 0, otherwise every use of iterators goes through debugging checks.
That's not a command line, though, is it?
It is suitable for a final release, however.
But during development builds, I would not recommend it since it enables debug checks.
It would be on the command line after: /D _SECURE_SCL=0Quote:
Originally Posted by Elysia
EDIT:
At least that's what Visual Studio shows me after I entered _SECURE_SCL=0 into the preprocessor definitions option.
*shrug*
Yet again, I did not consider preprocessor definitions. I only copied the command line and those preprocessor definitions are the default ones.
I guess "/Ox" (maximum optimization) should enable all generic optimizations?
I will try the _SECURE_SCL thing tonight. I don't use much STL stuff in the inner loops, though. The code is fairly low level.
I tried ICC on my Linux host, and its resulting binary is ~2% slower than GCC's...
I guess my program just likes GCC more than any other compiler for some reason.
Fun to look at fast scrolling ICC output, though :).
They make it SOUND so fast.Code:ipo: remark #11001: performing single-file optimizations
ipo: remark #11005: generating object file /tmp/ipo_iccY1Q2vY.o
Brainless.cpp(516): (col. 17) remark: LOOP WAS VECTORIZED.
Brainless.cpp(523): (col. 21) remark: LOOP WAS VECTORIZED.
Brainless.cpp(532): (col. 4) remark: LOOP WAS VECTORIZED.
Brainless.cpp(533): (col. 4) remark: LOOP WAS VECTORIZED.
Brainless.cpp(919): (col. 13) remark: LOOP WAS VECTORIZED.
Brainless.cpp(235): (col. 9) remark: BLOCK WAS VECTORIZED.
Brainless.cpp(270): (col. 9) remark: LOOP WAS VECTORIZED.
misc.cpp(11): (col. 7) remark: LOOP WAS VECTORIZED.
AI.cpp(110): (col. 2) remark: LOOP WAS VECTORIZED.
AI.cpp(361): (col. 13) remark: LOOP WAS VECTORIZED.
AI.cpp(87): (col. 4) remark: LOOP WAS VECTORIZED.
movegen.cpp(1576): (col. 3) remark: LOOP WAS VECTORIZED.
movegen.cpp(1469): (col. 3) remark: LOOP WAS VECTORIZED.
movegen.cpp(1554): (col. 3) remark: LOOP WAS VECTORIZED.
util.cpp(458): (col. 4) remark: LOOP WAS VECTORIZED.
movegen.cpp(1149): (col. 10) remark: LOOP WAS VECTORIZED.
AI.cpp(503): (col. 5) remark: LOOP WAS VECTORIZED.
AI.cpp(769): (col. 17) remark: LOOP WAS VECTORIZED.
AI.cpp(789): (col. 13) remark: LOOP WAS VECTORIZED.
AI.cpp(848): (col. 13) remark: LOOP WAS VECTORIZED.
AI.cpp(868): (col. 3) remark: LOOP WAS VECTORIZED.
movegen.cpp(1421): (col. 17) remark: LOOP WAS VECTORIZED.
AI.cpp(527): (col. 34) remark: LOOP WAS VECTORIZED.
AI.cpp(529): (col. 21) remark: LOOP WAS VECTORIZED.
Brainless.cpp(170): (col. 2) remark: LOOP WAS VECTORIZED.
"/D _SECURE_SCL=0" didn't make any noticeable difference.