Crystal Ball Panel: The Futures of Supercomputing William Gropp

University of ChicagoDepartment 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 ChicagoDepartment 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 3 rd law: Any sufficiently rigged demo is indistinguishable from magic  Gropp’s conjecture All supercomputing demos are sufficiently rigged There are two futures:

University of ChicagoDepartment 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 ChicagoDepartment 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 ChicagoDepartment 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 ChicagoDepartment 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 ChicagoDepartment 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