I agree with the previous poster that the "yeah yeah yeah" throughout the entire video was indeed very distracting. As a result you were difficult to follow at times and I had to rewind the video and replay it. In particular, as a presenter and mentor, you
need to work even harder on your communication skills. Anything distracting, whether it is the occasional "uhm" or, in this case, the constantly repeated "yeah," hurts your ability to convey your teaching points to others.
Additionally, commitments were made in the demo to post the source code on the presenter's blog on March 24th. As of today, March 26th, this has still not been done. If you commit to doing something before a very wide audience (i.e., Channel 9), make sure
you follow through!
Now, let's move on to topics more relevant to this technical presentation.
The following is not only directed to you, but to all future presenters of anything involving comparisons of performance. The (mis)behaviors described below seem to be rampant, not only in this video, but in many of the presentations on related topics at
the last PDC, as well. Without further ado:
Do not show performance comparisons of single and multi-threaded code in Debug mode. To make matters worse, not only were the comparisons made using Debug builds, but they were run
in the VS debugger, further degrading their performance.
No production code should be running as Debug builds and any performance comparisons made using Debug builds are
If you are going to compare the performance of two pieces of code, make sure that you are comparing
Release builds with all sensible optimizations turned on.
The single-threaded code may have been fast enough, if only the demo had presented it using a Release build, to
not even warrant the complexity and overhead of multi-threading.
Non-Release build comparisons are very deceptive of the true (relative) relationship between alternative implementations. The overall deception lies in the fact that, by prolonging the run time, in
Debug mode, the percentage overhead of such effects in multi-threaded code as lock contention, false sharing, potential context switching due to oversubscription, and other overhead that more than one concurrent thread of execution may introduce, is often
greatly diminished. This is unintentionally misleading at best and a downright lie to promote a certain multi-threaded approach, at worst.
When measuring the performance of your run, do not move the console window. Do not resize it, do not do anything to the app window other than passively monitor it using a performance tool. Keep your fingers off the mouse and off the keyboard until
the run is complete. I can't begin to count how many presentations I've seen, including this one and many at the PDC, where the presenter moves the console window around during a performance calculation. Do not do this! It impacts the performance of
the system and therefore potentially the application being timed / monitored. Even if the impact is subtle, it is neither negligible nor constant in that it can be subtracted out after the fact! Pre-position your console window programatically at the start
of the run, before any computations take place. Or, better still, pre-configure its placement before giving the presentation, so that it appears in the correct place on your screen and is of the appropriate dimensions for your demonstration.
When presenting the effects of multi-threading, explicitly state what hardware is being used, including whether or not it supports hyperthreading and whether this was enabled in the BIOS for the presentation. The number of physical cores present and their
layout on physical CPUs, is also important to mention explicitly, even if it can (sometimes correctly) be deduced from the one or more performance monitors presented.
Speaking of performance monitoring, if you are going to use Task Manager or, for that matter, any other performance monitoring tool as part of your performance related discussion, the Kernel Time / User Time breakdown should be displayed and not just the
total time. Seeing this breakdown is very important, especially when potential context switching and other kernel mechanisms (e.g., locking) are in play. Not seeing this breakdown, which is trivially enabled (e.g.,
View/Show Kernel Times in Task Manager), makes the presentation of system load seem
superficial and disingenuous. Additionally, showing the total CPU load rather than the load induced by the process or processes being examined, individually, is also somewhat misleading. To truly show the proper system load for multi-threaded
tests, PerfMon should be used and such counters as per Thread User / Kernel time, context switches per second, and other counters appropriate to the items being demonstrated should be included.
Let the above points be a lesson to this and all future presenters on this topic, whether on Channel 9, at a PDC, or any other venue.
OK, trolling aside, I looked at the "Book of WPF." First of all, regarding said book, whoever decided to make it an 18"x9" PDF file needs to go back to design school. It was a royal pain to have to navigate it horizontally and vertically in Adobe Acrobat
viewer. I did go through the entire book, though. Having done that, I basically came to the following conclusions:
- For video playback apps and other "player-like" apps, exclusively, WPF with a custom GUI layout that presented the application to the user in a manner resembling a hardware player, made some amount of sense.
- From the rest of the examples, the few implementations that looked semi-professional and not like GUI implemented by a College student on LSD, all used an Office 2007-like ribbon. These would have been better served, at least performance wise, by using
MFC and Codejock's Toolkit Pro.
Now, granted, I don't know how many of the apps were written in C++ and how many were written in C#. Certainly, my statements above only apply to those that were written in native C+, for which MFC was an option. Even for the C# apps, though, outside of
the various players, a ribbon interface would have been much better than the hacked attempts at GUI that I saw.
MS spent a small fortune on the evolution of its Windows (and Office) GUI, first using menus and toolbars and now ribbons. Most of the apps I saw spat in the face of this evolutionary development saying, "We can do reinvent the (GUI) wheel and do a better
job." As software engineers, we all know the most probable outcome of someone reinventing the wheel in the software development world.
If you want your business application to resemble an ATM machine, you will use WPF. If you want it to look professional (i.e., like office), you will use MFC and a good toolkit such as Codejock for ribbons and views.