Sign In
Register
Help
Post your comments for Intel exec: Programming for multicore chips a challenge here
Page 1 of 1
Intel exec: Programming for multicore chips a challenge
MultiQuote
#2
Jeffco8 
- Member
-
- Group: Members
- Posts: 73
- Joined: 26-March 01
Posted 02 April 2008 - 06:22 AM
It seems to me that the best solution is to let the OS and the Processor be the traffic cops for multicore systems. This keeps thing orderly, fast and allows for continued core expansion.
Apple has done some of this in Cocoa with NSOperations, which vastly simplifies writing multicore code.
Apple has done some of this in Cocoa with NSOperations, which vastly simplifies writing multicore code.
#3
adobephile
- Veteran
-
- Group: Banned
- Posts: 757
- Joined: 03-February 01
Posted 02 April 2008 - 06:23 AM
Hopefully, this multi-core technology will indeed usher in a new era in software development.
Though I know this is an essentially separate factor, I see Adobe has included a 64-bit option in its Lightroom 2.0 Beta for those who are running it on new Intel hardware.
But throwing even tera or zetta bytes at a problem can be as ineffective as throwing money at it if the basic approach has been insane from the get go.
Military applications? Come on! We need to concentrate on learning how to communicate with each other and resolve issues long before they develop into military situations. What is that old Chinese line? "Man who throw first blow admit he run out of ideas."
Though I know this is an essentially separate factor, I see Adobe has included a 64-bit option in its Lightroom 2.0 Beta for those who are running it on new Intel hardware.
But throwing even tera or zetta bytes at a problem can be as ineffective as throwing money at it if the basic approach has been insane from the get go.
Military applications? Come on! We need to concentrate on learning how to communicate with each other and resolve issues long before they develop into military situations. What is that old Chinese line? "Man who throw first blow admit he run out of ideas."
#4
deemery
- Member
-
- Group: Members
- Posts: 292
- Joined: 22-January 05
Posted 02 April 2008 - 06:53 AM
Programming for multi-core chips is hard for several reasons:
1. Education of software engineers and programmers routinely ignores the large body of work in parallel and distributed systems that has grown up in the 80s and 90s. Concepts such as 'heisenbugs,' 'byzantine failure,' even the really fundamental notions of 'race condition' or 'deadlock' seem to be missing from the vocabulary of most developers.
2. Current popular programming languages "inhale vigorously." Ada83 provided a high-level set of constructs with implementation on multiprocessors back in the late 80s. Lessons learned from that went into Ada95. C, C and Java provide really poor mechanisms for constructing either parallel or distributed programs. Current threads models are the 'assembly language of concurrency', and that is not intended as a complement here.
3. Parallelizing "legacy technology" strikes me as unlikely to be successful. First, applications make a lot of bad implicit assumptions that they're single-threaded which cause all kinds of problems if you start to parallelize them. Second, see point #2; the potential to alias any variable in C by passing its address is a major problem for things like cache consistency and atomic updates.
4. Research is not the problem, there's lots of good research to build on. Education and tools are the problems. It's good to see "education" get mentioned, but what about better tools? I think that has to start with a re-examination of programming language principles; programming language design has pretty much gone out of fashion, and that's part of the problem. We need to apply the research into better tools (languages, static analysis/model checkers, etc).
dave
1. Education of software engineers and programmers routinely ignores the large body of work in parallel and distributed systems that has grown up in the 80s and 90s. Concepts such as 'heisenbugs,' 'byzantine failure,' even the really fundamental notions of 'race condition' or 'deadlock' seem to be missing from the vocabulary of most developers.
2. Current popular programming languages "inhale vigorously." Ada83 provided a high-level set of constructs with implementation on multiprocessors back in the late 80s. Lessons learned from that went into Ada95. C, C and Java provide really poor mechanisms for constructing either parallel or distributed programs. Current threads models are the 'assembly language of concurrency', and that is not intended as a complement here.
3. Parallelizing "legacy technology" strikes me as unlikely to be successful. First, applications make a lot of bad implicit assumptions that they're single-threaded which cause all kinds of problems if you start to parallelize them. Second, see point #2; the potential to alias any variable in C by passing its address is a major problem for things like cache consistency and atomic updates.
4. Research is not the problem, there's lots of good research to build on. Education and tools are the problems. It's good to see "education" get mentioned, but what about better tools? I think that has to start with a re-examination of programming language principles; programming language design has pretty much gone out of fashion, and that's part of the problem. We need to apply the research into better tools (languages, static analysis/model checkers, etc).
dave
#5
hayesk
- Member
-
- Group: Members
- Posts: 978
- Joined: 07-August 04
Posted 02 April 2008 - 08:04 AM
Jeffco, the OS can only be the traffic cop for so much. It can not decide how to parallelize data within a specific app. It can only put entire threads and processes on a single core.
Given that most software doesn't run efficiently on a single core, it's a big challenge to get skilled developers to make applications run well on multiple cores.
Given that most software doesn't run efficiently on a single core, it's a big challenge to get skilled developers to make applications run well on multiple cores.
#6 Guest__*
Posted 02 April 2008 - 10:19 AM
adobephile said:
Hopefully, this multi-core technology will indeed usher in a new era in software development.
Though I know this is an essentially separate factor, I see Adobe has included a 64-bit option in its Lightroom 2.0 Beta for those who are running it on new Intel hardware.
But throwing even tera or zetta bytes at a problem can be as ineffective as throwing money at it if the basic approach has been insane from the get go.
Military applications? Come on! We need to concentrate on learning how to communicate with each other and resolve issues long before they develop into military situations. What is that old Chinese line? "Man who throw first blow admit he run out of ideas."
Though I know this is an essentially separate factor, I see Adobe has included a 64-bit option in its Lightroom 2.0 Beta for those who are running it on new Intel hardware.
But throwing even tera or zetta bytes at a problem can be as ineffective as throwing money at it if the basic approach has been insane from the get go.
Military applications? Come on! We need to concentrate on learning how to communicate with each other and resolve issues long before they develop into military situations. What is that old Chinese line? "Man who throw first blow admit he run out of ideas."
Not that it is at all related to the article and sorry for my digression, but how do you communicate with people who are like the "Necromongers" in the movie "The Chronicles of Riddick" whose mantra is "convert or die"? If you try to communicate you may end up "stoned" like the Prophets of old. Additionally there will always be a need for computing power in all sectors -- financial, military, exploratory, personal, the Internet and it applications, etc. etc. Your quote of the Chinese proverb reminds me of one symbol on American currency, that of the Eagle whose vision is on the Olive Branch in one of it's talons, however that vision can change to the arrows in the other talon should attempts at the olive branch fail. That symbol is how America has and continues to try to operate in a World fraught with interesting circumstances.
Page 1 of 1
