Poll: How Soon Will Multithreaded Apps Dominate?

By Kevin Farnham (107 posts) on December 5, 2007 at 8:58 am

I've posted a new poll on the Threading Building Blocks home page. In a September poll, more than half of the respondants said they expect 16-core PCs to be available for under $1000 in 2012. If this actually happens, there's going to be a lot of idle hardware in homes and offices -- unless a lot of multithreaded software is available.

So, in this new poll, I pose the question:

When will multithreaded apps begin to dominate the marketplace?

The response options are:

  • Today
  • In a year or two
  • In 3 - 5 years
  • Not until at least 5 years from now
  • Never

What's your view on this? Go to the Threading Building Blocks home page and let us know.

Kevin Farnham, O'Reilly Media, TBB Open Source Community

Download TBB

Categories: Open Source, Parallel Programming, Threading Building Blocks

Comments (3)

December 6, 2007 3:36 AM PST

jseigh
 You need a "Don't know" option. Barring a killer app or two to wake up the market place, it might take a while.

Also, you might want to take a look at the correlations between having multi-core hardware and being able to program it and having a application that can benefit from multi-cores and a commitment of resources from management. Things *aren't* going to happen until all the right pieces are together enough times to make a difference. Wishing certainly won't make it happen.
December 6, 2007 9:24 AM PST


Mike Smith-Lonergan		 Man, I gotta wonder why people assume that multi-core *must* lead to multi-threaded, when my Windows box (and many general-purpose, multi-process systems) has 50-125 processes running concurrently? Given that I'm pushing at *least* one application to do something interactive for me at a time, and that there are so many background processes competing for resources, it's not uncommon to see both cores of my Core 2 Duo getting pushed pretty hard.

I'm sure glad that at those times where some background process is running away with one core, it's not *always* keeping me from being able to do the work I'm trying to stay productive in. [Sure, there's plenty of times where the runaway background process is disk-bound, and lagging my system despite plenty of CPU headroom, but that's a problem that will only *increase* as cores become more plentiful.]

In server environments, the need for multi-threaded apps is greater, since (at least in classical single-OS-per-blade deployments) there's usually only a single process that's doing the vast majority of the work in that environment. But then, even there we're seeing "resource sharing" across blades by virtualizing the platform - trying to make better use of even *single*-core CPUs where they're so often sitting idle when only a single OS is running on them.

I firmly believe that more multi-threaded apps will lead to better utilization of all this processing power, but I'm not convinced that more cores *demands* that *every* app must go multi-threaded. I suspect we'll continue to see plenty of multi-process, multi-OS utilization of each core, even without most developers climbing that very steep learning curve of multi-threaded development.
December 13, 2007 12:53 PM PST


David Schwartz		 While more cores don't demand that every application go multi-threaded, I think it will happen anyway. Once it's clear that you have to pay the costs of being multi-threaded because the graphics library, I/O library, or whatever that you're using requires thread-safety, you might as well get the benefits.

It's just like how every modern application is native 32-bit, whether or not it actually needs or benefits from that. In fifteen years, they'll all be native 64-bit.

Old programmers won't learn new tricks, they'll be replaced by new programmers.

Trackbacks (1)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*