posted by Corrector2

posted by Corrector2

posted by Corrector2

posted by Corrector2

posted by Corrector2

posted by Corrector2

1) Way too light - Live Mail - everything is white, light blue, or some indistinguishable permutation of the two

2) Just right - Visual Studio 2010 - things have just the right amount of color and contrast

3) Dark, bland and dead - Visual Studio 2012 - welcome to the dark side, monochrome monitors revisited, and all of the other bad things you find in other applications that do it this way. If you read the forums of applications that do it this way (i.e., a black and white UI), you will find a myriad of complaints about this being a retro UI and how it should evolve into a more modern colorful (used sparringly, of course) UI.

posted by Corrector2

posted by Corrector2

posted by Corrector2

posted by Corrector2

posted by Corrector2

posted by Corrector2

posted by Corrector2

posted by Corrector2

posted by Corrector2

- A complex function, even if it is mostly one containing linear flow can be broken down into several simple functions in order to become more hierarchical and less linear. Let me give a simple example to elucidate my point:

Instead of a long function such as:

void Car::Build()

{
   // Build the frame

   ... build the frame code

   // Add doors

   ... add doors code

   // Insert engine

   ... insert engine code

   // Insert transmission

   ... insert transmission code

   // Insert upholstery

   ... insert upholstery code

   // Paint the car

   ... paint the car code

   // Whatever else needs to be done

   ... whatever else needs to be done

}

It is much easier to see (the comments are not part of the code, I am just adding them to show what the functions being called do for the purpose of explaining my point):

void Car::Build()

{
   BuildFrame(...); // Calls AddDoors()

   AddInternalParts(...); // Calls AddEngine(), AddTransmission(), AddUphostery()?, etc...

   AddBodyParts(...); // Calls AddDoors()

   Paint(...);

}

Now the Build function is easy to eye over and comprehend. If the programmer wishes to look into detail and see how each step is actually implemented, he can go into each of the functions being called and examine them (or look at call graphs, etc...).

By creating a deeper (rather than shallower) Build() function, it is much easier to comprehend in a top down (rather than bottom up) fashion. This is how most people solve and analyze problems - from an abstract problem statement to analyzing (i.e., "sweating") the details.

If you:

1. Break up your solve function into sub-tasks (functions)
2. Give them meaningful names
3. Only call these sub-tasks from within solve

Then, it would be much easier to see what solve does as a whole and there would be no performance penalty in doing this, to boot, because these sub-tasks would probably still be gross tasks. If any of the sub-tasks are still complex, you can further decompose them into more sub-tasks.

A developer reading solve would drill down to the level of interest to him, while seeing the big picture all along the way. Compare this to having to gloss over 400 lines of code, even if only looking for comments, in order to try to figure out what solve does.

My two cents...

posted by Corrector2

posted by Corrector2

Just my 2 cents...

posted by Corrector2

posted by Corrector2

Please follow up with more from DevDays 2010. Also, the video and audio quality are superb! All encodings of presentations should be this good.

posted by Corrector2

posted by Corrector2

Thanks

posted by Corrector2

posted by Corrector2

CalcPrimes
Count of prime numbers: 283146
Elapsed = 1713

ThreadingDemo.CalcPrimes
Count of prime numbers: 283146
Elapsed = 1080

ParallelFor.CalcPrimes
Count of prime numbers: 283146
Elapsed = 431

ParallelForEach.CalcPrimes
Count of prime numbers: 283146
Elapsed = 481

ParallelFor.CalcPrimes_TLV
Count of prime numbers: 283146
Elapsed = 430

ParallelForEach.CalcPrimes_TLV
Count of prime numbers: 283146
Elapsed = 447

LinqDemo.CalcPrimes
Count of prime numbers: 283146
Elapsed = 1740

PLinqDemo.CalcPrimes
Count of prime numbers: 283146
Elapsed = 461

Summary: It looks like, with a proper release 64-bit build, there are many options available here to gain the scalability, at least with this particular test and the specified number of CPUs.

Interestingly, if we make a slight improvement to the algorithm we can improve performance and most likely not even need to consider multithreaded approaches. Also, we can leverage the contents of the container we are forming without worrying about (and paying a concurrency penalty for) locking it, as follows:

        private static void CalcPrimes2()
        {
          List<int> primes = new List<int>() {2};
          
          for (int nr = 3; nr <= 4000000; nr+=2)
          {            
            int upperBound=(int) Math.Sqrt(nr);
            
            foreach (int prime in primes)
            {
              if (prime > upperBound)
              {
                primes.Add(nr);
                break;
              }

              if (nr % prime == 0)
                break;
            }
          }
          Console.WriteLine("Count of prime numbers: " + primes.Count);
        }

Running with these small changes, we get:

CalcPrimes2 (Single-Threaded)
Count of prime numbers: 283146
Elapsed = 501

Notices how this result is comparable to our best multi-threaded results.

For the next test, let's increase the number of numbers being tested for primality to 8 million and see how the various approaches fair:

CalcPrimes
Count of prime numbers: 539777
Elapsed = 4585

CalcPrimes2 (Single-Threaded)
Count of prime numbers: 539777
Elapsed = 1224

ThreadingDemo.CalcPrimes
Count of prime numbers: 539777
Elapsed = 2870

ParallelFor.CalcPrimes
Count of prime numbers: 539777
Elapsed = 1146

ParallelForEach.CalcPrimes
Count of prime numbers: 539777
Elapsed = 1210

ParallelFor.CalcPrimes_TLV
Count of prime numbers: 539777
Elapsed = 1144

ParallelForEach.CalcPrimes_TLV
Count of prime numbers: 539777
Elapsed = 1178

LinqDemo.CalcPrimes
Count of prime numbers: 539777
Elapsed = 4623

PLinqDemo.CalcPrimes
Count of prime numbers: 539777
Elapsed = 1183

Now, the slightly improved single threaded function (CalcPrimes2) is almost in line with out best parallel attempt, using the previous algorithm, despite the fact that this is a decent multi-processor host (i.e., 4 physical, 8 logical CPU cores) which allows for a lot of potential parallelism to the various decent parallel approaches presented in this session. This example (i.e., extending the domain of numbers being tested to 8 million) and how it scales as the workload increases, underlines the point about taking a little time to improve the algorithm first, before jumping with both feet into a multi-threaded solution.

If you are still not convinced, let's look at what happens when the domain is doubled again to the first 16 million numbers:

CalcPrimes
Count of prime numbers: 1031130
Elapsed = 12248

CalcPrimes2 (Single-Threaded)
Count of prime numbers: 1031130
Elapsed = 3017

ThreadingDemo.CalcPrimes
Count of prime numbers: 1031130
Elapsed = 7682

ParallelFor.CalcPrimes
Count of prime numbers: 1031130
Elapsed = 3054

ParallelForEach.CalcPrimes
Count of prime numbers: 1031130
Elapsed = 3119

ParallelFor.CalcPrimes_TLV
Count of prime numbers: 1031130
Elapsed = 3052

ParallelForEach.CalcPrimes_TLV
Count of prime numbers: 1031130
Elapsed = 3103

LinqDemo.CalcPrimes
Count of prime numbers: 1031130
Elapsed = 12318

PLinqDemo.CalcPrimes
Count of prime numbers: 1031130
Elapsed = 3106

In this run, the (improved) single-threaded solution (marginally) beats our best parallel attempts with the weaker algorithm.

Thanks for listening

posted by Corrector2

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:

1. 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.
2. No production code should be running as Debug builds and any performance comparisons made using Debug builds are completely vacuous.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.

Thanks for reading

posted by Corrector2