Seems there are more and more articles popping up on PLINQ and just multi core programming in general.  Visual Studio Magazine has a great summary of the current state of affairs in multicore programming.

Key to the article is that just enabling parallel code doesn’t always make it run faster.  There are dependencies, deadlocks, and all sorts of other problems that can occur.  Programmers have to know how to take advantage of the various technologies, and shift some thinking to new design patterns as well.

There are many technologies in .Net 4 including the following list:

More...

I recently wrote a quick test to prove something, that ended up being wrong…

Of course this is the way of science.  You form a hypothesis, then you test.  The results should prove or disprove your theory.

The hypothesis

Ok, my theory was that Buffer.BlockCopy() would outperform our current Array.Copy routines on the page level.

When we are loading records off a page we have to extract some parts of the buffer to build up a row buffer. A typical 8Kb page may have 100 or more records packed into it, and grabbing them out can take quite a bit of time.  Each row data is a compressed byte array that may include information that points to extended row data as well. 

This is one of the differences between this same app written in C++ and C#.  In C++ you would just take a pointer to the original buffer and pass that to the row routines, you wouldn’t need a copy of the data.  But we don’t have pointers in C#, so a copy is made to get out just the part of the buffer needed by that row.

Since we want the fastest way possible to read this block of data into the row, we were looking at alternative ways to do it.

The Experiment

I wrote a program that randomly grabs a length from an 8Kb block that contains 150 records.  The length of the row was randomized (but the seed reset to the same value for both tests to ensure the same random numbers were used with both methods).  The results were surprising.

More...