Multi-core Development is One Step Closer to Being Required

In my last blog entry, I mentioned Intel's futuristic 48-core chip. That is a long-term look that might cause you to believe you still have time to wait before considering multicore issues in your applications. If you are not considering multiple cores today, when developing your applications, then you are falling behind. While tapping the power of multi-core applications isn't critical in a dual core world, quad-cores are starting to make inroads into the market place and early next year you'll see the number of six core systems start increasing. Just as the release of quad-core systems pushed dual core to the mainstream. We should be able to expect six core systems to push quad-core mainstream.

Specifically, according to ChannelWeb, Intel leaked a document that indicated that they will be releasing thirteen different processors on March 16th of 2010. This includes seven quad-core processors and six new six core processors. The six core processors will be running between 2.26GHz and 3.33GHz. The seven 32nm, quad-core processors will operate between 2.13GHz and 3.46GHz.

Also on the leaked list were three other processors, of which one was dual core.

Multicore chips are no longer the future. They are here. Are you coding for them?



More...

I still feel that except for certain classes of problems this whole topic is a red herring - a solution in search of a problem.

Most of the time on a desktop system you don't want one program to soak up every cycle available in the machine. There are a multitude of background housekeeping functions you want to have running without starvation. Many of us are performing a foreground task of some sort while we run application services, multimedia applications, etc. in the background as well.

When it comes to servers there are better ways to exploit multiple execution units than having application code spread itself across the "farm." Most application services can manage this for you where it is needed, whether we're talking about IIS, SQL Server, general application components managed by COM+, or anything else of this nature.

Letting Mort use multithreading in a gratuitious manner is probably just asking for trouble in most cases. While some of the stuff in recent versions of .Net helps manage concurrency without the gross errors Joe .Net typically makes multithreading by hand... there is still significant overhead involved in coordinating and synchronizing the threads.

I personally only ever need to spin off 1 thread other than the UI thread, so at most a dual core system has enough cpu cycles to complete the task(s) lightning fast. Also the 1 other thread I launch, usually does File IO operations, so it's up to the speed of the HDD, etc that really matters not raw CPU horsepower.

I admit, there are places I can use the horsepower to parallelize loops that are creating objects and in the end, adding those objects to a collection; but the only "slow" parts of my programs are when I'm dealing with Crystal Reports and it has to paginate a 250 page report.

As far as threading goes, I consider myself a blackbelt at this point. I use background threads to grab and fill data and control secondary machine processes.

If anything can use a multithreaded kick in the pants, it's: DataAdapter.Fill(DataSet).

Depending on the amount of data you have, this one can be painful.