Breaking News
News & Analysis

Multicore programmers must 'think different'

3/21/2011 04:01 PM EDT
43 comments
NO RATINGS
More Related Links
View Comments: Newest First | Oldest First | Threaded View
Page 1 / 4   >   >>
Neo10
User Rank
Rookie
re: Multicore programmers must 'think different'
Neo10   5/23/2011 8:57:19 AM
NO RATINGS
I agree with Eric that we all, including I feel that parallel programming is hard. But if we take the problem space usually many of those in nature are not sequential, it is made sequential in our reference books/text books so that they can be imlpmented using the progamming language at hand and compiled to machine code. Infact it is the dearth of exposure during our formative years to the parallel nature of problems that makes us narrow minded later on in our careers. How often are we in our schools and colleges asked to write in a progam that offers parallel programming contructs, all we are taught and exposed to is c/c++ java, etc which have a bug legacy of tought and support to work on. It needs to be introduced early like in CS101 and it students would natutally take to it like fish to water.

Sheetal.Pandey
User Rank
Manager
re: Multicore programmers must 'think different'
Sheetal.Pandey   4/29/2011 12:13:44 PM
NO RATINGS
absolutely..engineers have to work both in hardware and sofwtare to have delvier the right stuff. it is always helpful for the embedded program if we have sofwatre engineers who undeerstand how hardware works and software engineers who know the limitations of hardware.

Eric Verhulst_Altreonic
User Rank
Rookie
re: Multicore programmers must 'think different'
Eric Verhulst_Altreonic   4/20/2011 9:11:48 AM
NO RATINGS
I certainly would love to see more female engineers. Never understood why they shy away from this no-muscles-involved domain. But to come back to the topic. Concurrent programming (the CSP type of paradigms) is exactly a way to reduce the number of things you have to keep in your head. It is a divide and conquer strategy. While a sequential program has a huge state-space to keep track off in the head, concurrency provides modularity and smaller state spaces. Each process can be a small, dedicated function. This reduces the global space problem to only look at how the modules are interacting. And as the protocol is then fixed, one can change any module without having to look at the state space of the other modules. Our programming model even achieves this across network and processor boundaries. How do you handle this with a single sequential thread on each processor? It is vastly more complex and close to impossible.

KB3001
User Rank
CEO
re: Multicore programmers must 'think different'
KB3001   4/20/2011 8:56:49 AM
NO RATINGS
@Eric Verhulst_Altreonic, I heard such stories before (the Damascene conversion moment etc.) but they are the exception rather than the rule in my experience. Yes, the brain is parallel in its functionning, that's why it's good at tasks such as pattern matching but try to ask 100 kids to do 2 or 3 tasks at the same time and you'll see :-) Some can be trained to do it, but most would struggle. On a side comment, do not they say women are better at multi-tasking than men? Should not women then be better parallel programmers? May be we should invest in female parallel programmers :-)

Eric Verhulst_Altreonic
User Rank
Rookie
re: Multicore programmers must 'think different'
Eric Verhulst_Altreonic   4/19/2011 10:55:36 AM
NO RATINGS
I tend to disagree. If you know that the brain essentially works as a pattern matching neural net, then you know that if you train it in certain way, the pattern 'sticks' and the nit only seems like sequential thinking is more natural. For every carpenter, every problem can be solved with a hammer and a nail. I speak of personal experience. I only learned to program in parallel 10 years after I had learned to program (sequentially). Then I wanted to learn occam (the forgotten language based on CSP). I didn't get anywhere even after 1 month. Then I went to a training course and during the first exercise I made the mental switch, the typical Ha-Ha Erlebniss. From then one, I never understood my people wanted to make life so difficult by forcing everything to be programmed sequentially. The world is parallel and software programs are essentially models of such a world, so why not program in a natural way?

KB3001
User Rank
CEO
re: Multicore programmers must 'think different'
KB3001   4/19/2011 10:09:36 AM
NO RATINGS
I agree that the Economics have to be right, but practical experiences have shown that Computer Science students find it harder to program in parallel than in serial, FACT. I hence do not agree with Prof. Patt's assertion. Also, the human brain, while parallel in its functioning, is much more comfortable with deterministic sequential behaviour. As for the parallel programming question, it has to be a decision based on return on investment, yes. High level APIs or skeletons have to be developed for the average programmer for the sake of productivity, while low level parellel programming should be the craft of a few, when it is economically viable to do so.

wave.forest
User Rank
Manager
re: Multicore programmers must 'think different'
wave.forest   4/1/2011 1:20:39 PM
NO RATINGS
This kind of tools have been around since 1970s ...

gronk
User Rank
Rookie
re: Multicore programmers must 'think different'
gronk   3/31/2011 11:34:10 PM
NO RATINGS
Non-deterministic program execution is hard to debug. Ideally, one would do a Monte Carlo simulation to achieve coverage of all the possible outcomes. Fortunately, Monte Carlo simulations can be easily parallelized on multi-core computers ;)

DynamicLogic.US
User Rank
Rookie
re: Multicore programmers must 'think different'
DynamicLogic.US   3/31/2011 1:39:15 PM
NO RATINGS
Google engineers showcased android 3 honeycomb recently which is said to do efficient deserialization from c script like code. Those concepts address several of the issues mentioned above. Interested to hear how well it works for various problems.

DF0
User Rank
Rookie
re: Multicore programmers must 'think different'
DF0   3/25/2011 10:56:24 PM
NO RATINGS
The big nondeterminism-related issue with parallel programming is dealing with race conditions and timing. Depending on how quickly the different threads execute, you can get potentially completely different results. Compounding the problem is that such bugs are very difficult to reproduce, and may only occur under very unusual conditions. Structures like caches do not affect the actual program result, assuming of course that there's no bugs in the caches. The only nondeterminism that occurs is with how long the program takes to execute. In short, parallel programming can potentially make correctness nondeterministic.

Page 1 / 4   >   >>
Flash Poll
Radio
LATEST ARCHIVED BROADCAST
EE Times editor Junko Yoshida grills two executives --Rick Walker, senior product marketing manager for IoT and home automation for CSR, and Jim Reich, CTO and co-founder at Palatehome.
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Top Comments of the Week