Slashdot Mirror

← Back to Stories (view on slashdot.org)

Panic in Multicore Land

Posted by Zonk on 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.'"

10 of 367 comments (clear)

  1. Panic? by jaavaaguru · · Score: 4, Insightful

    I think "panic" is a bit of an over-reaction. I use a multicore CPU. I write software that runs on it. I'm not panicking.

    --
    Follow me
    1. Re:Panic? by shitzu · · Score: 4, Insightful

      Still, the fact remains that the x86 processors (due to the OS-s that run on them, actually) have not gone much faster in the last 5-7 years. The only thing that has shown serious progress is power consumption and heat dissipation. I mean - the speed the user experiences has not improved much.

    2. Re:Panic? by leenks · · Score: 5, Insightful

      How is an 80-core cpu a cut down version of a dual-CPU box? This is the kind of technology the authors are discussing, not your Core2 duo MacBook...

    3. Re:Panic? by Chrisq · · Score: 4, Insightful

      Yes panic is strong, but the issue is not with multi-tasking operating systems assigning processes to different processors for execution. That works very well. The problem is when you have a single CPU-intensive task, and you want to split that over multiple processors. That, in general, is a difficult problem. Various solutions, such as functional programming, threads with spawns and waits, etc. have been proposed, but none are as easy as just using a simple procedural language.

    4. Re:Panic? by ObsessiveMathsFreak · · Score: 4, Insightful

      That works very well. The problem is when you have a single CPU-intensive task, and you want to split that over multiple processors. That, in general, is a difficult problem.

      It is in general, an impossible problem.

      Most existing code is imperative. Most programmers write in imperative programming languages. Object orientation does not change this. Imperative code is not suited for multiple CPU implementation. Stapling things together with threads and messaging does not change this.

      You could say that we should move to other programming "paradigms". However in my opinion, the reason we use imperative programs so such is because most of the tasks we want accomplished are inherently imperative in nature. Outside of intensive numerical work, most tasks people want done on a computer are done sequentially. The availability of multiple cores is not going to change the need for these tasks to be done in that way.

      However, what multiple cores might do is enable previously impractical tasks to be done on modest PCs. Things like NP problems, optimizations, simulations. Of course these things are already being done, but not on the same scale as things like, say, spreadsheets, video/sound/picture editing, gaming, blogging, etc. I'm talking about relatively ordinary people being able to do things that now require supercomputers, experimenting and creating on their own laptops. Multi core programs can be written to make this feasible.

      Considering I'm beginning to sound like an evangelist, I'll stop now. Safe money says PCs stay at 8 CPUs or below for the next 15 years.

      --
      May the Maths Be with you!
    5. Re:Panic? by Saurian_Overlord · · Score: 5, Insightful

      "...the speed the user experiences has not improved much [in the last 5-7 years]."

      This may almost be true if you stay on the cutting edge, but not even close for the average user (or the power-user on a budget, like myself). 5 years ago I was running a 1.2 GHz Duron. Today I have a 2.3 GHz Athlon 64 in my notebook (which is a little over a year old, I think), and an Athlon 64 X2 5600+ (that's a dual-core 2.8 GHz, for those who don't know) in my desktop. I'd be lying if I said I didn't notice much difference between the three.

    6. Re:Panic? by johannesg · · Score: 4, Insightful

      Let's not be too harsh on ourselves. In most systems today, the bottleneck is the hard disk, not the CPU. No amount of threading will rescue you if your memory has been swapped out.

      I write large and complex engineering applications. I have a few threads around, mostly for the purpose of doing calculation and dealing with slow devices. But I'm not going to add in more threads just because there are more cores for me to use. I'll add threads when performance issues requires that I add threads, and not before.

      Most software today runs fine as a single thread anyway. The specialized software that requires maximum CPU performance (and is not already bottle-necked by HD or GPU access) will be harder to write, but for everything else the current model is just fine.

      If anything, Intel should worry about 99% of all people simply not needing 80 cores to begin with...

    7. Re:Panic? by Alsee · · Score: 5, Insightful

      spreadsheets, video/sound/picture editing, gaming, blogging

      Odd selection of examples. The processing of cells can almost trivially be allocated across 80 cores. Media work can almost trivially be split into chunks across 80 cores. Games usually relatively easy to split, either by splitiing the graphics into chunks or parallelizable physics or other parallelizable simulation aspects.

      Oh, and blogging.
      My optical mouse has enough processing horsepower inside for blogging.

      OPTICAL MOUSE CIRCUITRY:
      Has the user pressed a key?
      No.
      Has the user pressed a key?
      No.
      Has the user pressed a key?
      No.
      (repeat 1000 times)
      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!

      -

      --
      - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
  2. The future is here by downix · · Score: 5, Insightful

    What Mr Moore is saying does have a grain of truth, that generic will be beaten by specific in key functions. The Amiga proved that in 1985, being able to deliver a better graphical solution than workstations costing tens of thousands more. The key now is to figure out which specifics you can use without driving up the cost nor without compromizing the design ideal of a general purpose computer.

    --
    Karma Whoring for Fun and Profit.
  3. No problems for servers by TheLink · · Score: 5, Insightful

    For servers the real problem is I/O. Disks are slow, network bandwidth is limited (if you solve that then memory bandwidth is limited ;) ).

    For most typical workloads most servers don't have enough I/O to keep 80 cores busy.

    If there's enough I/O there's no problem keeping all 80 cores busy.

    Imagine a slashdotted webserver with a database backend. If you have enough bandwidth and disk I/O, you'll have enough concurrent connections that those 80 cores will be more than busy enough ;).

    If you still have spare cores and mem, you can run a few virtual machines.

    As for desktops - you could just use Firefox without noscript, after a few days the machine will be using all 80 CPUs and memory just to show flash ads and other junk ;).

    --