The Trouble with Multicore
spectrum.ieee.org
The Trouble with Multicore
1–10 of 27 posts
Re: The Trouble with Multicore
#2Yawn. Another "OMG programmers can't handle multicore!" bullshit article.
I do threads all the time, and there are lots of things out there like various MapReduce toolkits that make it even easier than dealing directly with threads if you want. Threads are not that hard. It just takes an understanding followed by some practice to get a sense for it.
Re: The Trouble with Multicore
#3Repost of http://news.ycombinator.com/item?id=1477776
My response to this still stands: the problem is an education problem, little more. Read the full response here: http://news.ycombinator.com/item?id=1478331
Re: The Trouble with Multicore
#4Yawn. Another "OMG programmers can't handle multicore!" bullshit article. I do threads all the time, and there are lots of things out there like various MapReduce toolkits that make it even easier than dealing directly with threads if you want. Threads are not that hard. It just takes an understanding followed by some practice to get a sense for it.
Threads are not that hard.
I wouldn't quite say that, but perhaps rephrase it to Multicore is not that hard. Or maybe Concurrency is not that hard. (Basically, threads are just one abstraction for multicore/concurrent programming and I think its harder than some of the alternatives - its certainly a lower-level approach than others).
In any case, it isn't that hard. The problem is we're being educated to program sequentially and very little effort (relatively speaking) is being put into educating programmers to program concurrent/parallel multicore software. You cannot simply write a sequential program and then magically make it multi threaded. Good sequential algorithms are not good multicore algorithms and vice versa.
My response to the previous time this was posted to HN (linked in my other comment) explains what I mean.
Re: The Trouble with Multicore
#5Insert FP rant here
Re: The Trouble with Multicore
#6Counterpoint: The solution is multicore. http://www.darrylgove.com/2010/06/solution-is-multicore.html "1. Many problems just need parallelising once. 2. Given a number of cores, it is almost always possible to find work to keep them busy. 3. There are very few day to day tasks that are actually limited by processor performance."
Re: The Trouble with Multicore
#7Thats due to the fact that C++ is still without a standardized thread library, which works across all platforms.
Thus new students who start by C, C++ dont have proper exposure to the concepts of writting multi threaded applications.
I guess it is single biggest argument against C++
Re: The Trouble with Multicore
#8Thats due to the fact that C++ is still without a standardized thread library, which works across all platforms. Thus new students who start by C, C++ dont have proper exposure to the concepts of writting multi threaded applications. I guess it is single biggest argument against C++
This is untrue. First there is a stable boost::thread library available for a while, and second threads made it to the standard as well as futures.
I don't think the problem is the lack of a thread library, concurrency requires more than just being able to spawn and wait for threads.
Things like tasks managers, concurrent containers and transactional memory wrappers are better answers to the problem.
Re: The Trouble with Multicore
#9The "trouble" is only when you want a single process to monopolize the entirety of CPU resources. In today's (and even yesterday's?) processing environment, there are often tens if not hundreds of processes running at once, and 5 or 15 of them may be "performance critical".
Are multicore architectures not able to distribute this sort of load?
Re: The Trouble with Multicore
#10Thats due to the fact that C++ is still without a standardized thread library, which works across all platforms. Thus new students who start by C, C++ dont have proper exposure to the concepts of writting multi threaded applications. I guess it is single biggest argument against C++
This is untrue. First there is a stable boost::thread library available for a while, and second threads made it to the standard as well as futures. I don't think the problem is the lack of a thread library, concurrency requires more than just being able to spawn and wait for threads. Things like tasks managers, concurrent containers and transactional memory wrappers are better answers to the problem.
As someone who learned C++ few years back let me tell you that professors in Universities actively discourage use of Boost.
There is C++0x or which contains hashset and hashtable but even use of it is discouraged.
I think C++ standardization effort has become a joke and I doubt when we will see them being used in real life.
Even funny are people who claim to be waiting for emergence of D.(my professor said that he was waiting for andrecue or some one to finish his D book)