Crystal Ball Panel:The Futures of Supercomputing

William Groppwww.mcs.anl.gov/~gropp

University of Chicago Department of Energy

Where Are We?

• Scientists are doing new science• We have “commodity” supercomputing• But…

Programming and debugging, both for correctness and performance, is painful

System administration is hell Key software is being developed in public, not just

debugged I/O stinks (how many talks used “I/O” and “broken”

in the same breath?) Users discover problems, not the system, not the

operators, …

• Triumph of hope over experience

University of Chicago Department of Energy

But I Saw A Demo At Supercomputing!

• Clarke’s Third law: Any sufficiently advanced technology

is indistinguishable from magic• Demo gap

Corollary to Clarke’s 3rd law:• Any sufficiently rigged demo is

indistinguishable from magic Gropp’s conjecture

• All supercomputing demos are sufficiently rigged

• There are two futures:

University of Chicago Department of Energy

The Demo Future

• Ever more impressive demos, but … Users still tell system admins about errors in

the system software Users must choose between programming

at a low level (but (maybe) getting performance) or at a high level (but losing generality/performance/portability)

Tools are fragile Scalability means “scales to as many as

two” (far future: eight) I/O for applications measured in MB/sec

University of Chicago Department of Energy

The Stop Kidding Ourselves Future

• Applications work! Without any handholding by the tool

developers• Handholding does not scale

• Tools work• No handholding (repeat: no handholding)

• I/O for applications measured in GB/sec• Most scientists stop programming

Instead, they use tools and environments

University of Chicago Department of Energy

How Do We Get There?

• Emphasize robust tools that scale and interoperate E.g., Scalable Systems Software SciDAC

• Recognize the realities of HPC systems and design solutions (both hardware and software) that are for this universe

• Invest in the science of creating and maintaining high-quality software for HPC There are reasons why there are so few examples of good

HPC software, and it isn’t that the developers aren’t working hard enough

Feynman, on seeing a 10 page proof, observed that if the proof is that long, you haven’t achieved understanding.

• The fact that so much software is so flakey says that we don’t understand the underlying principles and approaches

University of Chicago Department of Energy

• Learn where to be new and where to live with a less than “perfect” solution

• Make no little plans If you give up standardization, you have to get a lot

back for it

• But don’t make grandiose plans Recall the quote about MULTICS from Dan Reed’s

talk

• Understand application needs Not what it desires, what it needs “I want to invert a matrix” — Not!

• Work with others Open processes to develop common interfaces

University of Chicago Department of Energy

We Can Get There

• We must set ambitious but reasonable goals

• We must close the demo gap• We must chose solutions that scale

in terms of people, not just compute processors