By Janie Chang
November 15, 2011 3:00 PM PT
Academic outreach is serious business at Microsoft Research. Its labs and individuals support academia with activities such as joint research, teaching and mentoring, internships, running conferences, and funding. Now, add to that list designing a cost-effective computing platform for teaching computer architecture.
Chuck Thacker, a Microsoft technical fellow based at Microsoft Research Silicon Valley and winner of the 2009 A.M. Turing Award, has been concerned about the decline of innovation in computer-architecture research for a long time.
“A key issue in recent decades has been the costly nature of this work,” Thacker explains. “It’s too expensive for researchers to build real chips to test new ideas, and software simulation is too slow to allow full-system experiments running real software.”
To address this issue, Thacker had been working with a consortium of universities to build a simple, affordable computing platform. Based on field-programmable gate arrays (FPGAs), semiconductors with programmable logic components, the resulting platform, called BEE3, enables researchers to emulate architectures and build multicore computers that run faster than software simulations.
Toward the end of the BEE3 collaboration, Thacker began working with colleagues Andrew Birrell and Tom Rodeheffer, principal researchers at Microsoft Research Silicon Valley, on Beehive, an even simpler design that uses a single, lower-cost FPGA. Then they realized the impact this work could have on the academic world.
“There was some hindsight,” Birrell admits. “We were designing this system, and I talked about it at MIT, Cornell, and some other places. Their feedback made us realize Beehive would make an excellent and much-needed teaching tool, so we adjusted our thinking a little to design a cost-effective platform aimed at enabling academic research and teaching for computer architecture and low-level systems programming.”
Source code for the Beehive hardware and software tool chain is available to universities for free through an open-source license. This gives users access to the raw hardware design—described in the Verilog hardware-description language—as well as a collection of low-level software libraries and a tool chain with a C compiler. Beehive provides a platform easily modified for “what if?” experiments and is available to the academic community for research purposes without external intellectual-property issues.
“Cores available for research use tend to be opaque ‘black boxes,’ or expensive, or large and complex,” Thacker says. “We wanted a core that was simple enough to be easily understood and modified, yet powerful enough to run large programs written in C or C#. We also wanted a system that could be built using only some basic tools.”
Adds Birrell: “Our hope is that Beehive enables systems research of the sort that starts from the bare metal, without operating systems getting in the way, and to explore questions at the boundary of systems software and computer architecture. This platform will facilitate experiments in design without the limitations of simulators and with much greater credibility than simulation results.
“I gave a talk about Beehive at the Massachusetts Institute of Technology [MIT] in the fall of 2009, and they thought it would be interesting to experiment with an Independent Activities Period (IAP) course using Beehive as a teaching tool for a multicore-systems lab.”
It didn’t take long before Beehive was pressed into action. MIT Department of Electrical Engineering and Computer Science professors Frans Kaashoek, Chris Terman, Robert Morris, and Nickolai Zeldovich collaborated on a syllabus. With help from Ph.D. student Silas Boyd-Wickizer, a 2010 Microsoft Research Ph.D. Fellow, the multicore-systems lab course was ready in time for the January 2010 semester break.
“There was a bit of a gap in the curriculum for students in that there’s very little parallel-computing instruction that combines both the hardware and software perspectives,” Kaashoek says. “We do have lab-based courses, but Beehive really made it easy for students to explore and code parallel hardware and software.”
Birrell spent time at MIT to help with the course, and the manufacturer of the FPGA hardware contributed 20 of the boards. The course, which was open to both graduates and undergraduates, attracted an enthusiastic group of students. By all accounts, it was a spectacular success.
It also was more fun than regular semester classes. At the end of the IAP course, student teams competed to devise the fastest solution to a classic computer-science problem called the traveling-salesman problem. Birrell attended that final day.
“We gathered in a meeting room and discussed each team’s solutions,” Birrell says. “In fact, as one set of students was presenting its neat trick for solving the problem, another set would be improving its program to make it work faster. Two of the professors formed a team and joined in the competition. I think they just wanted to play with the boards. It was all very fun and friendly.”
The IAP multicore-systems course proved so effective that Kaashoek was able to recruit Terman, Morris, and Boyd-Wickizer again to organize a full-semester undergraduate course based on the lab. As a bonus, Anant Agarwal joined the teaching team, and Thacker, Birrell, and Rodeheffer were invited as guest lecturers for this course, which was offered for the fall 2010 semester.
“MIT students are astonishingly bright,” Thacker recalls with a chuckle. “In fact, I’m a little embarrassed that one of the undergrads figured out how to simplify the basic communications mechanism of the Beehive much better than I had.”
Birrell, however, wonders whether the students who registered for the course appreciated how unusual it was to have four high-powered MIT academics teaching them.
“At the time, Frans Kaashoek and Chris Terman were associate directors of MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL). Anant Agarwal is now the director of CSAIL, and Robert Morris is a highly respected systems person. So this was the most powerful teaching staff you are ever likely to find in an undergrad course. It was seriously overstaffed.”
Kaashoek laughs at this comment.
“Normally, we take some time to develop a full course,” he says. “In this case, we didn’t ask for time but instead asked for additional staff, and those of us who participated did so because we felt it was important work. We were teaching and developing the course at the same time. Now that the initial development is done, the course won’t get that many instructors again. In addition, Chris, Robert, and I taught another class that semester.”
Student feedback for the undergraduate course was overwhelmingly positive, and Kaashoek hopes to offer this course in the future.
Despite the convivial banter between researchers, the fact that an array of eminent scientists invested considerable effort in bringing such a course to the curriculum underscores the importance of supporting research into multicore processors. The hardware industry is moving to multicore as the dominant computing-processing paradigm.
“All computing hardware and software will be parallel in the future,” Kaashoek says. “Our students need to understand parallel processing, and it begins with knowing how parallel hardware and software work in conjunction.”
While it is clear that researchers in systems design must have a reasonable grasp of how a computer works, down to the hardware level, Birrell says that even highly algorithmic work, such as search or natural language processing, benefits from this level of knowledge.
“If you want to understand the tradeoffs between memory or CPU usage,” he says, “or how to manage I/O, you need to understand how those parts of the computer work together. In my personal opinion, the people who design the best algorithms are the ones who know how to take advantage of the way all the parts of the computer work together.”
Thacker’s belief is that, in general, computer-science students are not thoroughly educated about what goes on at the lowest levels of the machines they use.
“We want to try to improve that,” he concludes. “By making a cost-effective system like Beehive available to universities, we allow students to learn a lot more about things they wouldn’t otherwise learn—like how to write concurrent programs. They have the concurrency mechanisms right there, and they can understand them and play with them. It makes life easier for the instructor, too, to have a working example that’s simple enough to be understood and yet complete enough that it displays the underlying architectural principles. I haven’t seen many tools like that out there for academia.”