Although Horst Simon was named Deputy Director of Lawrence Berkeley National Laboratory, he maintains his strong ties to the scientific computing community as an editor of the TOP500 list and as an invited speaker at conferences.
Twice during the week of May 6, Simon gave back-to-back presentations of a new talk on “Why We Need Exascale and Why We Won’t Get There by 2020.” Not only was the talk a hit with conference attendees, but it also made its way onto Slashdot. In this HPCwire exclusive, Simon talks about his presentation with Jon Bashor of Berkeley Lab.
Simon is well positioned to discuss the path to exascale. An internationally recognized expert in computer science and applied mathematics, he joined Berkeley Lab in 1996 as director of the newly formed National Energy Research Scientific Computing Center (NERSC), and was one of the key architects in establishing NERSC at its new location in Berkeley. Under his leadership NERSC enabled important discoveries for research in fields ranging from global climate modeling to astrophysics. Simon was also the founding director of Berkeley Lab's Computational Research Division, which conducts applied research and development in computer science, computational science, and applied mathematics.
In his prior role as Associate Lab Director for Computing Sciences, Simon helped to establish Berkeley Lab as a world leader in providing supercomputing resources to support research across a wide spectrum of scientific disciplines. Simon’s research interests are in the development of sparse matrix algorithms, algorithms for large-scale eigenvalue problems, and domain decomposition algorithms for unstructured domains for parallel processing. His algorithm research efforts were honored with the 1988 and the 2009 Gordon Bell Prize for parallel processing research. He was also member of the NASA team that developed the NAS Parallel Benchmarks, a widely used standard for evaluating the performance of massively parallel systems. He is co-editor of the twice-yearly TOP500 list that tracks the most powerful supercomputers worldwide, as well as related architecture and technology trends.
Question: On two consecutive days in early May, you gave a talk on “Why we need Exascale and why we won’t get there by 2020,” first at the IEEE Optical Interconnects meeting in Santa Fe and then at the Cray User Group meeting in Napa. What’s your thinking that led to the presentation?
Horst Simon: Well, everybody is talking about Exascale these days. Petaflop/s systems are firmly established in the HPC ecosystem and people are looking ahead to when we will see an exaflops/s machine. My position is that the methods we have been using to predict when we cross certain thresholds, like teraflop/s and petaflop/s no longer apply.
Q: Why not?
Simon: The TOP500 List, of which I am one of four editors, is marking its 20th anniversary as the chronicler of HPC performance. When it was started 20 years ago, the technology was transitioning from vector systems to massively parallel processing systems, or MPP. Now, back then “massively parallel” referred to machines with 64, 128 or even 256 CPUs. The TOP500 list was created to help understand this transition and to define what was a “supercomputer.”
If you look at the growth curve of performance over those 20 years, it is clearly influenced by Moore’s Law and parallelism. It’s not a surprising trajectory and if in 1992 someone said the first teraflop/s system would appear by such-and-such a date, they had a good chance of being correct. But we can’t say that for the next eight to 10 years. For one thing, it’s not clear what architecture will get us to exascale. Many look at the performance growth that is clearly visible over the last 20 years on the TOP500 list, and then just simply extend the straight line from today for another 10 or 12 years. This “straight line” extrapolation thinking is wrong. I think that the computing world faces a fundamental technology transition that will disrupt this simple extrapolation.
Q: How do current architectures fit into the picture?
Simon: We are currently following three different paths, each of which claims one of the top three slots on the latest TOP500 list.
The multicore path is built around high-end CPUs, such at Intel’s x86, SPARC and IBM’s Power 7. The Manycore/embedded approach uses many simpler, low power cores from embedded systems. Finally, there is the GPU/accelerator path using highly specialized processors from the gaming/graphics market space, such as NVIDIA’s Fermi, the Cell processor and Intel’s Xeon Phi (MIC).
Titan, the No. 1 system at Oak Ridge, uses the GPU/accelerator approach. The manycore embedded processor path has led to Blue Gene, which is as No. 2. And the K computer, using SPARC CPUs, is at No. 3.
One way to look at the race to exascale is as a swim meet. There are three swim lanes, each heading toward the same goal. But who do you bet on to win the race? If you choose too soon, your users cannot follow you. If you choose too late, you fall behind on the performance curve. And if you choose incorrectly, your users face multiple disruptive changes in the technology they rely on.
For the three swim lanes, the multicore path could hit a dead end, as seen by IBM’s cancellation of its contract for Blue Waters. Is this an indication that multicore with complex cores is nearing the end of the line? In the embedded lane, Blue Gene is the last of the line. Will there be any more large-scale embedded multicore machines? And with GPU/accelerators, Intel bought Cray’s interconnect technology and WhamCloud. Will Intel develop complete systems?
I’m willing to bet that by 2015, all top 10 systems on the TOP500 list will be GPU/accelerator-based.
Q: So, is there any good news out there in HPC?
Simon: Sure. First, the field is alive and well – there is worldwide interest in HPC as seen by more countries deploying large-scale systems. And if you look at the three swim lanes today, it’s an exciting race with all three approaches thriving. IDC is predicting rapid growth over the next three years and many countries have exascale projects in motion.
Q: But back to the theme of your talk, why won’t we get to exascale by 2020?
Simon: You could say that the end of the HPC world as we know it began in 2004, when we hit the inflection point of power use and clock speed. That’s when we realized that we could not keep increasing clock speed due to power demands (and heat), but needed to move to much greater parallelism.
Exascale has been discussed in numerous workshops, conferences and planning meetings for about six years now. In 2006, I co-organized the first exascale town hall meetings that led to the first exascale report. This was done jointly with Rick Stevens of Argonne and Thomas Zacharia, then of Oak Ridge. The title of the report was “Modeling and Simulation at the Exascale for Energy and the Environment.” In that paper, we noted that we were facing many changes in the design of supercomputers, but we didn’t originally want to call this an “exascale” initiative. It was clear to us that the challenge was in managing new architectures, programming models, dealing with truly massive parallelism and solving the power problem. But Ray Orbach, then head of the DOE Office of Science, thought “Exascale” would make it easier for Congress to understand and support the concept. Instead of focusing on the technology challenges and the scientific impact, the initiative was packaged as a race to reach a fixed goal.
I think there continues to be a lot of vagueness in the overall discussion of exascale, as well as what it means to reach exascale. So, let me propose a concrete and measurable goal: Build a system before 2020 that will be No. 1 on the TOP500 list with an Rmax greater than 1 exaflop/s.
On a side note, I have a personal bet on this with Thomas Lippert, head of the Jülich supercomputing center in Germany, that we will not reach this goal by November 2019. The bet is for $2,000 or €2000, and I think I will win. But I’d rather lose if it means we would have an exascale system by then.
Q: Ok, so you have personal stake in this. But what are the obstacles to getting there?
Simon: It’s not a single big technical issue, but rather a combination of challenges.
The first is just measuring the performance of such a system. Even at petascale, running the LINPACK benchmark is a challenge – you have to turn the whole machine over for 25 to 30 hours. When center managers are under pressure to make as many cycles available as possible, how many 30-hour LINPACK runs can be tolerated? At exascale, it will take five to six days to run the same LINPACK benchmark.
Then there are the total power issues. The K computer uses 12 to 13 megawatts. The machines are scalable, but the buildings, power supplies, etc., are not.
The increasing trend in power efficiency – though it might look like a gradual slope over time, is really a one-time gain that came from switching to accelerator/manycore in 2010. This is not a sustainable trend in the absence of other new technology. There is no more magic – we’re maxed out. Right now, the most efficient system needs one to two megawatts per petaflop/s. Multiply that by 1,000 to get to exascale and the power is simply unaffordable.
Also, data movement will cost more than flops (even on the chip). Limited amounts of memory and low memory/flop ratios will make processing virtually free. In fact, the amount of memory is relatively decreasing, scaling far worse than computation. This is a challenge that’s not being addressed and it’s not going to get less expensive by 2018.
But I do need to point out that there is progress in exascale in the U.S. with many projects now focused and on their way, including DOE’s FastForward, Xstack and co-design centers.
I also think calling the system exa-anything is a bad idea. It’s become a bad brand, associated with buying big machines for a few national labs. It also sets the community up for a perceived failure if we don’t get to exaflops. As an example of avoiding a bad name, the project at CERN was named the Large Hadron Collider, not the “Higgs Boson Finder.” The LHC would have been also successful if there would have been no Higgs, because it would have led to new physics. However, an “exascale” initiative that does not produce an exaflop/s system will likely be seen as a failure, no matter how much great science we can do on the systems being developed.
Q: You mentioned “old” HPC in your presentation. Can you elaborate on that? And maybe explain what you think “new” HPC is?
Simon: We are actually changing the whole computational model and current programming systems have the wrong optimization targets. For example, the “old” HPC constraints were peak clock frequency as the primary limiter for performance improvement; flop/s are the biggest cost for systems, so they are optimized for compute; concurrency was modestly increased by adding nodes; for memory scaling we maintain byte-per-flop capacity and bandwidth; we assume uniform system performance; and reliability is seen as the hardware’s problem.
In “new” HPC, power is the primary design constraint for future HPC system design; data movement dominates costs, so we need to optimize to minimize data movement; to increase concurrency we look to exponential growth of parallelism within chips. As I mentioned, memory scaling is a big constraint, with compute growing two times faster than capacity or bandwidth. Due to heterogeneity, architectural and performance non-uniformity will increase and when it comes to reliability, we cannot count on hardware protection alone.
This “new” reality fundamentally breaks our current programming paradigm and computing ecosystem.
Q: You also mentioned in your talk that exascale computing, if we can call it that, will usher in a different kind of computational science. Can you give an example?
Simon: I think we really need to think about the new applications that will emerge in the next 10 years. The BRAIN Project, or Brain Research through Advancing Innovative Neurotechnologies, is a $100 million proposal by President Obama in his FY2014 budget. The goal is to create real-time traffic maps to provide new insights into brain disorders. As many people know, using HPC to study, understand and simulate brain functions is an ongoing research area. A straightforward extrapolation of the resources needed to create a real-time human brain scale simulation shows we need about 1 to 10 exaflop/s with 4 petabytes of memory. So in addition to all the existing science challenges that require computational resources, there are clearly exciting new ones that the computing community needs to take on.
As an aside, and I always like to make this point: the most optimistic current predictions for exascale computers in 2020 envision a power consumption of – at best – 20 to 30 megawatts. By contrast, the human brain takes about 20 to 40 watts. So, even under best assumptions in 2020, our brain will still be a million times more power efficient.
Q: You’ve addressed half the title of your talk – why we won’t get to exascale by 2020. Can you conclude by talking about why we need exascale computing?
Simon: To maintain the U.S. competitive advantage, we need exascale resources. For example, digital design and prototyping at exascale will enable rapid delivery of new products by minimizing the need for expensive, dangerous, and/or inaccessible testing. I think exascale could be the potential key differentiator for American competitiveness and that we need strategic partnerships between DOE labs and industrial partners to develop and scale applications to exascale levels.
Exascale computing is also key for our national security. Other countries are making plans for exascale and this could impact our security – former Defense Secretary Robert Gates said in a 2011 interview with the New York Times that one nation with a growing global presence is much farther ahead in aircraft design than our intelligence services had thought, and HPC plays a very important role in aircraft design.
Finally, exascale technologies are the foundation for future leadership in computing. We have the lead and shouldn’t declare victory and go home. I recently read Niall Ferguson’s book “Civilization – the West and the Rest”. In the book, Ferguson recalls the story of Zheng He, a Chinese admiral who sailed from China to Indonesia, , to India and as far as the east coast of Africa in 1416. This was decades before Spanish and Portuguese explorers started their voyages. The potential for trade and economic gain from such trade routes was enormous, but the Chinese emperor decided that such exploration was a waste of money and abruptly canceled any further trips – when China was ahead.
The U.S. is not the only country capable of achieving exascale computing. But just like the Chinese emperor in the 15th century, Congress has stopped us now with insufficient funding to move ahead and explore the new frontiers of computing. If we stop now, the country that is first to exascale will have significant competitive, intellectual, technological and economic advantages. And achieving the power efficiency and reliability goals we need for exascale will have enormous positive impacts on consumer electronics and business information technologies and facilities. As I said, other countries are also in this race, motivated both by the tangible advantages to be gained and the national pride of being first to the finish line.
This article originates from HPCwire (www.hpcwire.com) http://www.hpcwire.com/hpcwire/2013-05-15/no_exascale_for_you_an_interview_with_nersc_s_horst_simon.htmlShare on Twitter Share on Facebook
|1|| Tianhe-2 (MilkyWay-2) - TH-IVB-FEP Cluster, Intel Xeon E5-2692 12C 2.200GHz, TH Express-2, Intel Xeon Phi 31S1P
|2|| Titan - Cray XK7 , Opteron 6274 16C 2.200GHz, Cray Gemini interconnect, NVIDIA K20x
|3|| Sequoia - BlueGene/Q, Power BQC 16C 1.60 GHz, Custom
|4||K computer, SPARC64 VIIIfx 2.0GHz, Tofu interconnect
|5|| Mira - BlueGene/Q, Power BQC 16C 1.60GHz, Custom
|6|| Piz Daint - Cray XC30, Xeon E5-2670 8C 2.600GHz, Aries interconnect , NVIDIA K20x
|7|| Stampede - PowerEdge C8220, Xeon E5-2680 8C 2.700GHz, Infiniband FDR, Intel Xeon Phi SE10P
|8|| JUQUEEN - BlueGene/Q, Power BQC 16C 1.600GHz, Custom Interconnect
|9|| Vulcan - BlueGene/Q, Power BQC 16C 1.600GHz, Custom Interconnect
|10|| SuperMUC - iDataPlex DX360M4, Xeon E5-2680 8C 2.70GHz, Infiniband FDR