Don't move.
Welcome to the Distinguished Lecture Series.
I'm Karen Matthews, of University Video
Communications.
Our program is designed to enrich
graduate and upper-division curriculum
with academic presentations by top computer scientists
from industry.
Speakers and topics were nominated
by computer science faculty of more than 50 universities.
This presentation is sponsored by Education and Research
Programs of Sun Microsystems.
Bill Joy, a leader in computer architecture,
received his Master's degree in Computer Science and Electrical
Engineering from the University of California
at Berkeley, where he was the principal designer of Berkeley
UNIX.
A founder of Sun Microsystems, in 1982,
he designed Sun's network file system
and worked on their scalable risk processor.
Currently Vice President of Research and Development
at Sun Microsystems, Bill Joy's talk today
is The Future of Computing--
The Open Systems Imperative.
It's our pleasure to introduce Bill Joy.
Bill?
Hello.
I'd like to talk to you today about the future of computing.
In particular, I'd like to start with a definition
of the problem that we see and also the enormous opportunity
for the future uses of computers.
The big problem in the marketplace today
is that people are beginning to apply computers
to very large tasks, tasks that involve
many different computing systems, which must work
together, and which involves very large pieces of software,
which have to run in a distributed environment.
This is a severe problem in constructing
these kinds of systems.
And to boot, we have the problem of very rapid change
in the component technologies.
Rapid innovation is occurring in many places.
Microprocessors are getting faster, networks are changing,
and no single organization controls all the pieces.
So it's very difficult to build and integrate these systems,
both from a hardware and a software standpoint.
What we'd like to describe today is an approach
we've taken at Sun Microsystems and one that's
becoming dominant in the industry, what we'd
call the open systems approach.
This approach involves using industry standards
whenever possible to allow these kinds of large systems
to be built. Rather than developing our own technology,
if possible, we license technology from others.
And when we develop new technology,
we describe the interfaces so that other people can also
implement them.
It's a kind of environment where we work with other vendors
and create a competitive environment
and one which we hope will provide better values
to our customers.
This kind of business approach is very highly leveraged.
To give you examples of a couple of industries where
this kind of approach has emerged,
the first would be the PC-DOS industry.
Basically, the set of IBM and IBM compatibles.
What happened in this marketplace
was IBM set some standards.
Microsoft, which developed the software, licensed it freely,
and a number of different companies
then came into existence, which provided piece parts to people
who wished to build systems.
There's a lot of leverage in this industry.
Some of the pieces are proprietary,
but in general, the whole business environment
is very open.
There's room for people to add value.
And this allows very valuable systems
to be built at relatively low engineering cost.
Another example is the workstation industry,
where we see 32-bit microprocessors
being the technology driver.
It was the emergence of these microprocessors that
made workstations possible, that allowed
us to move the power of the mini computers to the desktop.
The decline in the cost of RAM allowed
us to put large memory on the desktop,
and the emergence of UNIX as a software standard
allowed applications to be portable.
The inexpensive ethernet standard,
the 10-megabit local area network
connected all these systems together.
And so we have as another example
of an industry where all the piece parts are freely
available and a very high growth market where, in fact,
UNIX and open systems are a market requirement.
So if we look at the kind of computers
people have today and the kind of computers
we expect to see available in people's work environments
in the next five years, we see a number
of older systems that are essentially
one-vendor proprietary standards.
In particular, there's a standard based around the IBM
mainframe, there's a standard based around the DEC
VAX and VAX/VMS, and also a proprietary standard
developed by Apple Computer.
The difficulty with these standards
is that only a single vendor implements the base system.
And so it's difficult or impossible to make
an investment that's preserved in the different components
of the system.
On the other hand, we also have two open system standards,
one based around UNIX, developed by AT&T,
and one based around OS/2, developed
by Microsoft, which are freely available to everyone.
So if you have a good idea and you wish to start a company,
you can pick either to develop on OS/2 or on UNIX
and take advantage of all the investment
that people have made in those systems.
It is unnecessary to start from scratch
and develop everything yourself.
And that's very important, because that allows innovation
to reach the marketplace without reinvention of everything.
So the trend in the industry and the trend for the future
is that people are investing in open systems and standards.
UNIX and OS/2 will, we believe, get
the most seats, the most committed vendors, and the most
applications.
It's basic economics that if 100 companies can invest
in something, then more money will
be invested in that than something
only one company controls.
So being in universities, you've probably come in contact
with UNIX systems.
The UNIX system is very important,
over the last 10 or 15 years, to the university computing
environment.
I'd like to talk next about how we
see a UNIX standard emerging.
There's been much discussion of the lack of a UNIX
standard or the many UNIX standards,
and this has created a lot of difficulty
for the different UNIX vendors.
UNIX today is essentially a source-level operating system.
There are many different versions
that run on the many different platforms, ranging from the PC
to the Cray.
There is no binary standard and that
creates a big problem, in the sense that you
can't go down to your retail store
and buy some UNIX software.
And because UNIX didn't grow up on a single platform,
there's also no single look and feel for the applications.
So it's very difficult for an application developer
to develop something that's, say, like the Macintosh,
where his program is as easy to use as somebody else's,
because you can push the same buttons and the same commands.
Part of the reason for this is UNIX's long history.
It was really developed in the early '70s
at Bell Labs Research on 16-bit minicomputers
with paper terminal displays.
This UNIX was exciting.
It was a very powerful system.
It had the C programming language,
which was a very advanced language at the time.
But the applications which were written for that system
were necessarily limited by the fact
that it was running on a 16-bit minicomputer and the fact
that there was no sophisticated displays.
The paper terminals were exciting
if they could print both upper and lower case, for example.
UNIX continued its evolution in the late '70s and early '80s
at UC Berkeley in a project I was involved with,
where we took UNIX and made it run well on the VAX
and developed a lot of software which
worked on 24x80 terminals.
This made UNIX into a 32-bit system with virtual memory.
And we added networking and screen editors,
so this is a fairly substantial period of evolution for UNIX
in a distributed environment, in a full 32-bit environment.
For example, the PC standard that we
have today on 286 and 386, that software
is still stuck in the 16-bit space.
More recently, say in the last five years,
at Sun Microsystems, we've been using UNIX very
heavily to take advantage of microprocessors and bitmap
displays, which we can play with by the Rasterop primitive
that you see on Macintosh and languages like Smalltalk.
And the workstation market, which grew up around to 68,000
in UNIX, was really the first UNIX-dominated market,
unless you'd call the educational computer science
department market a market.
UNIX hasn't dominated in retail, it
hasn't dominated in the mainframe-class machines.
So it's important, if UNIX is to survive long-term, that it
had one market that it owns.
And this is really the market where
UNIX is now totally dominant in the market requirement.
And what we've done in the last five years to UNIX
is we've put in the technical features
to really take advantage of the distributed computing
environment that's been emerging.
Distributed file systems like NFS and RFS
and the advanced windowing systems,
like the X11 system or NeWS, allow
UNIX to take advantage of graphics displays
and develop sophisticated software.
So what we've seen is 15 years of cultural compatibility
with UNIX.
We've had three five-year periods
with three different kinds of platforms.
But the application's base has remained the same
and we've just added applications as we went along.
There's a lot of loyal UNIX users.
But there's some real severe problems
if UNIX is to grow outside of the workstation market
and outside of the universities.
In particular, to achieve wide acceptance of UNIX,
we need a single UNIX standard.
We need, in fact, a binary standard,
so that people can distribute software
through channels other than the direct channel, where
you can buy software in the store on a floppy disk.
UNIX needs to take account of DOS and OS/2,
which are very important.
Lots of people are going to have OS/2 machines on their desk.
UNIX has a number of problems, which have been
bandied about over the years.
Ease of use, security.
These things need to be accounted for if UNIX
is to continue to exist.
And we also need to defend UNIX against what
I would call the dark side.
Namely, the proprietary vendors who wish UNIX
would just go away.
The fact that people like to use it doesn't matter to them.
They have their own ax to grind.
So what we've seen internationally
is an awful lot of different people interested
in UNIX standardization.
AT&T has been working on an effort
called SVID, the System V Interface Definition.
There's an effort within IEEE to standardize UNIX, called POSIX.
The Europeans have an effort, under the X/Open auspices,
to standardize UNIX.
And Japan has an effort to standardize UNIX
based on Sigma.
These efforts are all very important,
because there's an awful lot of computers
out there we'd like to run UNIX on.
The difficulty is that none of these
is really broad enough in software,
and I'll talk in a minute about what I mean by that.
The other thing is that these people are standardizing
a software base, but not a hardware base, which
means that even a UNIX standard here will not allow us to have
shrink-wrapped software.
So there will still be a competitive disadvantage
for UNIX, relative to OS/2.
So what we've done at Sun is we've constructed one proposed
solution to this problem to try to keep UNIX
going strong into the '90s.
And I'd like to tell you a little bit about that.
You can take this as an example.
This is the kind of thing you have
to do when you're starting with a interesting piece of software
and want to take it to the market
and make it survive long-term.
What we've done, first of all, is
we've been working with AT&T and others
to really consolidate the different versions
of the system around a single standard.
We've been merging 4.2BSD with System V.
We're also trying to meet all the other open system
specifications, like the SVID and POSIX.
But it's very important in all this
that we not only do the UNIX standard stuff,
but add this kind of stuff that customers
and users and universities and other places
really need to do the research and development.
We need a standard graphics and windowing toolkit,
we need networking support, and we need the binary application
standard so we can have software widely available.
Those are technical things we need to do,
but we need to find a business context to do them in.
And the business context we've chosen
is the open systems one, where we
apply the leverage of the free market
to cause standards to emerge.
What we've done is we've developed a RISC architecture.
You've probably heard a lot about RISC,
a very high-performance, very simple machine,
based around the Berkeley RISC system.
And what we've done is we've gone
to a number of different vendors and given them
licenses to implement it, so that we
can provide a range of performances between 10
and 100 MIPS over the next few years.
By this business approach of licensing,
we've gotten access to the best technology.
And so it's a cooperative sort of approach.
And the other thing we've done is
we're selling UNIX in the environment with the chips,
so that, just like you get software from Microsoft,
from Sun, if you're a computer company,
you can get a complete UNIX environment.
So what we've done to date is we've
announced that we've licensed SPARC to Fujitsu, Cyprus
and Bit, three chip companies, which are providing us
with a range of performances from the 10 MIPS range,
which is available today, which is about
equivalent to the top of the VAX minicomputer line,
up to an ECL microprocessor, which should give us
about 50 MIPS of scalar energy performance, which is faster
for most of the interactive applications, say, than a Cray.
We're developing the binary standard
and you'll see some major endorsements of this program
in the fall of '87.
We think that this is the way to achieve a UNIX standard.
Other people may do the same thing
and there may be several of these,
but we think this one has a real chance of letting UNIX
survive into the next decade.
UNIX, to survive, is going to have to coexist.
We expect to link UNIX to OS/2 with windowing and networking,
to run DOS applications by emulation,
to support the full range of IBM SNA protocols
to link to the mainframes, and DEC connections
to link to VAX's and so forth, as well
as the protocols for the Macintosh to link to the Mac
with Appletalk and some graphics links, like with PostScript.
So if this all succeeds, what we would hope would happen
is that UNIX will become a wide and broad-based computer
standard that people who have innovative ideas
can go out and get UNIX and implement their ideas on top
of UNIX, instead of having to implement the whole system
themselves.
This removes a barrier to the flow of creativity
to the marketplace and it's very important.
The open system philosophy is the philosophy
that's causing this.
Licensing of hardware and software
with specs available and published
allows everyone to get in and do creative things.
And we're hoping that SPARC will be
the next major UNIX platform.
So that's where we're taking UNIX.
What about workstations?
You're all probably familiar with workstations,
hopefully you have some.
Workstations have been around now for five years,
and as we saw before, we had these periods of five years,
the five years that we saw Unix on the PDP-11, five major years
on the VAX.
And we think five major years on a machine, which is roughly
characterized as a big Mac with UNIX, a 68,000 with a few MIPS
and raster display.
History would suggest, if things change every five years,
that another transition will occur in '87
and that the preferred CPU and display
technologies should change.
And we would characterize this transition in '87,
much like we saw in '82, the transition from minicomputers
to workstations, as being the transition
to superworkstations, superworkstations
being super in two ways.
One having a supercomputer-like architecture and performance
to get us up to this 100 MIPS on the desktop in the next five
years.
And super in the sense of having a high-quality graphics, what
we call camera-quality graphics.
Graphics which is so high quality that you really
can't tell the difference between a picture
on your screen that was taken with a camera and a picture
that was constructed by the computer.
So if you just turn around and look at any computer
screen in your environment and then look away
from the screen at the rest of the world,
you'll see the difference between the state of the art
today, or whatever you have today, and camera quality.
That's a real challenge.
To meet the performance challenge
of putting 100 MIPS on the desktop, what we've done
is to find a scalable processor architecture,
a full 32-bit machine with normal integer instructions
and floating point.
But some support, especially for high-level languages and AI,
languages like LISP and Smalltalk
are very important for the next generation of software.
And so we leveraged off the Berkeley RISC II
and SOAR work to do this.
We've thereby got an architecture,
which we've looked at the technology for
and believe can be scaled up to 100 MIPS
into technologies like very high-speed CMOS, ECL,
and gallium arsenide over the next few years.
We have a 32-bit data bus, 32-bit address.
Not very many instructions-- of course,
it depends on how you count, but say, 80 or 100 instructions.
One thing that this architecture has
is an awful lot of registers.
If you look at the history of supercomputers, the machines
that Seymour Cray built, you've seen over time
that they've had more and more registers.
So what we did in SPARC is we put register windows,
an awful lot of registers, on the chip
to support fast procedure calls and to support AI language, as
well.
This gives us a lower off-chip data rate.
And these registers, you can think
of as the analog of the vector registers on the Cray.
This is a vector of procedure frames.
We've managed to implement this in a fairly old gate array
technology, running at 16 megahertz, to give us 10 MIPS.
Why is this going to scale?
What we really want to do with this architectures
is we want to put it in the highest performance
technology available.
We believe it'll scale because it's very simple, that there's
only 50,000 transistors.
We've left off a lot of stuff so that we could reimplement it
in hot stuff quickly.
It leverages static RAMs.
It uses off-the-shelf RAMs and float units
that generally already exist in a technology,
before anyone builds a processor, to run.
We've tried to translate the Cray philosophy onto a chip.
Cray machines tend to be very simple.
They tend to be very clever in their implementation
to get the speed, having lots of registers, large local
memories, like a large cache, or in this chip,
is the intellectual equivalent of the large local store
on the Cray-2 or the Cray-3.
The machine is highly pipelined.
Three or four-stage pipelines are required to implement it.
And the kind of support we've put in for high-level languages
in the system corresponds to the kinds of support Cray
puts in for Vector Floating-Point.
So what we expect to get out of this architecture
is a rough doubling of the performance every year,
continuing the curve you see here,
which shows how Suns have roughly
doubled in performance every year since we
started the company in 1982.
Our goal is to exceed eight MIPS in '87, 16 MIPS in '88,
32 MIPS in '89, and 64 MIPS in 1990
with microprocessor-based systems.
We expect to be able to double the performance repeatedly
because of the business leverage from open systems getting
us access to the best technology and because
of the technical leverage.
A very simple machine allows us to go in and use cleverness
to implement better pipelines, to continue
to work on the compilers and instructions scheduling,
and to take advantage, over time, of the extremely
large number of registers and other facilities
that are in the architecture for performance.
There are an awful lot of good ideas out there
that haven't been implemented yet in microprocessors.
There are ideas involving long instruction words.
Instead of a 32-bit wide RISC instruction,
you might have 100 or 500-bit wide RISC long instruction.
You see this in machines like the Multiflower Computer.
Vector Floating-Point, parallel organization, all these things
can increase the performance.
There are also new technologies to apply to microprocessors,
including, as I said, an ECL microprocessor, perhaps
a gallium arsenide micro, ballistical, optical, whatever
new technology comes along.
We've tried to design SPARC so that it's the simplest
microprocessor around, so that the first microprocessor
in each of these technologies has a chance of being SPARC.
So that concludes my remarks about processing,
why we think we'll get to 100 MIPS on the desktop
in the next few years.
Let's talk now about graphics.
Quality graphics is very important
and our goal is to have the quality of the screen
be as good as the quality of the real world
when you look out there.
For the last five years, we've been doing bitmap graphics,
whacking bits on and off on the display.
What we're seeing this year is a transition
from that bit-level model to what we
would call an imaging model.
The big transition here is that ASCII,
which was the old way of describing stuff that
go to the display, is being replaced by language called
PostScript, which describes printed documents very
nicely in a very resolution-independent way.
It describes things in real-world terms,
as opposed to the bit-oriented way
we've been describing things in the past.
The other transition that we're seeing
is a transition from doing graphics
in terms of vectors and polygons to being
able to do graphics in terms of curves and surfaces.
Technology to do this has been described
at, say, the last SIGGRAPH and we're
seeing PostScript sweep the industry in the printing space.
Now what PostScript and what high-quality, say,
Phong shaded curves and surfaces give us
are high-quality local shading.
This allows us to deal with an object at a time
and to cut and paste them together.
What it doesn't allow us to do is
to really model all the properties that photons have.
Light bouncing around the room, bouncing off
reflective surfaces, mirrors, glass, going through fog,
providing diffuse lighting.
All the very complicated things you
need to do to do sophisticated movie animation
and to really simulate the real world so the screen looks
like the real world does.
Supporting real-world quality is a clear goal
for a computing device.
We'd like to do at least as good as Lucasfilm
does in their wonderful movies they
make every year for SIGGRAPH.
The transition to be able to do this kind of thing
on the workstation is going to take a few more
years, because it involves such massive computing requirements.
In fact, if you look at the rough computing requirements
to prepare a display, looking back to '79, when
we had ASCII printers, a fraction of a MIPS, say,
a fraction of a VAX, and no floating point operation
could really put the characters up on the display.
By '82, when some of us had Macintoshes or Suns
or equivalent machines, a one-bit machine
could put up a bitmap raster and let us pull menus around
on the screen and draw lines.
To do engineering graphics, you need something a little more
powerful than a one-bit machine, perhaps something like an IRIS
from Silicon Graphics.
We have roughly 10 MIPS and a few megaflops
devoted to doing transforms in preparation
of the real-world coordinates of the graphics information.
Now in order for us to get higher quality,
what we'd like to do is to use curves instead
of lines and curved surfaces, rather than polygons,
to just dramatically improve the local shading
quality of the image.
The difficulty with this, of course,
is that it involves about a factor of 25 to 100
more computing.
And doing curves and Phong shaded solids
is something that we think will be state of the art in the '88,
but is probably beyond the state of the art today.
To get to the kind of global shaded environment
that I'm talking about, to do that in roughly real time,
needs about a factor of 500 more computing, about, perhaps, half
a million MIPS to render a Lucasfilm type
movie in real time.
So we're clearly have a long way to go.
Even doubling the performance every year,
it's going to take almost an arbitrarily long time
to get to 500,000 MIPS.
So to do global shading and real camera-quality graphics,
we're going to need massive parallelism.
If we have a super workstation, there's
some potential problems.
The first being that the I/O can be a real bottleneck.
You can imagine that this is not going
to spin all that much faster, and yet the machine
may be 10 or 100 times faster.
So the real answer here is to use caching,
to keep a lot more stuff in main memory,
and in fact, to put a battery in so that some of the memory
can be nonvolatile.
It can be basically a stable RAM disc.
Higher-level language has become possible
with this super workstations and that's real important,
because what we want to do here is
to use the MIPS to make the code smaller.
We don't want to make the code smaller
by putting in a complicated instruction set,
we want to make the code smaller by using
a higher-level programming language so
that smaller groups of programmers
can do interesting things.
The stress in all this, we think,
will be on applications environments.
Programming environments that are complete and interactive,
like a Smalltalk environment or a symbolic LISP environment
or an ALGO-like environment, like the Cedar environment that
was developed at Xerox PARC.
And we think stress on object-oriented programs
to make code reusable is also very important.
OK, so we've seen how the open system strategy can give us
leverage in an environment where technology is changing rapidly.
Hopefully, you're convinced that that's
a good strategy for the future and it
may help you to bring some of your ideas to the market.
We've also seen how UNIX is evolving
and how a UNIX standard might emerge that would allow
UNIX to survive into the '90s.
And we've talked a little bit about what's
next in workstations.
These are all relatively short-term things.
What I'd like to do now is to talk
about a longer view of where things are going over the next,
say, 15 years.
I'd like, in particular, to speculate
on UNIX, where Unix is going, where user interfaces are
going, where processor architecture is going,
and where hardware in general is going, the technology.
Because these are major components of the workstation.
I'd like to try to speculate what a workstation will
be like in the year 2001.
This is, of course, dangerous.
History has shown that people generally
underestimate what is possible.
I'll try to be an optimist.
I'm an optimist at heart, so maybe overestimate, perhaps.
But let's look at UNIX as it is today.
There's some real problems.
One problem with UNIX is that the C language is essentially
wearing out.
It's all written in C. C doesn't support
the structuring for large programs,
C doesn't support abstract data types very well,
it doesn't support parallel processing.
We have to address these things in the large UNIX programs,
in particular the UNIX kernel.
We have to also address the needs of the next 15 years
in having more ways of linking programs together.
We want to be able to make what looks
like a single program that runs on a bunch of processors
working together, whether they're
thought of as a multiprocessor or a distributed program.
By evolving UNIX, we have to solve the problems
with the lack of modularity of the code
and really make it possible to run the kind of multi-processes
we're going to see in just a few years.
So our hypothesis is that we'll see UNIX rewritten
in a language called C++ in the next few years.
And that the language will support concurrency in that
basically, concurrent C++ will become the language that really
defines UNIX, much like C defined UNIX in the beginning.
We expect to see an evolution of UNIX
to a system that supports very powerful programs running
in user mode.
The typical UNIX applications program
would then be concurrent, it would have dynamic linkages
to other programs in the network and to the kernel
and other resources, and all the facilities
that we've thought of as being part of UNIX kernel mode
would then be available to the applications.
The applications environment would be basically a runtime
for the concurrent C++ language.
One of the reasons why the UNIX kernel is so large
and unstructured today is that the extent
of the language you see for C in the kernel
is much more powerful than in user mode.
And so there are things you can do in the kernel
but can't easily do in a UNIX application.
C++ and its concurrent extensions should remedy this
situation.
The other thing we really need with C++ is we need
an integrated programming environment a lot of the things
we see for LISP or Smalltalk or with ALGO-like languages,
Cedar Mesa.
We need an incremental environment
and an interpretive, interactive environment.
We think this will be available in the next few years.
In the user interface area, we've
noted the problem that UNIX has no look and feel.
But beyond that, the state of the art today
basically being a bitmap display,
a keyboard and a mouse, really isn't
the interface of the future.
We believe that voice input is the natural complement to
high-quality graphics output.
Your voice is your highest bandwidth output device,
just as your eyes are you highest bandwidth input device.
So voice I/O with graphics is really the way to go.
Gesturing user interface allows you to wave your hands
and for the computer to see your body motions and perhaps
your mood.
All sorts of things are possible.
And people have begun to experiment
with gesturing user interfaces.
We think those will happen in the next 15 years.
Many people are working on the technology for 3D displays.
It's very natural for the display
to be three-dimensional, although there
are severe technical problems.
Take, for example, the application
of air traffic control.
It sure would be nice if the air traffic controllers were
standing over a scene that looked, perhaps,
like Star Wars, where they could see
the little planes as lighted things in free space
so they could see that they were going to crash into each other.
Your mind is pretty good at telling whether things
are going to collide by looking at a three-dimensional picture.
In fact, an animated display is something
we would expect to be a routine part of even the simplest
applications program in 15 years,
perhaps written by kids in elementary school.
They'll have animation languages that they
can program in, perhaps describing things
with their voice.
So what we expect to happen to UNIX over the next few years is
we're going to solve the first problem,
the problem of look and feel, by having UNIX adopt
one of the PC look and feels.
Basically, UNIX will either look like OS/2
or it will look like the Macintosh
or look like both, because those are
things that the mass market teaches people how to use.
And the real goal of the UNIX community
is going to be to produce a new wave look
and feel, one that can be driven with a voice
in a hands-free sort of way, uses inferencing and a database
to really provide a next-generation user interface.
And companies like Sun and NeXT and other advanced UNIX vendors
are beginning to work on these areas, a new media
interface for UNIX.
The next problem we could look at over a period of time,
over the next 15 years, is that the RISC architectural idea
will probably wear out.
RISC may run out of gas, say, in five years.
I mean, that's what history would suggest, roughly,
in 1992 that there's an opportunity
for an architectural evolution.
Now we could imagine that it was parallelism
and that we're just going to put in a lot of parallel RISC
machines.
But in fact, parallelism is hard to deal
with across a broad range of programs.
Existing programs are written in low-level languages.
They're written in C and FORTRAN and Pascal.
And the fact that the programming is fairly
sequential is very apparent.
There is not language mechanisms to automatically
insert semaphores very easily in most of these languages.
So it's hard to make them run, in general,
on a multiprocessor.
So what we would expect to have happen is two things.
First of all, for getting a single program counter
machine, a non-parallel machine, from a programming standpoint,
we would expect to see the long instruction word
idea become much more dominant.
We can expect that microprocessors based
on RISC with hundreds of bits for instruction
will be possible and people will write sophisticated compilers
to schedule the hardware and the programmers
won't have to think about the parallelism.
Fine-grained parallelism.
Parallelism without thought.
This is being done today on a graphics accelerator
that Sun has called a TAAC-1 and also on the mini supercomputers
built by Multiflow.
But this is really just, evolutionarily,
to really make a revolution in processing,
what we're going to need to do is to use massive parallelism.
Tens, hundreds, or thousands of processors.
We think the right way to approach
this is by using new languages, because applications
that are written in a way that parallelism is inherent
are much going to be much easier to compile for these machines.
So in particular, Sun, which is mostly
interested in powerful machines on the desktop,
sees parallelism coming to the desktop in three waves.
The first wave would be to solve the graphics problem.
To do the massive computing necessary to make
global shading possible interactively.
The second area would be in accelerating
specific applications.
For example, we might see a massively parallel machine
which can be used to simulate a neural network.
Such a machine could then be used
to program a simulation of, say, a part of the brain that
could do some interesting kind of computing
that we don't know how to do with the von Neumann machine.
But we think that having a massively parallel machine
is a central device in the machine.
The desktop is going to take a long time,
because it'll involve rewriting all of our applications.
That'll probably be the last thing to happen.
Now let's talk a little bit about where
hardware technology is going.
We've all heard a lot about room temperature superconductors.
And I would expect that, certainly by the year 2001,
we'll see people being able to fabricate
Josephson junction-like superconductors, which
run at room temperature with some micron geometries.
Today, we're a little bit in the situation
like we were early in the century or the turn
of the last century, when Edison was trying to find
a filament for a light bulb.
He'd stick any random thing in and test it
and see what happened.
So the people today who are trying to make room temperature
superconductors mess around, fabricate something,
it works for a while, and then burns up.
Doesn't superconductor anymore.
And nobody really understands why.
But over the next 15 years, applying the powerful computers
we have today, we should get a good understanding
of the science.
And it's clear from what we know about, say, liquid nitrogen
or liquid helium temperature superconductors,
that gate delays which are less than a picosecond
are quite possible.
In fact, we can imagine gate delays down to 1/10 or 1/20
of a picosecond.
If we can build a machine with such a gate delay,
then a cycle time with such a machine
might be on the order of 10 picoseconds, which
means a collection of 1 to 10 of these processors
could have a MIPS rating in the 100,000 to 1 million range.
So we might be able to build a small collection of micros
for your desktop in 2001 that was, say, 100,000 times the VAX
easily.
That might be the entry-level system.
So let's imagine what we would call a Sun-9, the 2001
workstation from Sun with one one-micron superconducting
microprocessor with a 10 picosecond cycle time.
And then what kind of memory would you
provide with such a machine?
Well, we could put in 1,000 RAMS.
And if you look at the RAM evolution curve,
we might get to a gigabit RAM in that timeframe.
So 1,000 gigabit RAMS gives us about 128 gigabytes of memory.
Those are both very large numbers.
And for resolution of the display,
we can just imagine that we max out
at the resolution of your eye, which
is fairly small by comparison to these other numbers,
it's only about 30,000 megabits per second.
So people have to talked about the 3M machine, the one
MIP, one megabyte, one million pixel, one megabit display.
The 111 machine.
This is 100,000, 30,000 machine.
It's almost 100,000 times as powerful,
and it's only 15 years from now.
So clearly, that's going to make an enormous difference.
In fact, it's hard to get a handle on what
effect of 100,000 will do.
We can look at some things like how many seconds are there
in a day?
Well, that turns out to be about a factor of 100,000.
So then, a computation that used to take a day on our VAX
would run in one second on this machine.
In fact, anything we could have done in an hour on our VAX,
we can make an interactive movie of,
because we could produce 30 frames a second
are the results of that computation.
Since a year is about 500,000 minutes,
we can see that a year of VAX time
will turn into five minutes on this machine.
And clearly, any calculation which
would take a year on a VAX today, if all you had
was a VAX, you probably wouldn't run it.
In fact, just imagine that you have this machine at your house
and you want to run a calculation overnight.
How much equivalent VAX computing
can you get in an overnight run, an eight-hour run?
It's about a century's worth.
So this is a little bit like the situation with space travel.
You can imagine, if the speed of space travel is advancing,
that the sublight ships that are sent out
get passed by the ships with the warp drive.
So starting a calculation on your VAX today
that'll complete a century from now, why bother?
Wait 15 years, and then run it for eight hours.
It's the same sort of situation.
How could we build a Sun-9?
Well, a Sun-9 might have a 10 picosecond cycle time.
The speed of light says that about a centimeter sugar
cube-sized computer will be about 33 picoseconds across.
That's about the largest we can make the computer.
In fact, if you get some information
about the Cray-3 and the Cray-4 that Cray is building,
you'll see that the very important thing that he has
is how big can the computer be?
The speed of light limits the maximum diameter
of his machine.
So this machine has to be substantially smaller.
It has to be small enough that the main memory is
within a cache miss delay in terms
of speed of light distance of the processor.
Of course, Cray is really pioneering
these kinds of machines, building them with lasers.
What he does is he has a laser which works
in a one square-inch area.
So the laser beaming together all the components
and squishing them down into, say, a one-foot cube.
For 2001, we can imagine that we might
use molecular-level assembly, either
taking individual silicon wafers and stacking them up
like we stack up layers in PC boards today,
so we may have 1,000 layers of silicon to make this cube.
Or even farther out speculation on how we might get
organic-like micro assemblers.
Things like little DNA and RNA to run around
in a symbol of this little computer creature out
of constituent parts.
People have speculated on this.
If you look at the book by K Eric Drexler called Engines
of Creation, he has some very interesting speculation
about what such machines could do.
What can we say for sure about the Sun-9?
I think the one thing we can say for sure
is it will require new software.
Any machine that's 100,000 times faster than what we have today,
we won't find the current software very interesting.
And it'll be for many reasons.
Because we'll interact with it in a different way,
with graphics and with voice, as opposed to
with a mouse and keyboard, but also just
because the power of the machine allows us to use new paradigms.
The other thing that's surprising about the Sun-9
is that it would either have to be increased in power by being
made parallel, and you'd just have to put a bunch of them
together, or it'll have to have a graphics accelerator option.
If you take the kind of software that Pixar uses today
to produce the animation sequences that are always
the last one shown at SIGGRAPH, the very nicest computer
animation, it wouldn't run in real time,
even on a machine that's 100,000 times as fast as a VAX.
If we can imagine 64 or 100 of these machines
with some parallel construction in a language that
allows us to take advantage of them,
then maybe that machine will be fast enough.
But it probably won't be the entry-level system
for your average engineer.
So just to sum up the talk and give you
a few conclusions about what all this might mean,
we think that open systems are the way to go.
Open systems are the ones that are best adapted
to an environment where change will occur rapidly.
If we really believe that systems
will be 100,000 times as powerful as they are just
15 years from now, that sort of advance
is going to occur in many, many steps.
Things are going to be changing constantly.
And we need the leverage of the open systems approach
to go out and get access to the best
technology in the marketplace.
Only by partnering with other people can
we get access to that technology.
No single company makes all the kinds
of computers you need today to build the best systems.
No single company is going to control
all the state of the art technology
that's going to be required in the next 15 years.
UNIX and SPARC are providing us with at least one solution
to the problem of an open system based on UNIX.
With DOS and OS/2 links and compatibility,
all the kinds of software that you want to run
can be run on a single platform.
And we think UNIX has a good chance of surviving
into the '90s and SPARC has a good chance
of being a major UNIX platform.
Super workstations.
These workstations with Cray-like performance
and high-quality graphics are, we
believe, the next wave of UNIX platform.
Whole new applications are going to get
written, because those machines are so powerful
and because of the kind of quality graphics
that you can do once you can simulate the real world much
more closely on the display.
So if you're thinking about what you
might be doing in a few years, what kind of research
you might be doing, thinking about starting
your own business, which is a very popular thing
to do these days, I think that one thing you have to plan for
is very rapid advance of technology.
I think you'll have UNIX to take advantage of.
And UNIX and the architecture, hardware, all these component
things are going to advance very, very quickly.
And it's people who know how to solve interesting problems that
are going to retain long-term value in their skills
in the marketplace.
So if you learn how to apply a good methodology
to problem-solving against a particular set of computing
tools and just be prepared that the tools are going to change,
the methodology will still be valuable,
and you'll have a lot of fun in the next 15 years
as we all watch the exciting future of computing.
Thank you.
I'm Judith Fleming from University Video
Communications, and our first faculty question
is from Columbia University.
Bill, with a network of distributed workstations,
can we use the high degree of hardware redundancy
to increase system availability?
Yes, I think we can.
The trend, really, is for computers
to become much less expensive.
And so just as today in buildings,
for example, there are many small motors,
what we'd call fractional horsepower motors.
They're buried all over the building,
it's almost impossible to count how many of them there are.
In the future, we can imagine that if you walk into a room,
you won't be able to tell how many computers are in the room.
And you might imagine that the studio that we're sitting in
could have tens or hundreds of microprocessors
and workstations and other things, all of which
are using very sophisticated software so
that the failure of any single one of them
wouldn't be apparent to us.
So I think that software is still in the research stage,
but it's going to be very important in the next decade.
Our next faculty question comes from Purdue University.
What have we learned from the experience with UNIX?
Should architectures be refined to suit it?
And a question to tag on the end of that,
can the government require UNIX as a standard?
I think we've learned a lot from UNIX.
Not all of it is technical.
We've seen a way in which something
which is used by a lot of people over a long period of time
in a very informal way can eventually come
to be accepted in the industry.
I think that's a good pattern for a lot of work done
in universities and research labs
to reach the market successfully.
In terms of evolving computer architectures,
I think UNIX has done a good job of helping us discard
a lot of architectures which had,
basically, undesirable properties.
UNIX doesn't make that many demands
of the computer architecture.
But computer architectures that are severely
poorly designed or otherwise unsuitable for a lot
of programming languages also can't run UNIX.
And so UNIX really sorts that out.
In terms of the government requiring UNIX or DOS or,
other software standards in their procurements, the issue
today, and it's in the courts, even, as we tape this lecture,
is whether the government can mandate those things
or require them when in fact, the requirements were
originally developed by a single company,
so that you could say that UNIX is proprietary.
Well, I don't think that's really the issue.
The issue is whether UNIX is available.
I think it would be unfair of the government
to require something that the specifications of it
weren't available so that anyone who wanted to
could implement it.
Or, in fact, to require UNIX if it were available--
the specification was available, but the only implementation
was so expensive that people couldn't afford to do it.
In practice, both UNIX and DOS, as well as
many other standards, are licensed inexpensively
and have been widely available for a very long time.
So there's no practical problem with anyone
who wants to use one of those standards from using it.
And UNIX and DOS do solve particular problems
that the government and other organizations
have in a very cost-effective way.
So back in the early part of the century,
Edison Electric Company was running DC power
and eventually got beat in the market
by other companies running AC power.
If the government had mandated AC power, because it had solved
problems that they had, namely they
could transmit it over long distances,
I think that that would have been a perfectly fair thing
for them to do.
So in the same way, UNIX and DOS solve problems that proprietary
systems don't.
And mandating their use to solve that problem is perfectly fair.
There really isn't an alternative in the marketplace
today.
OK, another question from Purdue University.
Many companies use only single-processor workstations
because of the rapidly increasing processing speeds.
When will applications' demands overtake their capacities?
When will we need multiprocessor workstations?
I guess from a standpoint of a university,
parallel processing is a real opportunity,
because you get to write papers about it and do research on it
and get a thesis and a grant.
And that's good, so it's a solution to the problem
of publishing or perishing.
In the commercial marketplace, when
you're trying to get the problem solved, though,
given the way languages are today,
parallelism is really a problem instead of a solution.
If I can accomplish a task at a given
cost with a single processor, then it gives me access
to more programming languages and more trained people
who know how to use it.
We hope the situation will change.
Over the last 20 years, the onset of parallel computing
has been announced many times.
But I think that it still remains a very difficult thing
to use parallel processing on the desktop.
And there are some vendors, namely Stellar Computer
and Data Computer, who are beginning to make noises.
They're going to be introducing their parallel desktop
machines in the next few months, probably.
And we'll get to see how well-accepted they are.
Parallel processing will eventually
appear on the desktop, but it won't be just an answer.
It'll also be a problem for some time.
This question comes from the University of California
at Berkeley.
Do you think RISC ideas and workstations are a fad?
Well, they definitely are a fad.
People want them, it's very fashionable
to be a RISC machine these days, as opposed
to what people call a [INAUDIBLE] machine,
a complicated machine.
And for better or for worse, the Intel 386
and RISC-based workstations are the ways
people want to do their computing for PCs
and workstations on the desktop.
And I think that's going to become more true.
This question comes from the University of Utah.
You talked a lot about MIPS and graphics.
Are there any software development tools
made practical by added MIPS and graphics?
Yes.
I think in the area of just the raw performance, the MIPS
rating, there are a lot of high-level languages
like Smalltalk and some of the AI-oriented environments
that have simply been too slow for people
to do production code in.
For example, a lot of the expert systems,
if you run them on real examples,
just take 20 minutes or 30 minutes
to recalculate and respond to a simple command.
And that's prevented people from really using them
in very widespread sorts of things.
So MIPS really breaks that bottleneck.
Higher-quality graphics also allows
people to automate and make interactive things that
weren't possible before.
In a lot of disciplines where hand-eye coordination is
involved, if you can't get an interactive response
to a movement of your hand, then you can't develop motor skills.
And so you need enough computing to do
the high-level application code and enough graphics
to track it on the display so that you can imagine,
for instance, reaching out on the display and doing,
with a gesturing interface [INAUDIBLE],,
what a sculptor does in molding clay.
You couldn't automate that today on a computer,
because the graphics and the processing aren't fast enough.
So I think there are many things we can imagine.
OK, and our final question.
Among your co-workers, you have the reputation
of finding simple solutions to complex problems.
Can you comment on your strategies?
Yeah.
I think if you're too close to the details,
sometimes you tend to find complicated solutions
to problems.
I think part of it is a question of perspective.
People need to go home from work.
In Silicon Valley here, we tend to work very, very late.
But you need to go home and relax and think
about things in a very clear way.
State what your assumptions are, question all your assumptions,
and try things that seem crazy.
A lot of times, a crazy idea that's obviously wrong
can be fixed into one that's right.
And brainstorming in small groups works very well.
And so we encourage people to regularly do these things
and it works very well for us.
Thank you very much.
Thank you.
And thank you for joining us.
We invite your comments and questions on this presentation.
We hope that you will make nominations
for future speakers and future topics.
And for these purposes, we have provided feedback postcards
under the label of your videocassette.
Thank you again.