E. Douglas Jensen

Performance effects of architectural complexity in the Intel 432

The Intel 432 is noteworthy as an architecture incorporating a large amount of functionality that most other systems perform by software. It has, in effect, “migrated” this functionality from the software into the microcode and hardware. The benefits of functional migration have recently been a subject of intense controversy, with critics claiming that a complex architecture is inherently less efficient than a simple architecture with good software support. This paper examines the performance impact of the incorporation of several kinds of functionality into the Intel 432. Among these are the addressing structure, the caches, instruction alignment, the buses, and the way that garbage collection is handled. A set of several benchmarks is used to quantify the performance effect of each of these decisions. The results indicate that the 432 could have been speeded up very significantly if a small number of implementation decisions had been made differently, and if incrementally better technology had been used in its construction. Even with these modifications, however, the 432 would still have only one-fourth to one times the speed of its contemporaries. These figures may represent the real cost of the 432s style of object-based programming environment.

Distributed co-operating processes and transactions

As part of our research in the Archons [Jensen 82] project on decentralized computers, we have developed a relational model of data consistency to replace the conventional serialization model for reasoning about the relationships among distributed system data objects in general and state variables in particular. We not only permit but encourage such relationships to be probabilistic, in the interest of efficiency. This model leads to a new formulation of co-operating processes, and thence to the notion of co-operating transactions: co-operating processes whose actions are made atomic for the sake of reliability. We believe that co-operating processes are valuable in a computer network, but essential in a decentralized computer [Jensen 82] where the conceptually singular but physically dispersed global operating system requires a transaction facility in the kernel [Jensen 80]. These ideas are illustrated by examples from our initial experience in applying the model to the Accent network operating system and other system software of the Spice personal computing network. This document is intended to be an overview of the synchronization effort in the Archons project, and future publications will elaborate on many of the individual points touched on here.

Peering through the RISC/CISC fog: an outline of research

We are defining a computer architecture to support a decentralized operating system that is under development. Since complex functions of this system could appear directly in the architectures instruction set, we are immersed in the current RISC/CISC debate where we have found many questions and few answers. Hoping to shed light on aspects of this conflict, we have embarked on two studies. The first seeks to find an environment where complex instructions can enhance system performance. The second tries to decouple multiple register set performance from instruction set performance in general-purpose register machines.

Chapter 8. Distributed control

Executive control concepts and mechanisms have evolved primarily in a highly centralized uniprocessor context, surrounded by the rather centralized (e.g., hierarchical) structures of nature and human society. At least partially as a consequence of this, there is currently some difficulty envisioning more “decentralized” control concepts and designing corresponding mechanisms. To help stimulate thought in this area, we present a conceptual model of the spectrum of control alternatives from maximally centralized to maximally decentralized. The model is not intended either to provide a quantitative measure of decentralization, or to ascribe attributes (e.g., “better”) to points in the spectrum—instead, its illumination should greatly facilitate the subsequent performance of these endeavors.

Physically dispersing an operating system

Computer systems can be &distributed& in many different senses - for example: the user access (such as remote terminals); the system geography (such as a computer network); the processing (such as a multiprocessor or a multicomputer); the data (such as a partitioned or a replicated database); the operating system (such as a network OS or a decentralized OS). These senses of distribution are not independent, and each has its own advantages and disadvantages in various circumstances, as well as its own research problems. However, some senses are becoming better understood than others, and some are becoming recognized as more fundamentally important than others. Distributing the user access or the system geography per se can be regarded as neither especially challenging nor critically fundamental technology. Distributing the (user portion of the) processing is important, and the ease of doing so is, to a first order approximation, determined by the extent and manner in which the data and operating system are distributed. It currently seems to be these latter two aspects of computing whose distribution involves the most essential, and difficult, new technology.

Chapter 17: Hardware/software relationships in distributed computer systems

The desireability of increased synergism between the hardware and software of computer systems has become a cliche, but unfortunately without being significantly reflected in practice. One of the principle aspects of our research in distributed computer systems has been to actually apply these arguments in the implementations and explore their ramifications. The examples herein were largely derived from that experience.