Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Supercomputing

Warning At SC13 That Supercomputing Will Plateau Without a Disruptive Technology 118

dcblogs writes "At this year's supercomputing conference, SC13, there is worry that supercomputing faces a performance plateau unless a disruptive processing tech emerges. 'We have reached the end of the technological era' of CMOS, said William Gropp, chairman of the SC13 conference and a computer science professor at the University of Illinois at Urbana-Champaign. Gropp likened the supercomputer development terrain today to the advent of CMOS, the foundation of today's standard semiconductor technology. The arrival of CMOS was disruptive, but it fostered an expansive age of computing. The problem is 'we don't have a technology that is ready to be adopted as a replacement for CMOS,' said Gropp. 'We don't have anything at the level of maturity that allows you to bet your company on.' Peter Beckman, a top computer scientist at the Department of Energy's Argonne National Laboratory, and head of an international exascale software effort, said large supercomputer system prices have topped off at about $100 million 'so performance gains are not going to come from getting more expensive machines, because these are already incredibly expensive and powerful. So unless the technology really has some breakthroughs, we are imagining a slowing down.'" Although carbon nanotube based processors are showing promise (Stanford project page; the group is at SC13 giving a talk about their MIPS CNT processor).
This discussion has been archived. No new comments can be posted.

Warning At SC13 That Supercomputing Will Plateau Without a Disruptive Technology

Comments Filter:
  • by Anonymous Coward on Wednesday November 20, 2013 @02:53PM (#45474695)

    The problem is that there are many interesting problems which don't parallelize *well*. I epmhasize *well* because many of these problems do parallelize, it's just that the scaling falls off by an amount that matters the more thousands of processors you add. For these sorts of problems (of which there are many important ones), you can take Latest_Processor_X and use it efficiently in a cluster of, say, 1,000 nodes, but probably not 100,000. At some point the latency and communication and whatnot just takes over the equation. Maybe for a given problem of this sort you can solve it 10 days on 10,000 nodes, but the runtime only drops to 8 days on 100,000 nodes. It just doesn't make fiscal sense to scale beyond a certain limit in these cases. For these sorts of problems, single-processor speed still matters, because they can't be infinitely scaled by throwing more processors at the problem, but they can be infinitely scaled (well, within information-theoretic bounds dealing with entropy and heat-density) by faster single CPUs (which are still clustered to the degree it makes sense).

    CMOS basically ran out of real steam on this front several years ago. It's just been taking a while for everyone to soak up the "easy" optimizations that were laying around elsewhere to keep making gains. Now we're really starting to feel the brick wall...

  • by fuzzyfuzzyfungus ( 1223518 ) on Wednesday November 20, 2013 @02:57PM (#45474747) Journal
    Even if you are willing to burn nigh unlimited power, thermals can still be a problem (barring some genuinely exotic approaches to cooling), because ye olde speed of light says that density is the only way to beat latency. There are, of course, ways to suck at latency even more than the speed of light demands; but there are no ways to suck less.

    If your problem is absolutely beautifully parallel (and, while we're dreaming, doesn't even cache-miss very often), horrible thermals would be a problem that could be solved by money: build a bigger datacenter and buy more power. If there's a lot of chatter between CPUs, or between CPUs and RAM, distance starts to hurt. If memory serves, 850nm light over 62.5 micrometer fiber is almost 5 nanoseconds/meter. That won't hurt your BattleField4 multiplayer performance; but when even a cheap, nasty, consumer grade CPU is 3GHz, there go 15 clocks for every meter, even assuming everything else is perfect. Copper is worse, some fiber might be better.

    Obviously, problems that can be solved by money are still problems, so they are a concern; but problems that physics tells us are insoluble are even less fun.
  • Re:Complete garbage (Score:5, Informative)

    by The Master Control P ( 655590 ) <ejkeever AT nerdshack DOT com> on Wednesday November 20, 2013 @03:26PM (#45474985)

    By definition, computers are scalable. Need more performance? Add more processing units/memory.

    BZZZT, WRONG.

    This is where you can stop reading, folks.

  • Re:So what? (Score:4, Informative)

    by fuzzyfuzzyfungus ( 1223518 ) on Wednesday November 20, 2013 @04:19PM (#45475473) Journal
    They have no choice in the matter, since nobody makes 500GHz CPUs; but there is a reason why (many, not all) 'supercomputers' lay out a considerable amount of their budget for very fast, very low latency, interconnects (myrinet, infiniband, sometimes proprietary fabrics for single-system-image stuff), rather than just going GigE or 10GigE and calling it a day, like your generic datacenter-of-whitebox-1Us does.

    There are problems where chatter between nodes is low, and separate system images are acceptable, and blessed are they, for they shall be cheap; but people don't buy the super fancy interconnects just for the prestige value.
  • Tianhe-2? (Score:4, Informative)

    by therealobsideus ( 1610557 ) on Wednesday November 20, 2013 @04:46PM (#45475863)
    Totally off topic, but I ended up getting drunk with a bunch of people that are here in town for SC13 last night. Those boys can drink. But I'm surprised that there wasn't more talk about Tianhe-2 there, and how Chinese is going to kick the US off the top 25 in international supercomputing.

Thus spake the master programmer: "After three days without programming, life becomes meaningless." -- Geoffrey James, "The Tao of Programming"

Working...