Are you concerned about multicore? [closed]

Answer 1

I think what is likely to happen is that once large numbers of cores (say 8+) become commonplace, then we'll see development of applications that take advantage of parallelism that were not considered viable in a single-threaded world.

I cant think of specific examples, but consider what happened when 3D accelerators became common. Games at the time (think Doom) were bound by the speed of their software rendering code. Having highly-detailed 3D models, simulating reflection/refraction and per-pixel lighting were not even considered. Nowadays everyone does it.

So unless your current apps are highly CPU-bound, I would not worry about parallelising them. If you find you have heaps of CPU power via multiple cores, then look at ways to exploit it in new projects.

Answer 2

I've been programming with threads for over 15 years now. I am not worried in slightest

Answer 3

I would argue that for most programmers and applications, significant-multicore does not present a significant advantage or potential over standard multithreaded development. Most people have threads to accomplish sequential jobs, and there isn't that much potential for splitting up those threads to much smaller units.

IMHO, most benefits of significant-multicore would come from improvements to underlying frameworks (e.g., database access, IO, GUI and 3D toolkits, etc.), and the vast majority of developers would benefit transparently.

In addition, future static analysis tools may be able to recommend pieces that could be split further into threads.

Answer 4

Yeah, I've been programming with threads, too. But I'm not masochistic enough to love them. It's still way too easy to get cross-talk between threads, no matter how much of a super-man you are, plus whatever help you get from coworkers. Threads are easy to do, but very difficult to do correctly, so of course Joe-Schmoe gravitates to it, plus, they're fast! (which is all that matters, of course)

On *nix, good old fork() is still a good way to go for many things. The overhead is not too bad (yes, I'll need to measure that to back up my BS some day), particularly if you are forking an interpreter, then generating a bunch of task specific data in the child process.

That said, child processes are hideously expensive on Windoze, I'm told. So the Erlang approach is looking pretty good: force Joe Schmoe to write pure functions and use message passing instead of his seemingly-infinite-state automata global (instance) variable whack-fest with bonus thread cross-talk extravaganza.

But I'm not bitter :-)

Revision / comment:

Excellent comment elsewhere about distance-to-memory. I had been thinking about this quite a bit recently as well. Mark-and-sweep garbage collection really hurts the "locality" aspect of running processes. M/S GC on 0 wait state RAM on an old 80286 may have seemed harmless, but it really hurts on multi-level caching architectures. Maybe referencing counting + fork/exit isn't such a bad idea as a GC implementation in some cases?

---

edit: I put some effort into backing up my talk here (results vary): http://roboprogs.com/devel/2009.04.html

Answer 5

Are your programs typically CPU bound?

If not, forget it. It doesn't concern you, and gives your users a smoother experience without making any demands on you at all.

Cool, eh?

If you are CPU bound, and your problem is parallelizable, you might be able to leverage the multiple cores. That's the time to start worrying about it.

---

From the comments:

Suggestion for improving answer: give rough explanation of how to tell if your program is CPU bound. – Earwicker

CPU bound means that the thing preventing the program from running faster is a lack of computational horse-power. Compare to IO bound (or sometimes network bound). A poor choice of motherboard and processor can result in machines being memory bound as well (yes, I'm looking at you, alpha).

So you'll need to know what your program is doing from moment to moment (and how busy the machine is...) To find out on a unix-like systems run top. On windows use the taskmanager (thanks Roboprog).

On a machine with a load less than 1 per core (i.e. your desktop machine when you're not doing much of anything), a CPU bound process will consistently have more that 50% of a processor (often more than 90%). When the load average is higher than that (i.e. you have three compiles, SETI@home, and two peer-to-peer networks running in the background) a CPU bound process will have a large fraction of (# of cores)/(load average).

Answer 6

One of my hardware-oriented professor tells us (well, preaches), that this is a massively important area of Computer Science. More so, it'll be addressed either by the OS (I noticed Apple is hitting this strong, MS is probably as well), or the coder himself will need to be thinking about parallel execution (threading, etc...).

Quite a neat area of CS. :)