Crystal Ball Panel: The Futures of Supercomputing

1
Crystal Ball PanelThe Futures of Supercomputing

• William Groppwww.mcs.anl.gov/gropp

2
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

3
But I Saw A Demo At Supercomputing!

• Clarkes Third law
• Any sufficiently advanced technology is
  indistinguishable from magic
• Demo gap
• Corollary to Clarkes 3rd law
• Any sufficiently rigged demo is indistinguishable
  from magic
• Gropps conjecture
• All supercomputing demos are sufficiently rigged
• There are two futures

4
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/port
  ability)
• Tools are fragile
• Scalability means scales to as many as two (far
  future eight)
• I/O for applications measured in MB/sec

5
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

6
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 isnt that the
  developers arent working hard enough
• Feynman, on seeing a 10 page proof, observed that
  if the proof is that long, you havent achieved
  understanding.
• The fact that so much software is so flakey says
  that we dont understand the underlying
  principles and approaches

7

• 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 dont make grandiose plans
• Recall the quote about MULTICS from Dan Reeds
  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

8
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