Dispatches from Maine

Just another person of little note writing about ordinary things. That I reside in Maine is icing on the cake.

13 September 2005

PDC05: Day Two (C++ Performance)

The next talk by Bob Davidson, "C++ Internals: Performance" cemented his skill as a very engaging presenter and all around smart guy. The new compiler has a tool called "Performance Guided Optimization" (PGO, pronounced pogo), which was originally built as a tool for the Itanium compiler. Before you make use of it, the key phrase to memorize is "Common User Scenarios." To make use of PGO you instrument your build and then exercise the application. If you use the application in way that triggers error conditions, then those are the code paths which will be optimized. If, on the other hand, you remember to exercise the application with "Common User Scenarios" then the normal uses of the application will have their code paths optimized. The Windows XP kernel was run with PGO enabled and they obtained an 18-20% performance gain. Just as Davidson finished uttering that line his demonstration platform blue screened. I hope that is not the PGO optimized build at work!

He then jumped into some very serious detail on new mechanisms for developers to give hints to the compiler which are ordinarily hard, or even impossible, for the compiler to discover. The easiest to describe, since aliasing is hard to explain with a few words, is the Named Return Value Optimization (NRVO). This optimization will make copy constructors faster since it eliminates the additional object ctor/dtor in the copy constructor call. The Frame Pointer Omission FPO) optimization can also produce a 3-5% gain, generally more on the 3% size. He also remarked on the need for developers to identify the most computationally expensive part of their projects and ensure that both the data and code can fit into the cache. The performance boost due to a good sizing is measurable (See "Cache-conscious structure definition" by Davidson, Bob, et al).

The last topic which arose before we left for dinner was the effect of exception handling on the optimizer. He opened with this statement, "If you do not care about performance, use exceptions all you want." Having studied exceptions and optimization in several languages, I was familiar with the effects he discussed. Toward the end, I asked him to elucidate on the effect of the ISO C++ exception specification on the optimizer. This has been a point of hot debate at work with most people coming down against using exception specifications with the belief that it seriously harms optimization. Davidson passed off this issue to Brandon Bray. Bray outlined the behavior as described by the standard: throw(), normally called nothrow, requires the compiler to wrap the decorated method with an exception handler and call terminate() if an exception is emitted from the method. Bray felt this was an absolutely stupid requirement, because of its severe consequences to performance. Microsoft has instead implemented this as an alias to __declspec(nothrow) which promises the compiler no method will be thrown. The compiler then uses this information to better optimize calls which use the method. This makes throw() a performance enhancer with VC++ rather than a performance killer, as it is in ISO C++. I cannot wait to go flex at George S's office at work.


Post a Comment

Links to this post:

Create a Link

<< Home