To view parent comment, click here.
To read all comments associated with this story, please click here.
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.






Member since:
2006-05-09
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...