Syntax and Semantics

Description

• exposé

Syntax and Semantics by Edward Nelson Department of Mathematics Princeton University The year is 2002 and here we are at a symposium on Foundations and the Ontological Quest. The first thing to say is how bleak the present situation is. In foundational studies of mathematics and physics we have been stuck for seventy years; despite numerous books, articles, and meetings, there has been no real progress. Seventy years ago Godel established his incompleteness theorem [1], destroying the foundational program of David Hilbert [2].

• classical mathematics
• mathematics for 57 years
• j. tonson
• original semantics of motion into an infinitesimal region
• infinitesimal
• foundational role
• e. s. craighill
• seventy years
• mathematics
• 3 mathematics
• semantics

Sujets

• Exposé
• Department
• Eckhart
• Robinson
• Schrödinger
• 2466 Golson
• Werner Heisenberg
• Carroll
• Hawaii
• University of Chicago Press
• Island

Informations

• Publié par: edwui
• Nombre de lectures: 41
• Langue: English

Extrait

-
USENIX Summer Conference
Why Aren’tJune 11-15, 1990
Anaheim, California Operating Systems
John K. Ousterhout University of California at Berkeley Getting Faster As
Fast as Hardware?
ABSTRACT
This paper evaluates several hardware platforms and operating systems using a set of benchmarks
that stress kernel entry/exit, file systems, and other things related to operating systems. The
overall conclusion is that operating system performance is not improving at the same rate as the
base speed of the underlying hardware. The most obvious ways to remedy this situation are to
improve memory bandwidth and reduce operating systems’ tendency to wait for disk operations to
complete.
1. Introduction
1.2
In the summer and fall of 1989 I assembled a collec-
tion of operating system benchmarks. My original intent
was to compare the performance of Sprite, a UNIX- 1.0R
ecompatible research operating system developed at the
l
University of California at Berkeley [4,5], with vendor- a
tsupported versions of UNIX running on similar hardware. 0.8i
vAfter running the benchmarks on several configurations I
e
noticed that the ‘‘fast’’ machines didn’t seem to be run-
P 0.6ning the benchmarks as quickly as I would have guessed e
rfrom what I knew of the machines’ processor speeds. In
f
order to test whether this was a fluke or a general trend, I o
r 0.4ran the benchmarks on a large number of hardware and m
asoftware configurations at DEC’s Western Research
n
Laboratory, U.C. Berkeley, and Carnegie-Mellon Univer- c
e 0.2sity. This paper presents the results from the benchmarks.
Figure 1 summarizes the final results, which are con-
sistent with my early observations: as raw CPU power 0.0
increases, the speed of operating system functions (kernel 0 2 4 6 8 10 12 14 16 18 20
calls, I/O operations, data moving) does not seem to be MIPS
Figure 1. Summary of the results: operating system speedkeeping pace. I found this to be true across a range of
is not scaling at the same rate as basic hardware speed.hardware platforms and operating systems. Only one
Each point is the geometric mean of all the MIPS-relative
‘‘fast’’ machine, the VAX 8800, was able to execute a performance numbers for all benchmarks on all operating
variety of benchmarks at speeds nearly commensurate systems on a particular machine. A value of 1.0 means that
with its CPU power, but the 8800 is not a particularly fast the operating system speed was commensurate with the
machine’s basic integer speed. The faster machines all havemachine by today’s standards and even it did not provide
values much less than 1.0, which means that operating sys-consistently good performance. Other machines ran from
tem functions ran more slowly than the machines’ basic
10% to 10x more slowly (depending on the benchmark) speeds would indicate.
than CPU power would suggest.
The benchmarks that I ran are mostly ‘‘micro-
The benchmarks suggest at least two possible factors benchmarks’’: they measure specific features of the
for the disappointing operating system performance: hardware or operating system (such as memory-to-
memory bandwidth and disk I/O. RISC architectures memory copy speed or kernel entry-exit). Micro-
have allowed CPU speed to scale much faster than benchmarks make it easy to identify particular strengths
memory bandwidth, with the result that memory-intensive and weaknesses of systems, but they do not usually pro-
benchmarks do not receive the full benefit of faster CPUs. vide a good overall indication of system performance. I
The second problem is in file systems. UNIX file systems also ran one ‘‘macro-benchmark’’ which exercises a
require disk writes before several key operations can variety of operating system features; this benchmark
complete. As a result, the performance of those opera- gives a better idea of overall system speed but does not
tions, and the performance of the file systems in general, provide much information about why some platforms are
are closely tied to disk speed and do not improve much better than others. I make no guarantees that the collec-
with faster CPUs. tion of benchmarks discussed here is complete; it is
1




































































possible that a different set of benchmarks might yield 3. Operating Systems
different results.
I used six operating systems for the benchmarks:
The rest of the paper is organized as follows. Sec- Ultrix, SunOS, RISC/os, HP-UX, Mach, and Sprite.
tion 2 gives a brief description of the hardware platforms Ultrix and SunOS are the DEC and Sun derivatives of
and Section 3 introduces the operating systems that ran on Berkeley’s 4.3 BSD UNIX, and are similar in many
those platforms. Sections 4-11 describe the eight bench- respects. RISC/os is MIPS Computer Systems’ operating
marks and the results of running them on various system for the M2000 machine. It appears to be a deriva-
hardware-OS combinations. Section 12 concludes with tive of System V with some BSD features added. HP-UX
some possible considerations for hardware and software is Hewlett-Packard’s UNIX product and contains a com-
designers. bination of System V and BSD features. Mach is a new
UNIX-like operating system developed at Carnegie Mel-
2. Hardware lon University [1]. It is compatible with UNIX, and much
of the kernel (the file system in particular) is derived fromTable 1 lists the ten hardware configurations used
BSD UNIX. However, many parts of the kernel, includ-for the benchmarks. It also includes an abbreviation for
ing the virtual memory system and interprocess communi-each configuration, which is used in the rest of the paper,
cation, have been re-written from scratch.an indication of whether the machine is based on a RISC
processor or a CISC processor, and an approximate MIPS Sprite is an experimental operating system
rating. The MIPS ratings are my own estimates; they are developed at U.C. Berkeley [4,5]; although it provides the
intended to give a rough idea of the integer performance same user interface as BSD UNIX, the kernel implemen-
provided by each platform. The main use of the MIPS tation is completely different. In particular, Sprite’s file
ratings is to establish an expectation level for bench- system is radically different from that of Ultrix and
marks. For example, if operating system performance SunOS, both in the ways it handles the network and in the
scales with base system performance, then a DS3100 ways it handles disks. Some of the differences are visible
should run the various benchmarks about 1.5 times as fast in the benchmark results.
as a Sun4 and about seven times as fast as a Sun3. The version of SunOS used for Sun4 measurements
was 4.0.3, whereas version 3.5 was used for Sun3 meas-Hardware Abbrev. Type MIPS
urements. SunOS 4.0.3 incorporates a major restructuring
MIPS M2000 M2000 RISC 20
of the virtual memory system and file system; for exam-
DECstation 5000 DS5000 18
ple, it maps files into the virtual address space rather than
H-P 9000-835CHX HP835 RISC 14
keeping them in a separate buffer cache. This difference 3100 DS3100 12
is reflected in some of the benchmark results.
SPARCstation-1 SS1 RISC 10
Sun-4/280 Sun4 8
4. Kernel Entry-Exit
VAX 8800 8800 CISC 6
IBM RT-APC RT-APC RISC 2.5 The first benchmark measures the cost of entering
Sun-3/75 Sun3 CISC 1.8 and leaving the operating system kernel. It does this by
Microvax II MVAX2 0.9 repeatedly invoking the getpid kernel call and taking the
average time per invocation. Getpid does nothing but
Table 1. Hardware platforms on which the benchmarks
return the caller’s process identifier. Table 2 shows thewere run. ‘‘MIPS’’ is an estimate of integer CPU perfor-
average time for this call on different platforms andmance, where a VAX-11/780 is approximately 1.0.
operating systems.
All of the machines were generously endowed with
The third column in the table is labeled ‘‘MIPS-memory. No significant paging occurred in any of the
Relative Speed’’. This column indicates how well thebenchmarks. In the file-related benchmarks, the relevant
machine performed on the benchmark, relative to itsfiles all fit in the main-memory buffer caches maintained
MIPS rating in Table 1 and to the MVAX2 time in Tableby the operating systems. The machines varied somewhat
2. Each entry in the third column was computed by tak-in their disk configurations, so small differences in I/O-
ing the ratio of the MVAX2 time to the particularintensive benchmarks should not be considered
machine’s time, and dividing that by the ratio of thesignificant. However, all measurements for a particular MIPS rating to the MVAX2’s MIPS rating.machine used the same disk systems, except that the
For example, the DS5000 time for getpid was 11Mach DS3100 measurements used different (slightly fas-
microseconds, and its MIPS rating is approximately 18.ter) disks than the Sprite and Ultrix DS3100 measure-
Thus its MIPS-relative speed is (207/11)/(18/0.9) = 0.94.ments.
A speed of 1.0 means that the given
The set of machines in Table 1 reflects the resources
machine ran the benchma