Hi, I’m Lin Xu, a Program Manager working on the C++ compiler.

Recently, we collated performance numbers from our testing passes over this release cycle. We track many different benchmarks closely for all of the architectures and switch options (/O1, /O2, /GL, /PGO). We also track these across multiple CPU models. (Yes, this is quite a big matrix. Look for an upcoming blog post from the QA team to learn more.)

We’re pretty excited about the improvements we made for this release in code quality. (Read Ten’s recent post about it here) As I looked at the numbers, one thing jumped out at me: To really take advantage of these improvements, applications need to be compiled with /GL, and PGO, if possible.

If you aren’t familiar with PGO, you can read Lawrence’s blog post on Profile Guided Optimization here.

I’ve summarized some of our data comparing VS2010 Beta2 with VS2008 SP1.0. Here is a comparison between integer benchmark performance with various switches on x86 and x64:

These particular graphs are based on a benchmark suite similar to SPEC CPU 2006. But our benchmarks include real world code as well. We build and measure performance of many Microsoft products, including SQL, Windows and Office.

 Let’s say you currently build release builds with the /O2 switch in VS2008. If you moved to VS2010, you might see on x64:

·         10% faster code if you turned on /GL,

·         16% faster code if you turned on /GL and PGO

and on x86,

·         7% faster code if you turned on /GL,

·         13% faster code if you turned on /GL and PGO.

Now, for the last couple of releases, a new VC++ project will have /GL on for release builds. However, settings for upgraded projects are not changed. So whether you use the Visual Studio build system or your own custom build system, go ahead and check that you are specifying /GL for your release builds!

 The other recommendation I have is to use PGO. Doing so requires a larger investment (it requires you to figure out scenarios and create training data) – but it can improve the performance of your app above and beyond /GL. PGO works best on medium or larger applications. Small applications may see little benefit from PGO, depending on the application’s workload.

We recently created training data and turned on PGO for part of the C++ intellisense engine in Visual Studio 2010 and saw ~25% better performance on some scenarios. When we turned on PGO for the compiler, we measured ~10% speedup in compiler throughput. Again, you can learn about how to turn on PGO in your own builds in Lawrence’s blog post here.

/GL shouldn’t increase your build time significantly, but note that /GL is not compatible with Edit and Continue (/ZI) and incremental builds (the linker option /INCREMENTAL). You can read some quick tips about /GL in another previous blog post here.

As Lawrence describes in his blog post, with PGO your application is built twice – once for the instrumented build and once for the final optimized build. This means build times increase more significantly, as but as I’ve noted above, the performance increase is also more significant.

So, if your application is CPU bound, I hope that these numbers will convince you to take a second look at your release build settings and turn on /GL and PGO!