Panic in Multicore Land 367
MOBE2001 writes "There is widespread disagreement among experts on how best to design and program multicore processors, according to the EE Times. Some, like senior AMD fellow, Chuck Moore, believe that the industry should move to a new model based on a multiplicity of cores optimized for various tasks. Others disagree on the ground that heterogeneous processors would be too hard to program. The only emerging consensus seems to be that multicore computing is facing a major crisis. In a recent EE Times article titled 'Multicore puts screws to parallel-programming models', AMD's Chuck Moore is reported to have said that 'the industry is in a little bit of a panic about how to program multicore processors, especially heterogeneous ones.'"
Re:Not *that* Chuck Moore (Score:5, Funny)
Re:Should Mimick The Brain (Score:5, Funny)
I think it's pretty obvious there are serious design flaws in the human brain. And I'm not only talking about stability, but also reliability and accuracy.
Just look at the world.
Simple well tested solution. (Score:1, Funny)
For the multicore problem, I propose a similar strategy. Simply write a natural language programming interface which uses n-x cores to interpret and compile the code into a mish mash of bloated machine code, which then runs on the remaining x number of cores. Of course, several remaining cores would be needed to run this bloated mess at speeds comparable to 486's - but at least the new hardware could be widely sold, thus supporting industry!
Its not like the users really need faster software, they just need a reason to upgrade to better hardware, right?? right??
Re:Let's see the menu (Score:5, Funny)
better idea (Score:3, Funny)
P.S.: I know why this is impossible, so please don't flame me.
Re:Panic? (Score:5, Funny)
Current state of software development (Score:5, Funny)
Ugg can program a CPU.
Two Uggs can program two CPUs.
Two Uggs working on the same task program two CPUs.
Uggs' program has a race condition.
Ugg1 thinks, it's Ugg2's fault.
Ugg2 thinks, it's Ugg1's fault.
Ugg1 hits Ugg2 on the head with a rock.
Ugg2 hits Ugg1 on the head with an axe.
Ugg1 is half as smart as he was before working with Ugg2.
Ugg2 is half as smart as he was before working with Ugg1.
Both Uggs now write broken code.
Uggs' program is now slow, wrong half the time, and crashes on that race condition once in a while.
Ugg does not like parallel computing.
Ugg will bang two rocks together really fast.
Ugg will reach 4GHz.
Ugg will teach everyone how to reach 4GHz.
+1 Optimistic (Score:4, Funny)
I don't think we'll be Slashdotting your server any time soon, CBravo
Re:Panic? (Score:3, Funny)
Re:Panic? (Score:3, Funny)
"But you're still left with the issue that the application may not be written to be thread safe - so now, your kernel does something (even if that is thread safe!) on a different core whilst the program continues on the original core and it has an adverse affect on the application since it happens faster than the application needs it to. (Been there - done that. Big problem and hard to find and resolve.)"
A single core that was faster would have the same problem. If the application breaks if things happen "too fast", it *needs* to run slow. There's no hope of speeding it up without fixing it anyway. What does that have to do with multiple cores? Nothing.
Okay, one more:
"If the app was only designed for a single processor, then there will be all kinds of timing issues that will arise including but not limited to race conditions."
This makes absolutely *NO* sense. I defy you to present a single case of an application designed for a single processor that runs into problems when the kernel does work on another processor.
And, this claim:
"Now OS's mitigate a lot of these issues by leaving things mostly the same - programs typically operate on a single core just like they would have if there only existed a single core and single processor in the system - changing that would break a lot of applications, which OS kernel vendors have no desire to do - especially Microsoft."
I cannot believe that you have any idea what you're talking about. When you say "changing that", what are you talking about? What is it that OS kernel vendors aren't changing? They've made just about every possible change to support SMP and multicore that they could think of. If there's some change they have no desire to do, please tell us what it is.
Re:Panic? (Score:4, Funny)
Re:Panic? (Score:-1, Funny)