This time the migration of projects to the latest VS version was relatively painless in comparison with the upgrade to VS2010. The one error I ran into was
Cannot open include file: 'sal.h': No such file or directory
which was easily fixed by adding "C:\Program Files (x86)\Windows Kits\8.0\Include\shared" to the list of include directories.
Remembering how the performance of an H.263 codec improved *notably* when we migrated from VS2008 to 2010, I was curious to find out what the VC team has done in 2011. After having rebuilt the Video Processing Project solution and running the FrameGrabber application the following results were observed:
Mode: Total average Per frame Improvement %
0 872.10 ms 0.86 ms
1 859.45 ms 0.75ms 13.42%
2 816.97ms 0.56ms 35.26%
3 879.01ms 0.82ms 5.04%
5 N/A
Comparing these results to the ones obtained using VS2010 as posted in Improving live multimedia pipeline performance
Mode: Total average Per frame Improvement %
0 1224.46ms 1.16ms
1 1105.63ms 1.02ms 12.26%
2 969.82ms 0.55ms 53.10%
3 1572.18ms 1.24ms -6.74%
5 1106.09ms 0.59ms 49.13%
The results were obtained using the FrameGrabber application, running the application 5 times and taking the average. Looks like the compiler team has done some serious work optimising the generated code. Even though the relative placement between the timings of the various modes is still similar, the gap has closed considerably. This is not to say, that optimisation is any less important when using newer compilers : a 35.26% improvement is nothing to frown upon.
Looks like the free lunch isn't quite over yet, as long as you can afford a new compiler/IDE :-)
UPDATE:
Looks like this might have something to do with the auto-vectorizer in VS2011: http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-7-VC11-Auto-Vectorizer-C-NOW-LangNEXT
No comments:
Post a Comment