Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror
Programming IT Technology Hardware

Panic in Multicore Land 367

Posted by Zonk
from the multi-cores-no-waiting dept.
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.'"
This discussion has been archived. No new comments can be posted.

Panic in Multicore Land

Comments Filter:
  • by Hal_Porter (817932) on Tuesday March 11, 2008 @06:52AM (#22714064)
    Those +1 Informative links go to wikipedia [wikipedia.org], an online encyclopedia.
  • If we first assume that the human brain has a pretty interesting organization, then we should try to emulate it.

    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.
  • by thehatmaker (1168507) on Tuesday March 11, 2008 @07:31AM (#22714376)
    Looking back at history, we see that as clock speeds and memory capacity increased, software writing became simplified by the use of higher level languages whos output, while not as optimal as machine code programming, ran at a similar speed to previous generation hardware using well optmised machine code. And so, the "problem" of writing for faster machines was solved.

    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??
  • by imikem (767509) on Tuesday March 11, 2008 @07:34AM (#22714406) Homepage
    Would you like fries with that?
  • better idea (Score:3, Funny)

    by timster (32400) on Tuesday March 11, 2008 @07:43AM (#22714504)
    See, the thing to do with all these cores is run a physics simulation. Physics can be easily distributed to multiple cores by the principle of locality. Then insert into your physics simulation a CPU -- something simple like a 68k perhaps. Once you have the CPU simulation going, adjust the laws of physics in your simulation (increase the speed of light to 100c, etc) so that you can overclock your simulated 68k to 100Ghz. Your single-threaded app will scream on that.

    P.S.: I know why this is impossible, so please don't flame me.
  • Re:Panic? (Score:5, Funny)

    by divisionbyzero (300681) on Tuesday March 11, 2008 @07:47AM (#22714554)
    Developers aren't panicking. Their kernels are! Ha! Oh, that was a good one. Where's my coffee?
  • by Alex Belits (437) * on Tuesday March 11, 2008 @07:55AM (#22714650) Homepage
    Ugg is smart.
    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.
  • by Sapphon (214287) on Tuesday March 11, 2008 @08:03AM (#22714736) Journal
    The height of optimism: posting proof in the form of a 70-odd page thesis on a Slashdot.
    I don't think we'll be Slashdotting your server any time soon, CBravo ;-)
  • Re:Panic? (Score:3, Funny)

    by bdjacobson (1094909) on Tuesday March 11, 2008 @12:04PM (#22718714)
    Might take a look at Gentoo again with 80 cores. I'd be done compiling in just 2 days!
  • Re:Panic? (Score:3, Funny)

    by JoelKatz (46478) on Tuesday March 11, 2008 @01:35PM (#22720208)
    Bluntly, it doesn't sound like you have any idea what you're talking about, as nothing about what you said makes any sense at all. Why not stick to talking about thinks you understand? I'll just pick one example, but there are dozens:

    "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)

    by Sloppy (14984) on Tuesday March 11, 2008 @05:07PM (#22722664) Homepage Journal

    Nobody will buy an 80-core processor till there is software which would benefit from it.
    Fortunately, we already have that software. It's "make" with the "-j 80" option. Intel just needs to run a "Get Gentoo Now!" advertising campaign and their hardware marketing problem is solved.
  • Re:Panic? (Score:-1, Funny)

    by Anonymous Coward on Tuesday March 11, 2008 @05:13PM (#22722730)

    OPTICAL MOUSE CIRCUITRY: Has the user pressed a key? No. Has the user pressed a key? No. ... Has the user pressed a key? Yes. OOOO! YES! QUICK QUICK QUICK! HURRY HURRY HURRY! PROCESS A KEYPRESS! YIPEE!
    What's your optical mouse circuitry doing in your keyboard?!

When you don't know what you are doing, do it neatly.

Working...