Parallel processing Rip Van Winkle just woke up!

I just got back from attending a Microsoft HPC conference in Redmond Washington this week and during one of the breaks I had a chance to talk to another attendee who had previously worked at Microsoft back in the late 80's / early 90's. What this gentleman and I found we had in common was that back in the late 80's he taught at Microsoft University (which was Microsoft's only training facility in the 80's) where I had attended a couple of OS/2 development courses.

As we were talking about the good-old-days of developing for OS/2, we were reminiscing about all of the cool multi-threading and interprocess communication things you could do back then and it struck me. For the last twenty years, the number of times I have had the chance to do any parallel programming has been very limited within the context of developing and delivering business focused applications. Yet, here I sit twenty years later with about 100 people on the Microsoft campus talking about parallel processing again! Halleluiah!

I was starting to feel like a parallel processing Rip Van Winkle! That I just woke up from a twenty year nap and someone coined the terms embarrassingly parallel to point out how dumb we have been for not solving these types of problems via a parallel approach before!

Now, I would be the first to tell you that there were a lot of reasons for not doing parallel processing to solve embarrassingly parallel problems before. Given the hardware, languages and general developer parallel processing acuity of the day, the gains from parallel processing would have been negligible. But given the only recent change in the above list has been the advent of multi-core processors to continue Moore 's Law trajectory. Is that enough to take parallel processing main-stream?

When will main-stream development languages seamlessly address multi-core capabilities?

When will developers understand the intricacies of thread synchronization?

What if you didn't even need multi-core processors to do parallel processing? Did you know that you can take your Visual Basic programs, on single core commodity computers and they will solve embarrassingly parallel problems (and some not so embarrassingly parallel problems) reliably? No multi-threaded development experience necessary. Yes, you might have guessed it. It's called a fabric.

Bring us your embarrassingly Cobol or Visual Basic applications and we can show you how to make them embarrassingly parallel...

Until next time..

Mark

Technorati: , ,

very interesting, but I

very interesting, but I don't agree with you
Idetrorce

PLINQ

I'm interested in "massively parallel processing" --using hundreds of computers, each with multiple cores, as quickly as possible.

I have found some information on PLINQ (Parallel LINQ); however, as I understand it, that's only for multi-core programming, not *distributed* programming, correct?

Is there an "easy" way to combine both techniques, so that you can use as many cores on as many PCs as you have available, in a "transparent" fashion?

Post new comment

The content of this field is kept private and will not be shown publicly.
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
4 + 1 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.