The Free Lunch is Over

As though we haven't had enough problems with all those programmers and developers struggling (or most of the time, not bothering) to understanding what "object oriented" truly means, the job of overcoming poorly engineered, inefficient code can no longer be pushed to future hardware.

http://www.gotw.ca/publications/concurrency-ddj.htm

It is time for developers (and their bosses, really) who are serious about their profession to stop for moment, sit up, and contemplate just what kind of code they are (and will be) writing. The future is bleak indeed.

just try uttering something like 'i think i'm gonna split the work into 2 threads' to your team and watch how ppl's faces start to fold like protein molecues.

in fact i tried that even when i thought it's a pretty innocent suggestion to put AI calculations into a separate thread, the shock on ppl's face was still vivid.

but i guess with now that MSFT is behind this thing, threading will one day become like the gc: most of the time you don't care because it just works.

feelite wrote:

threading will one day become like the gc: most of the time you don't care because it just works.

Looking at the current science of computing, I cannot see a clear possible avenue to achieving this.

Only you really know what you want your program to do, and thus which can be executed before or after something else. Or concurrently, for the topical matter. There is not a good way for the compiler to break the below sample into several threads executed out-of-order behind the scenes and expect them to work.

using (StreamWriter sw = new StreamWriter("TestFile.txt"))
        {
            // Add some text to the file.
            sw.Write("This is the ");
            sw.WriteLine("header for the file.");
            sw.WriteLine("-------------------");
            // Arbitrary objects can also be written to the file.
            sw.Write("The date is: ");
            sw.WriteLine(DateTime.Now);
        }

it might be something like instruction prefetch and pipelining used in cpu and gpu, only assembly code programmers really have to know. of course whether the machine, compiler or the mortal does the dependency analysis will ultimately determine how easy the end-product is.

i've lost touch with the research side of concurrency for quite some time and am not aware of what the state-of-the-art is now. but the inclusion of openmp for the average programmers is a good start. CCR could also turn out to be interesting.

feelite wrote:

instruction prefetch and pipelining used in cpu and gpu

Correct me if I am wrong, but doesn't that happen only when two or more mutually exclusive processes/chores are available for work to be done? I am not a Photoshop user, but I have been told (some years back, to give allowance, for I don't know about newer versions) it wouldn't benefit a single bit from running a dual-processor workstation since being single threaded it only occupies the capacity of one CPU. Also clearly evident are poorly written software that can hold a CPU hostage and rage it 100%. On multi-proc machines, though, one can see such processes only seizing one CPU while the rest idle.

The good thing about graphics rendition is the software defines a "single" input of what needs to be drawn and leave the hardware, like today's SLI configurations, to decide which card renders which portions. But, they can easily split the data and not interfere with each other.

So with respect to what the article is pointing at, we likewise need to start defining the software work into various blocks that can be executed in parallel, assignable to different processors without interferring one another. But, we've been bred to think in one long sequential track, and it will take us very long (way too long) to work naturally with concurrency. And this is something current CPU hardware is no longer able to help us in, as pointed out. We have to write our own performance gains from now on.

Something that should be highly relevant, though I haven't got the time to read it to confirm.

http://channel9.msdn.com/wiki/default.aspx/Channel9.ConcurrencyRuntime

yes, that's what I was referring to.

"concurrency for everybody". CCR first appeared in PDC 05 with a very candid overview by the researcher

Justin Lee's recent UG talk on concurrency has renewed my interest in this area.

The existing Parallel extensions by Microsoft targetted at .NET FW 3.5 is currently a June 08 CTP

http://www.microsoft.com/downloads/details.aspx?FamilyId=348F73FD-593D-4B3C-B055-694C50D2B0F3&displaylang=en

it is indeed interesting how all this will play out. hopefully more languages (other than C#) get more widespread usage in the .NET framework, like Ruby, maybe we'll even have .NET versions of Erlang and Haskell!