Ok, the machine I’m going to test this on, is a Vista x64 machine (I know I just couldn’t be bothered to upgrade it yet).
The CPU is an Intel Core2 Quad Q9300 running @ 2.50Ghz, with 8GB of ram.
The “Windows Experience Index” is 5.9 (It’s 5.9 across the board).
I’m using a redo of the SDL port of Quake 1 as a benchmark. You can download it here.
Unzip it somewhere, and I’ve tried to make this pretty easy to follow… There are precompiled EXE’s for various CPU’s and Visual C++ levels.
To build, setup your CLI with the VC environment variables, then simply cd into ‘ezquake\build’ and run:
nmake -f quake.mak
If you have Visual C++ 2.0 (I forget if I needed this for 4, and I just don’t feel like installing 5.0 right now) you may need a slight ‘hack’ to undefine some things that just don’t exist in the winmm.dll setup with the vc2.mak/b2.cmd .
And this should produce an EXE with the /O2 flags for a generically built maximum speed optimized EXE. If your make has issues, you can try the build.cmd file which just blindly compiles the thing one at a time…. It should work as well.
Then to test the exe, simply cd into the ‘ezquake\test’ and run:
..\build\quake -nomouse +timedemo demo1
Anyways, now for some interesting test results:
Visual C++ 2 x86 619.4 FPS
Visual C++ 4 x86 689.1 FPS
Visual C++ 6 x86 631.2 FPS
Visual C++ 2008 x64 375.7 FPS
Visual C++ 2008 x86 400.6 FPS
Visual C++ 2010 x86 772.2 FPS
Visual C++ 2010 x64 949.5 FPS
949 FPS in Quake1!
I’m blown away with just how fast this new version of Visual C++ is.
Um, excuse me, but it looks like you're conflating the Visual Studio version with the compiler version. The compiler has been around a bit longer than VC++/VS (and does not exist solely for use as a component of them), so it has a somewhat larger version number. For example, VS 2008 (9.0) appears to come with:
>CL
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80×86
Copyright (C) Microsoft Corporation. All rights reserved.
I would suggest picking one version and sticking with it — the CL version is presumably more meaningful — or listing both for each compiler. Note also that the CL versions in a single package may differ between target architectures, for example:
Z:\WinDDK\3790.1830>for %I in (fre 64 AMD64) do cmd /c "bin\setenv.bat . %I && c
l"
Z:\WinDDK\3790.1830>cmd /c "bin\setenv.bat . fre && cl"
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.4035 for 80×86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
usage: cl [ option… ] filename… [ /link linkoption… ]
Z:\WinDDK\3790.1830>cmd /c "bin\setenv.bat . 64 && cl"
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.39 for IA-64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option… ] filename… [ /link linkoption… ]
Z:\WinDDK\3790.1830>cmd /c "bin\setenv.bat . AMD64 && cl"
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option… ] filename… [ /link linkoption… ]
I didn't notice I mixed in the compiler version along with the product version..
And yes, I've used MSC before it went all C++, then 'Visual', even if it felt like a glorified (and exceedingly more expensive) version of QuickC for Windows.
I even had a copy of MSC 3 in the box, the last version that was actually a microsoft product. I couldn't find a 5 1/4" working drive to make images, and now it's lost with all this moving around. 😐