Multi-core Clip Show

Yet another multicore rant. This one is triggered by the recent Multicore Expo.

Over the years, I have developed a reputation for writing things down. It started when I was younger, but I really earned my stripes in the early days of HPC clustering. My motivations were self serving. Rather than write the same response to a mailing list question for the tenth time, I figured I would write it down and send a text document to those who were interested or better yet, I’ll put it on the web. Now my response was easier, I could easily write “take a look at this URL” rather than write a long response. There are those, however, who have a knack for writing excellent exhaustive answers to cluster issues many times over. I won’t mention any names, but some guy with the initials rgb has such a reputation on the Beowulf Mailing list. Don’t tell Robert Brown I mentioned his initials. Thanks.

Continuing, recently I was irked by the following article: Multicore chips pose next big challenge for industry. My response to the IDG News Service writer, Do ya think? May I suggest a better headline Multicore chips pose the biggest most monumental and grandest challenge ever to the entire industry. This is not news, this is more of the same old song and dance. In case you have been under a rock, I have been losing sleep over this for over two years now. If you have read my past installments, you know I’m about to head into one of my multicore rants. I can’t help myself.

Where to begin? First, some apologies if this column seem like some cheesy television clip show made up of old content. That is not my intention. I will reference some old columns because I think they do a good job representing my position on multicore and I will also try and drive home a simple: point we are doomed.

Looking behind the article, there was a recently the 4th Annual Multicore Expo. Aha! Expo’s need press and “next big challenge” headlines always help the cause. As noted above I prefer the “biggest most monumental and grandest challenge” headline, but maybe I’m spitting hairs. A Multicore Expo? That has to be a good thing. At last, someone grabbing the bull by the horns. So let’s have a look at the agenda. Hmmm. Seems like there are a bunch of solutions. The web pages clearly states: The ONLY Conference Delivering REAL Developer SOLUTIONS for Multicore and Multiprocessing Designs . I click on a few abstracts. Then a few more. Wait a minute, all the talks are from companies and guess what the companies are all sponsors of the event. In addition, they all have a great solutions although some of the solutions don’t seem to Delivering REAL Developer SOLUTIONS. The more I read the abstracts the more I got the “same old same old” feeling. There seems to be no real consensus about how to program these things.

Of course, I believe there needs to be a mammoth effort to address this problem. And for reasons of economics, I am convinced it needs to be an open solution. The Multicore Expo was, in my opinion, yet another recycled effort to push square methodologies into a round problem. At first, I thought, maybe I should attend. Then after I looked at the agenda, I thought it was a good thing I did not go. I probably would have been thrown out for “heckling” or as I like to think of it “asking the hard questions”. Alright, enough railing on the Multicore Expo. At least someone is talking about it.

I was always told, don’t criticize unless you have a solution to offer. I like to adhere to this rule, but there are times when it does not make sense. For instance, “Excuse me Mr Titanic Captain, your boat is sinking and Jack over here is probably going to die. I am trying not be critical, but I did not build the damn boat, nor did I run it full speed into an iceberg, or not include enough life boats, but I would like to make a suggestion for your next cruse …” Seems kind of like a moot point.

In any case, here my suggestion. I have said it before, and I will say it again and again — Functional Programming. Yes, that weird, I don’t want to learn this because it makes me have to think differently language. Personally, I like Erlang, but I would recommend giving Haskell a good look as well. And, let me be clear, these are not miracle languages, but they are a far sight closer to what we really need to move forward in the multicore (read parallel) world.

Let’s recap. In the age of multicore, we are doomed if we don’t do something different, an open approach is the only economical way to solve this problem, and functional languages are the most promising. Yes, I said it all before. Sorry for the multicore clip show. At least mine did not require a name tag.

Comments on "Multi-core Clip Show"


Current architecture on mother boards (except for high-end) stuff does not support multiple channels to memory or multiple memories.

So we have the bottleneck for performance being transferred from the processor(s) to the memory system, and to the I/O systems.

It reminds me of through-put studies for a ticket booth.

With a single queue, are you better off with one server working at speed 2X or two servers working at speed X?

Actual measurements and queuing theory algorithms say, faster processors, but fewer of them, are the better answer.

Hi, Neat post. There is a problem with your website in internet explorer, would check this… IE still is the market leader and a large portion of people will miss your great writing due to this problem.

qKg2F5 wieujrmlewxh, [url=http://cnbwpairqfqu.com/]cnbwpairqfqu[/url], [link=http://azgusbmvljlm.com/]azgusbmvljlm[/link], http://tjzwkjbmczph.com/

Leave a Reply