teaching machines

CS 352 Lecture 32 – Von Neumann Architecture

November 28, 2016 by . Filed under cs352, fall 2016, lectures.

Dear students,

Today we discuss the pattern that generalizes most modern computers: the von Neumann architecture. But we start back before such a pattern converged.

In the 1940s, the ENIAC was built to calculate artillery tables for World War II. It was built out of many vacuum tubes (which served the same role as transistors). The ENIAC was billed as a general-purpose computer, but to make the hardware do different things, one had to manually connect wires to the appropriate connections on the hardware. “Programming” the ENIAC was really just circuit-building. This was a slow process, and for this reason and others, the ENIAC wasn’t finished until after the war was over. General-purpose computing would need to become easier if it was going to take off.

One of the consultants on the ENIAC was John von Neumann, and in 1945 and 1946, he laid out the ground for the ENIAC’s successors. His descriptions still accurately describe today’s computers:

First: Because the device is primarily a computer, it will have to perform the elementary operations of arithmetic most frequently. These are addition, subtraction, multiplication and division. At any rate a central arithmetical part of the device will probably have to exist and this constitutes the first specific part: CA.

Second: The logical control of the device, that is, the proper sequencing of its operations, can be most efficiently carried out by a central control organ.

If the device is to be elastic, that is, as nearly as possible all purpose, then a distinction must be made between the specific instructions given for and defining a particular problem, and the general control organs which see to it that these instructions—no matter what they are—are carried out. By the central control we mean this latter function only, and the organs which perform it form the second specific part: CC.

Third: Any device which is to carry out long and complicated sequences of operations (specifically of calculations) must have a considerable memory. The instructions which govern a complicated problem may constitute considerable material, particularly so, if the code is circumstantial (which it is in most arrangements). This material must be remembered. At any rate, the total memory constitutes the third specific part of the device: M.

The three specific parts CA, CC (together C), and M correspond to the associative neurons in the human nervous system. It remains to discuss the input and output organs of the device.

The device must be endowed with the ability to maintain input and output (sensory and motor) contact with some specific medium of this type. The medium will be called the outside recording medium of the device: R.

Fourth: The device must have organs to transfer: information from R into its specific parts C and M. These organs form its input, the fourth specific part: I. It will be seen that it is best to make all transfers from R (by I) into M and never directly from C.

Fifth: The device must have organs to transfer from its specific parts C and M into R. These organs form its output, the fifth specific part: O. It will be seen that it is again best to make all transfers from M (by O) into R, and never directly from C.

This pattern of what a computer looks like is generally called the von Neumann architecture. Probably the most significant contribution of this architecture is the idea that the functionality of the computer is not hardwired. It is derived from instructions stored in memory. This is referred to as the stored program concept, and it is in stark contrast to the hardware’s functionality being derived from its physical circuitry.

One can think of a program, then, as a virtual description of an early computer. When you program, you are actually building a computer. You store your description inside of another computer. When you run your program, the physical computer pretends to be your virtual computer. Things get messier when you throw a virtual machine into the picture!

With this simple model of a computer fleshed out, let’s start measuring its performance. When building machines, how can one tell if the design is good or not? “Good” is not actually a meaningful term here. To get into the realm of facts, we are better off comparing two designs. But to compare designs, we need some means of measuring hardware.

Coming up with numbers to help compare technology is a big business. Vendors will pick and choose which metrics are appropriate for their target market, but today we will discuss just these three:

Let’s get a feel for these metrics by solving a few problems:

  1. LUBE++ schedules oil changes at 8:00, 8:15, 8:30, 8:45, 9:00, 9:15, and so on, closing at 6 PM. What is their latency in minutes and throughput in vehicles per day?
  2. Dee Bugger fixes on average 4 bugs each each 8-hour workday. What is her latency in hours? What roughly is her throughput per year? If the software was 2713 bugs, how long will it take for her to make the software perfect?
  3. A memory system organizes data in 32-bit words and takes 10 ns to perform a read or write transaction. What is the latency of the memory system? The throughput in transactions per second? The bandwidth?
  4. A webserver needs to deliver a 750 KB webpage describing the state of the planet to up to 10 world leaders every second. What is the maximum bandwidth, throughput, and latency that the server must support?

See you next class!

Sincerely,