Confronting Parallelism: The View from Berkeley

To explore the important new paper on the challenges of parallelism, "The View from Berkeley," HPCwire talked with NERSC computer scientist John Shalf and David Patterson, professor of computer science at UC-Berkeley. Shalf and Patterson are among the co-authors of "The View from Berkeley."

HPCwire: To what extent has the HPC community learned how to exploit hardware and software parallelism during the past 20 years? Where do things stand today?

Shalf: When the HPC community migrated from vector to parallel machines in the early 90s, the transition was extremely difficult for the first five years. Now, 80 percent to 90 percent of codes have made that transition to MPPs [massively parallel processors] and the community has developed a substantial portfolio of parallel numerical algorithms.

As things stand today, the HPC community has become accustomed to modest increases in system concurrency over the past 15 years. For that matter, the desktop community has become accustomed to virtually no parallelism. As clock frequencies stall, future performance improvements will depend on accelerating the pace of parallelism -- doubling the concurrency of computer systems of all scales every 18 months! The assumptions on which the current generation of codes are founded will break very rapidly under this situation. The software changes necessary to ride this wave of exponentially increasing parallelism will be at least as substantial as the transition from vector to MPP systems.

Patterson: The industry is already betting on multicore for future improvements in computing performance. To use a football analogy, the computing industry has already thrown a "Hail-Mary" pass with the first round of multicore designs. The ball is in the air, but nobody is running yet. That's where things stand today.

HPCwire: Your report is called the "View from Berkeley." What is the view from Berkeley about the challenges of future parallel architectures?

Patterson: The overarching challenge is that we need to find ways to make it easy to write programs that run efficiently on manycore systems. If we don't succeed, then the future of the IT industry looks clouded, because the industry will then face diminishing returns on the value of buying new computers with more cores.

We also offer opinions on good paths to pursue. First, RISC, not CISC. Assuming we can program them, the most efficient hardware in FLOPS per watt and FLOPS per dollar is simple single-issue pipelined cores. Second, manycore, not multicore. We think the target should be hundreds to thousands of simple cores per socket, not four or eight. Third, autotuners, not compilers. We think generating parallel code by dynamically exploring the options heuristically on that computer is a more promising path than producing code only via conventional compilers. Finally, human-centric, not machine-centric programming models. Psychological research on how people design and why people make mistakes shapes HCI [Human–computer interaction] research, but not programming models. We think we should rely on experimental research from psychology to guide future parallel programming models.

Shalf: Underlying all of the arguments laid out in the report is the belief that manycore chip design is our ultimate path forward for future computing systems. We aren't so much wild-eyed advocates for the multicore approach as we are realists. I think Kurt Keutzer, one of the lead authors on the report, sums this up best when he says "This shift toward increasing parallelism is not a triumphant stride forward based on breakthroughs in novel software and architectures for parallelism; instead, this plunge into parallelism is actually a retreat from even greater challenges that thwart efficient silicon implementation of traditional uniprocessor architectures." If you don't accept Kurt's statement at face value, the report provides substantial arguments to turn your opinion around. If you accept that the future of computing is manycore, then the Berkeley View explores the ramifications of that assumption in detail.

Convergence toward manycore for mainstream chips is already apparent. There is the new NVIDIA CUDA GPU, which is moving from the highly specialized pixel and vertex processors of the previous generation of GPUs to 128 more general purpose cores. The recently announced Intel teraflop chip employs 80 simplified cores to hit one teraflop double-precision on a chip that consumes less than 70 watts. Cisco has moved away from its typical ASIC designs towards employing 192 Tensilica cores in the Metro chip, which is the heart of its new high-end CRS-1 router. The common thread is that using hundreds of simpler cores is more power-efficient than attempting to push the clock rate on a few complex cores.

HPCwire: Your new project is called RAMP. Can you tell us what RAMP is, and how it will help in the transition to more parallelism in future systems?

Patterson: RAMP stands for Research Accelerator for MultiProcessing. This project focuses on how can we build low cost, highly scalable hardware/software prototypes, given the increasing difficulty and expense of building hardware. A group of ten faculty members at six institutions (Berkeley, CMU, MIT, Stanford, Texas, and Washington) is exploring emulation of parallel systems via Field Programmable Gate Arrays (FPGAs). The idea is that although FPGAs are slower than real hardware, they are much, much faster than simulators. We believe they are fast enough for the parallel research community to use to evaluate novel ideas in parallel architecture, languages, libraries, and so on.

Despite the project being just 18 months old, we already have two interesting prototypes to demonstrate the potential of the project. For the RAMP Red prototype, Christos Kozyrakis of Stanford led the building of the first Transactional Memory computer using RAMP. This eight-processor system runs PowerPC Linux as the OS and runs SPLASH-2 benchmarks, the C-version of SpecJBB2000 (3-tier-like benchmark), and some AI apps. This single board system runs 100X faster than a simulator on an Apple 2GHz G5 (PowerPC). It should be able to scale to multiple boards relatively easily. In RAMP Blue, John Wawrzynek of UC Berkeley led the building of a message-passing computer using 256 MicroBlazes RISC cores provided by Xilinx, running on eight boards. We demonstrated it by running all the NAS benchmarks, written in UPC.

In both cases, the processors ran at 100 MHz. The RAMP emulation argument is that while this is, say, 20X slower than real hardware, it is plenty fast enough for researchers to run whole software stacks.

We also have a very low cost example. While the two RAMP projects used the BEE2 boards above, which cost about $10K, we also used the $300 XUP board from Xilinx to run full Debian Linux on a 32-bit SPARC processor that comes from an open source hardware group. You just grab the binaries and run them. It runs at 50 MHz. This group just created a multiprocessor version of the processor and a compatible version of Linux, so we expect to demonstrate very low-cost multiprocessors.

HPCwire: Do you think current scientific applications will scale to hundreds of thousands or processors?

Shalf: They have no choice. They have to scale to hundreds or thousands of processors if they have a need for increased performance. There are no alternatives waiting in the wings.

Patterson: It's a shocking statement, but the era of faster sequential processors is over. All hardware companies rely on parallelism for performance, and there are no plans for fast sequential processors.

HPCwire: What will be the biggest challenge for commercial applications -- when future multicore chips arrive with 32 to 128 cores?

Shalf: The programming model for managing massive parallelism has been driven by the needs of the HPC community. As such, it has evolved in a manner that is extremely complex so that it could suit the needs of a handful of parallel programming experts. I don't think the current model is appropriate for a broader audience of software developers. In fact, the complexity and arduousness of existing parallel software development environments is leading to what can only be characterized as widespread panic in the mainstream software development community.

Many commercial software vendors are attempting to side-step this issue by questioning why such high concurrency is necessary in the first place. Why would a word processor or PowerPoint require 128 cores? Does that annoying talking paper clip really need more compute power? That point of view is very short-sighted and limited primarily by a lack of imagination. As someone once said, we won't be done until we match the capabilities of the computers we see in our favorite science fiction, so we have a long way to go.

Patterson: We get questions along the lines of, "What could you possibly run than needs 128 cores on a laptop?" This reminds me of the story of the patent examiner in 1870 who decided that everything of importance had been invented, so he quit his job to look for something permanent. Or that 640KB ought to be enough memory for PCs. We think the most exciting software has yet to be written, and it's going to be highly parallel.

HPCwire: At what point will the current programming paradigm begin to break down?

Shalf: It is already broken. Witness the hand-wringing over Blue Gene/L. And yet, with the current path we're on, the concurrency of Blue Gene will be eclipsed by the first petaflop-scale systems based on more conventional multicore desktop computing technology. If the industry moves to manycore, as our report suggests is our ultimate destination, then the concurrencies, represented as the number of cores, will expand by another order of magnitude.

Patterson: I agree with John. Threaded applications like J2EE are ready for lots of threads, so they'll be okay, at least for multicore servers, but it's not clear what is the right model with thousands of threads.

HPCwire: What attributes will the future programming model need?

Shalf: It has to be human-centric and focused on how users interact with systems. It has to be this way to reduce errors and to reduce uncertainty in the results when errors occur. There are the competing requirements of exposing all the features of the hardware so that experts can tune it, versus providing an elegant way of expressing the problem, such as domain-specific languages.

Often, computer scientists depend on introspection to design next-generation programming languages or the elements of new programming models. Tim Mattson of Intel pointed out to our group that when psychologists actually tested these assumptions, they often found the introspection to be dead wrong. Given that the process of programming is done by humans, it would be good to use the tools of psychology to pick apart that process.

Patterson: The "View from Berkeley" talks mainly about the process that John mentioned, but there are a few specifics that seem glaringly obvious. To maximize programmer productivity, programming models should be independent of the number of processors, allow programmers to use a richer set of data types and sizes, and they should support successful and well-known parallel models of parallelism: independent task parallelism, word-level data parallelism, and bit-level data parallelism.

HPCwire: How do you get people to move to a new paradigm when there's always some pain involved?

Shalf: People will adopt a new programming model only when their backs are against the wall. The rapid acceleration of system concurrency is going to press our backs against that wall in short order. When MPPs began to supplant the vector machines, scientific application developers explored alternative strategies including PVM, MPI, and eventually HPF to see which software ecosystem provided the right direction for the future. The MPI plus Fortran and C ecosystem has been stable for years due to relative stability in the underlying hardware platform. The hardware climate is about to change considerably, so the ecosystem is going to have to evolve to accommodate those changes.

HPCwire: With exponentially increasing concurrency, will some of today's "embarrassingly parallel" applications need to be renamed "humiliatingly parallel"?

Patterson: I've always been struck that we apologize when we do have success at parallelism. There is nothing wrong with task-level parallelism, like we see at Google. The fact that important codes like Monte Carlo or MapReduce are highly parallel is a good thing. We should change the labels to "successfully parallel" or "brilliantly parallel."

Shalf: Attention to locality of communication is the essential feature that enables good scaling, and that can be very difficult to design. For instance, the Cactus Computational Toolkit, which has consumed a large fraction of my life as a contributing developer, scales efficiently to tens of thousands of processors, but it has very demanding communication requirements. It scales because the requirements are well localized by design – not because the communication is trivial.

I agree with Dave that we need to change the lexicon. It is neither embarrassing nor trivial to write scalable algorithms, nor should it be "humiliating" to employ algorithms that are naturally scalable.

HPCwire: To what extent will current algorithms and codes need to be fundamentally rethought and rewritten?

Patterson: In the past, it wasn't clear if it was worth the effort, as you could wait for faster uniprocessors. If you care about performance, there is now no choice but to parallelize. We also comment in the paper that in the past, programmers thought less than linear speedup on an MP was a failure. The new conventional wisdom is that given the universal switch to parallel computers, any speedup via parallelism is a success. Hence, now is the time to rethink and rewrite.

Shalf: The designs of current codes are founded on assumptions that are no longer true. This is natural. Nothing lasts forever.

HPCwire: How much can the HPC community be helped by other domains, such as embedded computing?

Patterson: To the surprise of the representatives of HPC and embedded computing in our group, there is more in common than either group expected. Both embraced parallelism long before the desktop computing community, and both seem more willing to change codes to embrace parallelism than the desktop community.

Shalf: The Cisco Metro chip and Blue Gene/L both provide examples of convergence toward manycore architecture, but they also point to a convergence between embedded and high-end computing technology. As Dave points out, the embedded and HPC worlds are not as far apart as originally thought, and the common need for more computationally efficient designs has pushed us even closer together. In the past, the desktop paradigm targeted performance at any cost. It was all about who could make the fastest processor. Two chief concerns going into the future are power consumption and cost effectiveness. While the desktop world is still in the process of turning their huge ship around, the embedded world has been concerned about optimizing cost and power consumption since its very inception! We have a lot to learn from the embedded computing industry.

Blue Gene is an excellent example of how the flow of innovation is starting to trickle upward from embedded computing to high-end computing rather than trickling down. This upward flow will increase in the future because the embedded folks know considerably more about power efficiency than the high-end computing market does.

Patterson: More specifically, as John says, the focus on energy efficiency is another common concern, as flops-per-watt are important for both battery life and to best use the limited power and cooling ability of a data center.

HPCwire: Can anything be done for legacy engineering codes that don't scale well and can't easily be rewritten because they've been certified based on years of experience and incremental refinements?

Shalf: I can appreciate that concern because I've spent some time as an engineer, and know how arduous the certification processes can be. Even in academic scientific applications such as numerical astrophysics, it takes years for a research group to convince themselves and their community that the code is producing credible answers. If they recode their applications, then they are subjected to a nontrivial revalidation process.

So, in short, it's going to be a real problem for them. We certainly don't have a magic bullet to offer. It's not even clear to me if the ultimate solution for them actually exists yet, even assuming they commit to recoding. The "View from Berkeley" report is identifying the future direction of computer architecture and defining a research agenda that matches the challenges that result from these changes. Since it is research, we are not claiming to have the answers a-priori. However, we are saying that failing to develop a good solution to these problems will guarantee failure for the industry as a whole.

HPCwire: How confident are you that the HPC community has the technical ability to overcome the challenges of increasing parallelism?

Patterson: If the HPC community doesn't have the technical ability, heaven help the hardware industry, which is betting its future on someone having this ability. I would think HPC has more people with experience at large scale parallelism than any other computing community. If this is not the case, then I think multicore will be another force pushing towards centralization of computing via software as a service. To put it simply, multicore and manycore are great for Google, even if it may be an exciting challenge to Microsoft.

Shalf: Necessity is the mother of invention. The HPC community is known to sustain considerable innovation in the face of sea changes in computer architecture. I'm not saying it won't be painful and potentially costly, but they can do it.

HPCwire: How confident are you that the HPC community has the will power to do this?

Shalf: It's not necessarily about will power. If they need more performance, there isn't some alternative architecture waiting in the wings to save them. Our current field of algorithms is a product of the machine architectures we have become familiar with. The fact that we will need to reopen this area of exploration is not unprecedented. That is not to say that good science only happens at massive concurrency – good science comes in all sizes. But if you need performance, massive parallelism is going to be the only game in town.

Patterson: This question sounds like there is a choice. If Bill Gates and his company don't have enough money to find alternatives to parallelizing their codes, then I'm pretty sure the HPC community doesn't have any alternatives either.

HPCwire: Can the HPC community mentor the larger IT market where parallelism is concerned?

Patterson: Absolutely. The HPC and embedded communities have the most experience at highly parallel systems, which is why we brought experts from those fields together to create the Berkeley View. We intend to continue to leverage that expertise in our plans to help show the larger IT market how to write programs that run efficiently on manycore systems.

-----

To learn more, go to http://view.eecs.berkeley.edu to see the wiki, blog, video of lectures, or YouTube-style video interview; or read the paper at: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-158.pdf. To learn more about RAMP, visit http://ramp.eecs.berkeley.edu.