An Inside View: The $20 Million Intel/Microsoft Multicore Programming Initiative

Most TG Daily readers may already know about the news of Intel and Microsoft setting up two research centers called "The Universal Parallel Computing Research Center" (UPCRC) at the University of California at Berkeley and the University of Illinois at Urbana-Champaign (UIUC) with a grant of $10 million each. In addition, UIUC will match with its own grant of $8 million which will be utilized by 22 faculty members from the Department of Computer Science and Department of Electrical and Computer Engineering. Although the announcement came on March 18, the news and specifically Berkeley's name had been doing rounds on technology news websites much earlier. Berkeley and Illinois were selected from an initial set of 25 top universities across the nation including MIT and Stanford. The funding is particularly exciting for Illinois since it is a recognition of its continued excellence in the field of parallel computing since the days of Illiac IV back in the 1960s.

Misconceptions

I have observed opinions on quite a few websites as to how $10 million represents a drop in the ocean for Intel and Microsoft, while both companies have been posting billions of dollars in annual profits. In addition, given the fact that the problem of programming multicore chips poses such a significant risk to their core business, the amount appears to be tiny at first look. But we should keep in mind that Intel and Microsoft are not stupid. They have had frequent and significant collaboration with academia for a long time. They realize that $10 million is a large enough amount to generate excitement among academic researchers, especially in Computer Science community where they mainly have a need for computers and graduate students. They don't need to buy telescopes and nuclear reactors. You get the point.

As the news about this project cools down across blogs and technology websites, the researchers at UIUC are gearing up for some very exciting research. The array of faculty members at UCPRC at University of Illinois is quite impressive, both at the individual level and as a group. Their area of expertise represents the whole stack of computation as we know it today.

The project group

The research project covers subjects ranging from microarchitecture (Wen-mei Hwu, Sanjay Patel, Craig Zilles) to computer architecture (Marc Snir, Sarita Adve, Joseph Torrellas, Rakesh Kumar), from compilers (Vikra Adve, David Padua, Matthew Frank, Maria Garzaran) to programming languages/programming models (Gul Agha, Laxmikant Kale) and from software design (Ralph Johnson), testing and verification of concurrent software (Grigore Rosu, Darko Marinov, YuanYuan Zhou) to end-user applications (Klara Nahrstedt). In addition, the project includes researchers in AI (Eyal Amir, David Forsyth, Dan Roth) and graphics (John Hart), which is a very important area in terms of parallel algorithms.

There is a realization at UIUC that a new class of next-generation applications will drive the demand for the parallel processing capability available through a processor. Based on the current vision, these applications have been broadly categorized into human-centric and environment-aware applications. One area that Illinois' center lacks strength is that of operating systems and virtualization. I believe that efficient and reliable run-times that deal with inter-core communication, scheduling, resource management, security and debugging on multi-core is important to the layers above it. In fact, multi-core processors provide an opportunity to fix mistakes of the past by leveraging extra processing to enhance the security of the platform.

The gap between the community and researchers

Amidst all the excitement, there are some reservations that need to be analyzed and addressed carefully. Traditionally, academic researchers are interested in securing tenure, getting citations and making an impact in the research community. This translates into the sole goal of publishing research papers and more research papers. Also, academic research in this area is focused on the insights and the theory behind some phenomenon.

As a result, such research or a prototype may not be scalable into real-world applications or it may not be user-friendly enough to make sense for the developer community. On the other hand, the problem of multi-core programming is staring at us right now. I am not sure what Intel's and Microsoft's expectations are, but it is quite possible that they are in fact looking at fundamental results from the academic centers to leverage their large work force to polish and realize the ideas that come forth. It calls for a much closer collaboration between the centers and the companies than it appears at first sight.

Another development that I will be watching with much interest is the evolution of a model of collaboration among the members within a center. It is simply not possible for all the faculty members to work on the same project at the same time. The current model seems to be that small groups (up to three or four members) are currently collaborating on a project that matches their current interests, beliefs and philosophy.

Actor model

One such group that, among others, which includes my adviser Professor Gul Agha, believes in building practical tools to facilitate the mainstream adoption of "Actor model of programming". An introduction of Actor model is overdue at this point: It describes a programming model that is built around concurrently-executing objects called "Actors" that communicate by asynchronous message-passing. A few things to note here are that it is an inherently concurrent model of programming. Actors do not have a shared state and exchange information by passing messages only. You can think of Actors as objects in object-oriented programming (each having their own data and behavior) augmented with a thread of control and a mail queue. Another view of actors is that of services in service-oriented architecture (SOA), which provide a service on receipt of a message from other service, each running independently and asynchronously. The Actor model was proposed originally by Carl Hewitt, and then further developed by Professor Agha. His book is one of the most cited articles in Computer Science and an excellent description of the model.

Erlang is arguably the best known implementation of Actor model. It has been used to write production systems at Ericsson for about 20 years. There have been other implementation but the growing awareness of concurrent and parallel programming has seen a surge in the interest in Actor model, as we have noticed new Actor languages and libraries coming from both the academia and the developer community. This includes Scala (a language coming from academia and receiving lots of attention from developers), Salsa (another language from academia), Ptolemy (an Actor framework from UC Berkeley) in addition to Actor libraries in Java, Python and Ruby. Additionally, the syntax of these languages comes in different flavors. For example, Erlang is based on functional programming. Scala has a Java-like syntax.

Keeping this scenario in perspective, this group is focused on the design and implementation of a virtual machine and run-time to support actor languages. This would serve as a vehicle in the research of the design of actor languages, enabling language designers to focus on the correct programming abstractions and elegant syntax. In short, it hides the complexity and heterogeneity of the underlying hardware from the language designer.

An interesting research direction in this regard is that of exploring meta-architectures and reflection to manage scheduling and resource management at run-time. This focus also highlights research problems in the communication among actors, providing debugging support for actor programs and enabling secure computation. Efficiency and optimization is interwoven with the concerns I have mentioned earlier.

As a side-effect, it would allow developers to write Actor programs in the syntax they are comfortable with - but they would be able to send and consume messages to and from other actors written in a possibly different language. This would be similar to the role XML plays in SOAP messaging. Having a run-time underlying the VM enables you to leverage the locality and shared memory in multicore processors for efficiency, while resorting to distributed messaging in cluster environments, for example. I must admit that these are high-level ideas and expectations, and as we dig deeper we might find dead-ends as well as exciting new questions.

Similarly, I believe other researchers have started to explore avenues of collaboration with each other under this umbrella. I can feel the spring in their step, excitement in their emails, and energy in their research activities. And why not? This represents a lifetime opportunity to not only make a significant academic impact, but especially an impact on the industry and the developer community.

About the author: Rajesh Karmani is a graduate student in the Department of Computer Science at University of Illinois at Urbana-Champaign. He is a recipient of the Sohaib and Sarah Abbasi Fellowship. His current area of interest is programming languages and software engineering. Previously, he has worked in wireless sensor networks and multi-agent systems.

Disclaimer: The views expressed in the article are author's personal view and do not represent those of TG Daily, the University of Illinois, or the UPCRC at University of Illinois.