Quantcast



Docs


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Persistently Different - Not right, just different.
 Multi-core Parallel Processing - or Not.
posted on Wednesday, August 20, 2008 10:07 AM

Fortune has an article about multi-core CPUs and the struggles of software to make use of them.

If you follow software development at all, you knew this was coming, and like a car crash, can't seem to look away, though you know it's going to be ugly.

And it is all a question of market maturity. Funny thing about computers, in many ways the market has grown up over the last 20 years, but due to an endless stream of innovation, in many ways it hasn't.

This particular problem is probably the best example we have of this phenomenon.

Not every car needs to be a Maserati when a beat up old Ford will get you to work every day. This is common sense applied regularly in every industry and field of endeavor out there - you don't send strategic bombers to blanket the country where a bank robbery is occurring. And yet in computers, bigger and faster is always assumed to be better for every application. That's where the first, truly useful, wave of Virtualization came in - putting all of those servers that were using a tiny percentage of their resources together on one box... Because we always had to have the newest, fastest box. Many of you are about to decry "but that's all they sold..." yeah, that's a part of the problem. The other part is that while you're bringing in the faster bigger brighter box through the front door, perfectly serviceable boxes were going out your back door as "too old".

The other part of the problem is that this is a tools issue, not a developer issue. The vast majority of developers in today's world are focused on business problems, not technical problems. With millions of developers across the globe, asking them to do what we would have done even 10 years ago - relearn everything to the "cool new standard" - is not acceptable. Some will, no doubt, those who, like me, are intrigued by difficult programming problems (in my case preferably close to the metal), but most won't. It's not their job. Even if it was their job, the state of software development is such that most development occurs in virtual machines or as interpreted languages - not development that could or should have to worry about what the CPU is doing. And honestly, for most enterprise developers, their eyes glaze over when you start to say "parallel development". Start talking about atomic operations, protected code segments, and locks, and you'll lose them completely. That's no business problem.

So what do we do? Well, the tool vendors need to figure it out. Either your VM can handle multiple CPUs or it can't. Just let us know, so we know whether we need more cores or more boxes when the time comes. You could lay this at the feet of OS vendors - and I could make that case since that's one of the ways the development tools could be generated - but do you really want your OS wasting even more cycles worrying about whether your machine is multi-core or not? Yeah, me either.

Do I wish I was involved in the research? Oh heck yes, that type of development is really fun - in that frustrating until you get it sort of way. Do I think that Fortune mis-represented the problem? Only kind of. They never come out and say that the Enterprise should be worried about it, but their target market includes C-Level execs, and they never clearly state that this is not - and should not be - an enterprise problem either. Tool vendors and in some cases appliance vendors will have to struggle with this problem, but enterprise developers? Nope.

What can you do in the meantime? Well first off, don't oversize too much. Unless you're certain your app can take advantage of multi-core, it may not be doing you any good. Second off, when your application outgrows that server, save it as a hand-me-down, don't let Bob take it home to add to his network. Other apps likely don't have the same sizing requirements. And finally, watch the smart folks at Intel and AMD, that's where the problem is likely to be fixed first... Intel sells a C++ compiler that can directly take advantage of multi-core, so they're on the road to the solution, just need a little time to bubble it up to more commonly used enterprise languages.

Don.

/Reading: M10 GMC in Action

Share this post :



Email This
  del.icio.us
      

Feedback


8/20/2008 10:36 AM
Gravatar This problem was first attacked by (D)ARPA and their parallel supercomputing initiatives. I was involved in a developing a methodology to convert existing mainframe supercomputing software to parallel supercomputing software. The methodology mainly involved reframing the logic of the problem to separate it into independent operations (sort of like LTM v9 and CMP). At the time, Intel was one of the leading manufacturers in this. AMD was nowhere to be found. However, ths was many years ago.
Pat

8/20/2008 11:10 AM
Gravatar Hey Pat!

You bring up a point that I was thinking of while writing this - we studied parallelism in the context of UNIX when I was in college. This is not a new problem at all, so I'm not certain why they aren't just cranking out a solution. But not having taken the time to research the current problems, I didn't go there in the post.

I wonder if it is just a case of deciding who does what? The app (and by extension the compiler) are dependent on both the hardware implementation and the OS scheduler. In interpreted environments there would be another scheduler in the virtual engine. There would have to be a plan for who is responsible for what - pipelining, etc is more complex by a long shot in a multi-core environment, so that could be part of the issue too.

If I only had an excuse to go research this ;-).

Don.
Don

8/21/2008 7:18 AM
Gravatar I just read an interesting post on concurrency, threading, and multi-core approaches: http://blog.isotoma.com/2008/05/some_thoughts_on_concurrency.html

While some of the article is specific to Python's Twisted framework (an event driven networking library), it's still an excellent read that may be of interest.

-Matt
Matt C.

8/21/2008 8:12 AM
Gravatar "tool vendors need to figure it out." Agreed. And, I think this is a biggie, so can't primarily rely on just one group in the ecosystem. I suspect it will require serious involvement from the semiconductor vendors, O/S players, and others.

I think the silicon arrived a couple years ahead of tools to program it, but good news is that there's a few approaches available (and some in development) - thread pools, OpenMP, Intel's TBB, Microsoft's in the game, as are we at Cilk Arts.

Ilya
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 4 and 7 and type the answer here: