Saturday, October 20, 2007

7 Reasons Every Programmer Should Love Multi-Core

  1. The technology is not new it's old. It's just really cheap SMP and the SMP domain (shared memory model) is a well understood domain. So there are tons of resources (books, white papers, essays, blogs, etc) available to get you up to speed.

  2. Shared memory concurrency is challenging. It's guaranteed to grow your brain.

  3. Most programming languages [already] have language and/or API level support (threads) for multi-core, so you can get started right now.

  4. There are a plethora of computing domains that benefit from increased parallelism. The following are just a few off the top of my head: GUI applications, client/server, p2p, games, search, simulations, AI. In other words, there won't be a shortage of interesting work to do in this space.

  5. Most programmers [and their managers] don't have a clue about concurrency so you can easily impress them with your skills/CNM (Concurrency Ninja Moves).

  6. The majority of today's programs aren't written with multi-core in mind so mastering concurrency programming means you won't be out of a job any time soon. Somebody has to write the multi-core aware version of all those apps.

  7. Since most programmers are clueless about concurrency, mastering it means you'll be smarter that millions of people. Being smarter than your [so called] peers is really satisfying.


  1. Maybe you're right. But on the other hand, I've done some work in multi-threading and data structures designed to work with multiple threads.. and I'm not sure it's something that will ever catch on. Although it's fun, it requires a mind shift I'm not sure the masses will make.

    More likely is that compilers will have to bridge this gap for us before it becomes mainstream, IMO.

  2. Anonymous7:58 AM

    > GUI applications, client/server, p2p

    What? These applications take %1 CPU and spend 99% of their time waiting for some event (User, network).

    You mean "multithreaded programs"?

    Multicore is good when you have a lot of load and the algorithm can be parallelized and speed matters.

    A raytracer? Yes. p2p? Certainly Not.

    Are you sure you know enough to provide advice for this?

  3. I agree with the previous comment. I don't think the author fully understand the difference between parallelism and multi-threaded. There is a really big difference of which the majority of programmers will probably never need to code for. Boosting your ego is probably a really bad reason for mastering HPC or similar types of parallel computing models.

  4. mccoyn3:25 PM

    Even though GUI applications might only take 1% CPU, making them multi-threaded can improve responsiveness, if done right. Its only really necessary if you are doing some sort of background processing that you don't want to interfere with the user experience.

    As for the heavy lifting processing work, like a ray-tracer or AI it can be a big win. Unfortunately, it is hard to get right. It really isn't hard to understand to basic concepts, but it takes a lot of care to not make any mistakes. I like to think of it as being similar to doing dynamic memory management in C. Sure the concepts are easy, but anyone who has done a lot of work with it knows that you have to be very careful to get it 100% correct.

    I have to agree with david on this one. We will probably spend 20 years trying to figure out how to get programmers to do it write and then the next language will just do it automatically. Similar to how Java became the first heavily promoted language with garbage collection. These days no one even bothers to invent a language that doesn't have garbage collection.

  5. Anonymous4:51 PM

    "These days no one even bothers to invent a language that doesn't have garbage collection."
    And these days all these news languages are written in C and so is linux and any performance oriented application.
    Memory management is not hard, it's just a question of discipline.
    And same same goes with multi-threading.
    The reasons some people find 'dynamic' memory difficult is the same reason they have trouble grasping the concept of race condition: they just don't understand how their computer really works.

  6. After reading Anonymous' and JeffH0821's comments I'm a bit perplexed about where I lost them. Maybe my aberrant sense of humor and sarcastic wit [or lack thereof] is being viewed as statements of fact. Highly technical discussions are god awful boring. This is my personal blog and I'm not particularly interested in publishing white papers here. At the same, I firmly believe it is possible to have a technical discussion and be humorous. So I stand by the parts that are not humor because I have the experience [in production environments] to back it up. That said, the fact remains, I've lost and/or confused my reader(s) and that was not my intention. So I've made some minor changes to the original entry. The most important (I think) is adding the humor label/tag to the entry. So when I say, being smarter than millions is reason enough to learn shared memory concurrent programming, just know I'm joking. Unless, of course, you really feel that way. In which case, more power to ya!

    I'm posting a new entry which I hope will clarify things for Anonymous and JefH0821 and any other who didn't "get it". It is located here.