First, some background on myself: I have been a computer architect at Intel for just under seven years. I was initially responsible for architecture and micro-architecture on the Pentium and most recently responsible for the definition of the Intel/HP architecture. Intel is in the process of creating an organization to perform research in processors, systems, and software and I presently have responsibility for staffing the processor architecture and micro-architecture group within that organization. Prior to Intel I was at Cydrome where I was a designer of their VLIW machine.
In the following I address what I consider to be the current status and future challenges of computer architecture. Given my background, I will tend to exhibit (no less than) three biases:
- An industry view vs. an academic view
- An application (non-privileged) architecture view vs. a system (privileged) architecture view
- A processor architecture (CPU) view vs. a system architecture (whole box) view.
In an attempt to alleviate semantic confusion I think it appropriate to lead off with my definition of computer architecture and my view of how it fits in the Big Picture: Computer architecture is the definition of machine state, the instructions that operate on this state, and the low level compiler and operating system algorithms employing same. An architecture is a set of rules/algorithms/heuristics that are physically manifested in the form of an implementation (hopefully many of them). Architecture is a means to an end, not an end in and of itself. The end is to provide useful functionality to the user at highest performance and lowest cost (hopefully said user will be interested in paying for said functionality).
With that out of the way, what follows are sections on Current Status and Future Challenges...
Current status:
===============
What's done well:
- Academia supplies reasonably well tuned minds to industry (and to itself).
- Creative ideas are being generated.
- Reasonably well oiled mechanism for rotation of students and professors through industry via internships and sabbaticals.
- Conferences are a good forum for interaction and distribution of results.
What needs improvement:
- Better mechanisms for distributing results. Journals (e.g. IEEE TOC) take far too long to publish results. Conferences have low publishing latency but they only occur once per year and their papers are too short to expound upon the details. What's needed is a regular publication (>1 per year) with long papers (10's of pages) and low review latency (<1 year). I think ACM TOCS comes closest to this today. I suspect email can be profitably employed to achieve this goal.
- Take a holistic view. The compiler, the micro-architecture, and the operating system are variables - not constants. Architectural study must take variations along these axes into account as much as possible. Due to resource constraints, I don't expect every study to vary all of these variables. And in some cases one or more of these variables may really be constant, e.g. due to market forces. However, in looking at what's been published in the last several years I believe more can be done to explore the architectural solution space. Along a similar line of thought, no program runs in a vacuum. Architectural study needs to take into account the effects of other concurrent activities in the system, e.g. the operating system, the GUI, other concurrently running apps, I/O.
- Don't loose sight of the actual use of computation. However aesthetically unappealing it may be (and it certainly is unappealing), the reality is that the three largest consumers of computation today are word processors, spreadsheets, and GUI's (one particular GUI to be exact). The overwhelming majority of computer users don't spend their time computing the thermal profile of nuclear reactors, compiling code, or running CAD tools. Although, as I point out below, the lack of source code puts an upper limits on what can be done, results generated on current workloads will be immediately applicable. As my next bullet points out, I'm not suggesting that *only* current workloads should be used, but in order to maintain some degree of realism these should be taken into consideration.
Future challenges:
==================
- Anticipate the future uses of computation. Thankfully, the use of computation is not static (this is to make you feel better after that last bullet). Serious quantitative work is needed in emerging areas of which I believe the most important/imminent to be: OOP; multi-threading; audio, video, graphics; and software components (aka applets). I'm sure I've left off a few emerging trends in operating systems. The physical aspects of future computers will have an impact on the use of computation as well, e.g. carrying computers around in your handbag, computers embedded in the walls of your house.
- Impediments to architectural innovation. As noted above, there are multiple variables to architectural work. In my experience in developing two complete architectures from scratch, one of the most significant limiters to innovation is the latency of compiler development. Minor tweaks to existing architectures may have localized compiler impact but fundamental architectural innovation requires rapid implementation of, and changes to, optimization algorithms. Work needs to be done on the architecture of compilers and on rapid software prototyping to bring down the latency of compiler changes. A research compiler doesn't need to be fast or small, it needs to produce code of highest quality employing the latest whiz-bang architectural concept. Another significant limiter is the availability of source code. More likely than not, the most commonly used software will be proprietary and therefore the source won't be available. Lack of source freezes an important architectural variable and limits one's ability to gather data. The solution here is unclear (short of expanding the Free Software Foundation).
- Continuously improve the relationship between industry and academia. I believe industry should take a more active role in providing direction to academia regarding relevant problems (naturally more financial and equipment support wouldn't hurt either). Industry types also need to become more involved in reviewing papers, organizing conferences, and editing publications. In a perfect world industry types would publish their results more frequently but I'm not holding my breath on this one.