It was a different computing world in the late 1980s. Many if not most researchers in the computer architecture area had become convinced that complex instruction sets such as the Intel x86 were doomed in light of the many advantages promised by reduced instruction set architecture publications. There were many voices within Intel urging upper management to abandon x86 and get started on some alternative. Even engineers who had worked on Intel's then-flagship 486 were expressing serious reservations about whether the x86 architecture could be “dragged further up the hill” to be, if not directly competitive with emerging RISC designs, at least close enough for x86 to remain profitable.

Intel’s Pentium microprocessors have been a feature of computers for over 25 years. Robert P. Colwell, lead designer of the microarchitecture used in the Pentium Pro and beyond, recounts how it all began.

Presents a collection of slides covering the following topics: Moore's Law; computer design; neighboring technologies; and chip designers algorithm.

The computer architecture community of the late 1970s and early 1980s thought that a few things had been established and no longer needed questioning. One of these was the amount of intrinsic parallelism embedded in normal object code. Making what they considered to be self-evident assumptions about correctness, Tjaden and Flynn established that there was, on average, only a factor of two parallel...

PUT TH IS ON your to-do list: read the following paper by researcher David Shaw and colleagues that describes their Anton molecular dynamics (MD) engine. Shaw’s Anton engine applies leadingedge computer science concepts to the biologically crucial problem of modeling molecular interactions. In an era when much of our most advanced computer technology is spent creating ever more horrible creatures that we can shoot ever bigger virtual holes in, the idea of productively using this technology to explore nature at its most up-close-and-personal is both exciting and reassuring. The nature of the computational problem Anton aims to solve, and the unique aspects of the resulting design, are fascinating peeks into a corner of the computer design space we seldom get to visit—even though each of us is a biological machine that relies on the correct functioning of molecular mechanisms. When diseases cause these mechanisms to go awry, medical researchers try to infer the causes and possible remedies from very indirect and error-prone evidence, as they lack direct means of measuring or simulating the molecular underpinnings. David Shaw calls his new instrument a “computational microscope,” and if successful it stands to make the same kind of game-changing impact that Anton van Leeuwenhoek’s original optical microscope once did. (Shaw’s machine was named in van Leeuwenhoek’s honor.) To appreciate what Shaw’s machine is attempting, consider a system containing a realistic protein molecule together with a few layers of water molecules, which might together encompass tens of thousands of atoms. If calculation of the force between any two atoms takes 10 computer operations, then the total ops required per time step would be (10 atoms) × (104 atoms) × 10 ops/atom = 109 ops. Time slices are on the order of femtoseconds (10 seconds), and simulations must run for milliseconds (10-3 seconds) to capture the biology being modeled. So we’ll need to run those 10 ops for 1012 slices to reach a simulated millisecond—that’s 31,000 years. We need six orders of magnitude speedup, roughly three orders of magnitude beyond today’s fastest supercomputers. But even if you weren’t a biological unit with a vested interest in this effort, you could still appreciate the Anton design from a computer system perspective. General-purpose computer systems aspire to run everything well, but no one thing spectacularly well. Anton is designed to run a specific molecular dynamics workload spectacularly well. While a well-designed general system can bottleneck 100 different ways on 100 different benchmarks, Anton must try, in essence, to bottleneck everywhere, all at once, on its one workload. This balancing act must be attempted in the face of imperfect knowledge of that one workload. For example, electrostatic interactions between two atoms that aren’t sharing any electrons are considered to be well understood, and are the most numerous, so Anton applies very specific, very parallel, and very inflexible hardware to handling them. Less is known about the infrequent bonded interactions, so those calculations are allocated to a much more flexible subsystem that will allow experimentation with various “force field” models and algorithms. What might go wrong with the Anton effort? Subtle errors arising from the class of force fields that Anton is designed to handle efficiently may accumulate over the extremely long MD runtimes; in a custom machine with no operational experience, soft errors could strike much more often and substantially slow its performance; quantum effects may turn out to be necessary, beyond the classical force field being modeled here; some clever graduate student may come up with a software-based approach that reduces Anton’s two-orders-of-magnitude performance advantage to only one (which might no longer be enough to justify its hardware expenditure). Or Anton might become a victim of its own success if early learnings point to much better (and much different) MD algorithms that no longer fit well into Anton’s overall structure. But what if things go right? Benoit Roux, an MD researcher now at the University of Chicago, said that as soon as Anton has delivered its first verified scientific result he will want an engine of his own, and so will everyone in the entire MD field. Roux points out that molecular biologists must normally have “elaborate strategies to prevent fooling themselves” in their macroscale experiments. With Anton, “we’ll be able to do insane things with unknown problems and two weeks later we’ll discover how the molecules actually move. ... Anton will revolutionize molecular biology.” It is not often that a science reaches a clear tipping point—when it advances very quickly, virtually exploding into a new shape and venue. Our own field of computing has done that several times. Many physicists expect this of the Large Hadron Collider currently being completed in Europe. Shaw and his coworkers are attempting nothing less in the field of molecular dynamics. As a computing professional, I am proud of their efforts, I salute their attempt to drive an extremely important basic science forward, and I heartily recommend their paper.

An excerpt from The Pentium Chronicles: The People, Passion, and Politics Behind the Landmark Chips offers a project manager's firsthand account of the technical and management challenges facing the team that conceived Intel's P6 microarchitecture.

Summary form only given. Intel's ×86 processors pushed pipelining and clock rates until physics stopped us. Less obviously, we were also pushing complexity, and therefore risk. We now know where the limits to these trends lie: with the Prescott processor. This talk explores the nature of risk in chip developments, how the ever-deepening pipelines in the Pentium series affected, and were affected by, perceived risk and thermals, and where the future will take us.

Foreword. Preface. 1. Introduction. 2. The Concept Phase. 3. The Refinement Phase. 4. The Realization Phase. 5. The Production Phase. 6. The People Factor. 7. Inquiring Minds Like Yours. Bibliography. Appendix. Glossary. Index.

Meeting emerging computer design industry challenges requires finding a balance between continuing to apply old technology beyond the point where it is workable and prematurely deploying new technology without knowing its limitations.

Brainstorming done right is an exhilarating, exhausting process. The personnel mix in a brainstorming group is crucial. Ideally, the group includes at least one and at most two "idea fountain" types, the kind of people whose brains automatically generate 10 ideas for every one being discussed. The group also should include at least one person who strongly wants useful results out of the session, such as the team leader or an architect looking for a solution to a particularly vexing problem. One team member should be someone who has the mental horsepower to keep pace with the intellectual sprinters but is willing to stay half a step behind them during the session to help spot strengths and weaknesses in the ideas they are volleying back and forth. This person subtly helps direct the group's energies toward the most promising ideas, after enough time has been spent generating them.

A microcomputer chip, often simply referred to as a microchip or just chip, is an integrated circuit component that is the building block of a computer system. Typically, microcomputer chips are very large-scale integrated circuit components (VLSI) containing millions to tens of millions of transistors. In 1999, the largest such components contained over one hundred million transistors. A computer will typically contain a large number and variety of such components or chips. A typical personal computer will contain about 40 chips of different varieties. Hand-held "personal digital assistants" have very few chips, to save battery power and to keep them small. The best known example of a microcomputer chip is the microprocessor, but "microcomputer chip" is a very broad term that refers to many different kinds of such components. Furthermore, the boundaries and distinctions between the particular forms are constantly changing.

E very year, many companies engage in employee performance reviews, a monthslong process that scares their employees, costs huge amounts of management time, and purposely sunders the teamwork required for product development. From this process come promotions, raises, management changes, and, ultimately, much of the corporate culture itself. Performance reviews also generate demotions, disciplinary actions, and dismissals. A substantial measure of overall job satisfaction derives from this official evaluation. Mix in all the normal human frailties about who likes whom better, misremembered communication mixups in meetings, incomplete or erroneous understandings about the evaluation process, and pretty soon the trepidation approaches mandatoryValium levels. Why do companies pursue this painful process every year? Because they believe in the idea of a technical meritocracy. Companies want to reward their top producers, and they need to identify those who may not be carrying their share of the load. Employees hope to distinguish themselves by their efforts, and they want those efforts to be noticed and rewarded. People who contribute more to the company’s efforts should be rewarded commensurately. Recognizing its best producers and rewarding them with promotions and bonuses encourages the kind of behavior the company wants to foster. Without performance reviews, deadwood tends to accumulate—people who are not enjoying their jobs, are not producing at a rate comparable to their peers, and probably are holding the entire team back from its goals. The question is, how can a company evaluate a population of engineers in such a way that they accept the process as fair and equitable, encouraging maximum overall output? Since it is the example I know best and because I think its system works well overall, I will use Intel as my case study for how one company answers this question. INTEL’S MERITOCRACY Intel divides its employees into grades. A recent college graduate with a BSEE might start out as a grade 3. As the years go by and the employee gains in knowledge, experience, and responsibility, she typically will be promoted through the various grades, perhaps up to principal engineer (grade 10) or Intel Fellow (grade 12). Promotions are determined at management meetings called “ranking and rating” sessions. The basic idea of an R&R is to divide up the technical ranks into groups of about 20 engineers and rank order the names according to their individual accomplishments over the past 12 months. The managers then use this rank order to drive discussions about pay raises, stock option allocations, promotions or demotions, and “messages”—the advice that will appear in the final written performance review each employee receives. At these R&R sessions, an immediate supervisor represents each employee who is being ranked and rated. A department manager or the general manager (the “rank manager”) leads the session. Typically, a human resources representative sits in to make sure the session follows Intel policy and to serve as an independent witness that all employees are treated fairly. After the R&R, the supervisors have a few weeks in which to write the formal reviews, which include the accomplishments, strengths, and areas for improvement, along with whatever advice the supervisor feels will best guide the employee toward higher productivity and more job satisfaction. The supervisor, the supervisor’s boss, and the employee sign these reviews. A separate letter details any salary, bonus, stock option, or pay grade changes.

Engineering is the act of making intelligent tradeoffs and compromises among conflicting and sometimes mutually exclusive goals. To improve product performance, the die size might need to increase, which diminishes the chip's economic attractiveness. Assessing risk and product quality is not an exact science. Nevertheless, the computing industry's future rests as much on our success in achieving product quality as it does in continuing to innovate in circuits and microarchitectures.

Because engineers generally cannot test their creations to the point of saturation, they must make do with a lot of substitutions: anticipation of all possible failure modes; a comprehensive set of requirements; dedicated validation and verification teams; designing with a built-in safety margin; formal verification where possible; and testing, testing, testing. If you did not test it, it does not work. In some cases, computers have become fast enough to permit testing every combination of bit patterns. Many, perhaps most, things you design cannot be tested to saturation. So it behooves us to try to anticipate how our designs will be used, certainly under nominal conditions, but also under non-nominal conditions, which usually place the system under higher stress. The paper considers how programmers have a range of techniques at their disposal