To read all comments associated with this story, please click here.
It's true. There is at least one startup in Massachussets that has been trying the same approach. The problem is, it's just not very effective. For example, I doubt that it can parallelize a quicksort algorithm, a perfect candidate for parallel processing. If it were any good, Intel, Microsoft and AMD would not continue to pour hundreds of millions of dollars into research labs around the world to find a solution to the parallel programming problem.
Truth is, Intel is scared. They are already comitted to the multithreaded route and, at this late stage of the game, they can't go back and change their multicore strategy without losing billions of dollars. Too bad. In my opinion, that's exactly what's going to happen. To find out why multithreading is not part of the future of parallel programming, read 'Nightmare on Core Street':
http://rebelscience.blogspot.com/2008/03/nightmare-on-core-street.h...
I read that article as well as the alternative it suggested. It's actually really really good reading for a quiet evening in.
I'm still having difficulties getting my head around the alternative approach with signals, nodes, etc
I'd highly recommend anyone who's interested in programming to read it.
For now, it's not very effective.
10 to 20 years down the road, compilers producing multithreaded apps out of singlethread code might just be another type of optimization.
Should it really have to though? Wouldn't it be better to have a standard library of routines and have it designed to use threads so the developer doesn't have to think about it?
Something I don't understand is why the C++ standard library hasn't been updated to include a threading API.
After following the large number of links with repeated information to get to that author's point, I think it's pretty mundane. They've tried this fine-grained message passing approach before in high performance computing applications (there was a company called Thinking Machines that did this) and found it to be difficult to program for a useful task. A bunch of DoD money was wasted on these projects.
There are cool algorithms which you can do in such fine-grained systems (for instance, GPGPU algorithms for data processing), but most day-to-day computer operations do not really require this work. Maybe if this sort of research pays off, we might have a good speech or vision recognition system, but it won't make MSWord run faster.
It depends on how one uses their computer. As long as you have more than one simultaneous process running on your computer, then the OS should be able to balance those processes between the available cores/CPUs.
Even if every process running on your computer is single-threaded, you'll still see some net benefit (even if the individual processes don't run any faster than they would on a single core).
indeed, but that hardly scale beyond 2-4 cores.
thing is that the only stuff that need on-going attention from a cpu is automated processes that scan, convert or otherwise work on massive piles of data.
and ones you hit a couple of those running at ones, your running into problems with supplying them with the raw data they work on.
most cpu time today is spent waiting for user input for a spreadsheet, editor or similar.







Member since:
2008-02-05
I really hope this is true. I think it's stupid that we're all buying n-core computers but most of the software we're running doesn't do parallel processing...