Welcome to the Distinguished Lecture series.
I'm Karen Mathews of University Video Communications.
Our program is designed to enrich
graduate and upper division curriculum
with academic presentations from top computer
scientists and industry.
Speakers and topics were nominated
by computer science faculty of more than 50 universities.
This presentation is sponsored by Apollo Computer.
Dr. David Nelson, a leading figure
in computer architecture, received his PhD in physics
from the University of Maryland in 1970.
He has managed research at Digital Equipment Corporation,
and directed Research and Development at Prime Computer.
He is now Vice President and Chief Technical Officer
at Apollo Computer.
His talk today is network computing.
It's our pleasure to introduce Dr. David Nelson.
Dr. Nelson.
Thank you, Karen.
Before I begin a detailed discussion
about the technical aspects of network computing,
I'd like to build a context, a way of thinking
about architecture and the technology in general.
And I have developed a number of axioms that I, on the one hand,
think are very simple and easy to understand,
but on the other hand, I think are relatively significant
and provide some insight.
The first such axiom is the idea, or the observation,
that computers over the years have generally
cost an equal amount in terms of weight.
And I've observed that independent of time
and largely independent of the size of the computer,
that figure on the order of $200 down to $100 a pound
is not a bad estimate for how computers
compare to each other.
Another axiom is, again, relating to weight,
is the idea that weight is a very good determinant of use.
In the sense that a department for example,
might use 500 pounds of computers,
whereas an individual might use 50 pounds of computer.
A personal portable computer might
be as little as 10 pounds, for example.
And when we view computer architecture this way,
we can derive a system of tiers which really start
with very large environments such as campus environments,
and then a lower than that going to a building environment,
and then further down is a department, an office, and then
you get into the personal area which
is briefcase computers, laptop computers, and even
wallet-size computers.
And one interesting thing about this
is that over time the technology going
across these multiple tiers has very accurately correlated
weight to that environment.
We've observed another axiom, which
is that the technology rate through these various tiers
is approximately 35% per year.
When you compound that over a period of about seven years,
you observe about a factor of 10 improvement.
And so if we were to show that changes
across the tiers as a function of time,
we would get some very qualitative differences
in the machines at each tier.
We have here a chart which shows the computer developments,
beginning in approximately 1960, and extrapolate it out
to about 1990.
And vertically is the logarithm of the cost
of the machine or, accordingly, the weight of the machine.
And so we find that the technology following
an exponential curve at 35% a year,
is represented here by the series of straight lines
beginning at the upper left and then migrating slowly
toward the bottom.
We have found that concepts such as large virtual address
spaces, and large physical address
spaces, and many other concepts, such as hierarchical file
systems and other properties, or characteristics, of computers
typically obey this downward trend beginning at the top
and evolving toward the lower right.
When we populate these with workstations,
we see that there is a further refinement
of workstation products in that workstation tier.
The problem that this all generates
is that as time goes on, the tiers
become more and more populated with computers.
So these days we don't find simple environments.
We find environments that contain a variety of computer
sizes, ranging it with very large supercomputers at the top
and building mainframes in the mid-range and department-sized
computers lower down, and then finally workstations
at the lower tier.
And this, in part, has motivated the development
of a network computing model, which
is what I want to focus on primarily in this lecture.
Network computing, in our judgment,
should be viewed in a much broader context, which includes
some predecessor architectures.
Basically we view each of these architectures
as being generational, that is one mode
of computing lasted perhaps a decade each
and then it gave way to the subsequent mode.
So while the 1960s was largely associated with batch,
and the 1970s was largely associated with time-sharing,
Apollo Computer and others developed the idea
of distributed workstations as being the principle
architecture for the 1970s.
We are now developing a technique
which we refer to as network computing, which
positions the entire environment for the 1990s.
One interesting way of viewing this transition
is to observe the ratio of computers per user
over a very long period of time.
The number of users per computer back in the 60s
was literally thousands or more servicing
a fairly wide community.
The 1970s reduced that number down to approximately 100.
The 1980s, with Apollo and others and personal computers,
we reduced the ratio down to about one-to-one.
The interesting question here is whether that ratio,
or that trend in the ratio, will continue,
or will it stop with one-to-one?
And in fact, we believe that it will continue,
that the ratio will invert itself,
so that the number of computers will actually
outnumber the number of users by a very significant margin.
We could envision in the mid-90s of applications,
single applications, doing single functions,
taking advantage of literally hundreds of computers working
collectively, partly in parallel, partly sequentially,
but all to serve some greater goal or objective of the user.
This diagram more or less shows some
of the physical configurations of computer systems
as they have evolved from the 60s and on.
And in the lower right, we show a typical configuration
of a network computing environment.
Now I would stress in this diagram
that we are not thinking of simply connecting together
a large number of computers, but rather, we
are developing a technique whereby a single application
can dynamically run across an environment that's shown there.
Taking advantage of say, a Cray, or taking advantage of an IBM
mainframe, taking advantage of the graphics on a workstation,
in one integrated solution.
There are many dimensions to network computing.
It includes certainly the user view.
And in this area we regard the x windows standard
developed at MIT as being very fundamental to the technique
of exporting the user view across a network.
Network computing services is in the second area,
and here the yellow indicates systems
which have been developed and are in place,
and white indicates areas that are yet
to be fully developed or explored.
Further on, distributed data access,
and further on is network administration issues.
I'm going to narrow in on this broad view
by focusing on the network computing architecture,
and spend the rest of the time on, pretty much, this area
of network computing services.
We look at the whole problem of network computing
as being constructed, or I should say supported,
by two pillars, if you will.
One pillar being that which is associated with network data,
and the other pillar being that which is associated
with network computing.
These two pillars, to some extent,
represent the history of networking and the other pillar
represents the future of networking.
If you reflect on it, I think you'd
agree that most of the networks over the past 25 or 30 years
have been pretty much exclusively designed
around the idea of transferring or accessing data.
If you consider X.25, the ISO model,
and many other networking schemes developed
by various manufacturers, they have been principally developed
for the purpose of transferring files or accessing
files in place.
The idea of accessing computation on other machines
has been rather late-coming, rudimentary at best,
and generally thought of as an afterthought,
taking the principle role as being the axis of data.
That's been the history.
The future is to take is to re-examine networking and see
if we can't build a far more comprehensive model to truly do
distributed processing.
Using all of the features that have been previously
implemented regarding data access,
but advancing these principles to solve
the complementary problem of networked computing.
Frequently, the question of why now is raised.
The idea of distributed computing
is not a new one, its history goes back at least 15 years,
if not further.
This has been a rather well explored topic.
We have had numerous proposals, and implementations,
and research studies, and languages have evolved,
and architectures have been developed all for the purpose
of distributing an application.
But I think there are two trends that are occurring,
or two significant happenings, which
cause a commercial supplier like Apollo
to take a good hard look at this technology.
The first I'm going to comment on in a few moments,
is basically the emergence of a large number
of server hardware, which is being developed and now
being marketed on networks in the industry.
The second is certain advances in the area of software
engineering, and I've prepared a very brief sequence
over time of what I thought some significant happenings were
in the area of software development.
While I won't go through these in detail,
there is an interesting trend that
occurs when one looks down the chart from 1960 on.
The 1960s, generally, it was the first decade
to embrace high-level languages in any meaningful way.
And so we saw languages such as Fortran and COBOL,
which, to these standards, are largely
regarded as unstructured languages,
and so people didn't have any structured approach
to either code or to data objects.
The 1970s emerged with the concept
of structured programming.
Structured programming then led to the development,
or the modernization of Fortran, and the Fortran 77 standard,
and ultimately to the broader acceptance of C and Pascal.
And these days practically all languages
embody some form of structure in the programming.
They did not, by and large, address data in a complete way.
The 1980s are doing to data what the 1970s did for code.
That is, it is through the techniques, which
are referred to as object-oriented design,
we are now adding a high degree of structure to data.
By essentially encapsulating it into objects,
encapsulating data and procedures into objects,
allowing the internal state of these objects
to be varied and hidden from the rest of the world,
placing a high degree of emphasis
on the external interface of the object,
and attempting to describe applications
more as relationships, or interactions, of objects.
The significance here with regard to network computing
is that to the extent we can, in fact, think of applications
as collections of objects, we have, in essence,
decomposed a large, linear, complicated address space
into a number of independent, smaller address spaces.
And since we've then decomposed the virtual address
space we can in turn then, think of decomposing
the physical address space and, in fact, assigning
each of those address spaces to a unique physical machine.
So to some extent, the network computing architecture
can be thought of as an application which
is comprised of a set of distributed
network-based objects.
Now a good deal of the formalism and the theory,
I should say, behind network computing
is described in terms of object-oriented design.
Having said that, however, it's important to realize
that this requirement does not extend
its way into the application.
The network computing system that I'll be describing here
is very appropriate for non-object-oriented languages
such as C, and Fortran, and Pascal, and others.
But much of the theoretical description
and the architectural description of network
computing is, in fact, described in terms
of object-oriented design, and is most appropriately
thought of in terms of object-oriented designs.
The other trend I want to get back to
is one, really, comprised of two trends, one
in the area of applications and the other in the area
of hardware development.
And my assertion here is that these two trends are really
diverging and proceeding in opposite direction,
requiring, therefore, something like network computing
to bring them back together.
Simply stated, the trend in the area of applications
is toward integration of multiple disciplines
of computation.
And here we refer to a discipline
as being, say, computation, which is highly numerical;
or graphics which is, obviously, graphics;
simulation, which is frequently logical in its nature;
data management; AI; and many others, all of which
here we think of as being generic forms of computation.
Years ago, we would find applications
that would exclusively involve one discipline.
For example, we might find an application that simply
did computation, or another application, modeling
or drafting, which simply did graphics.
These days, however, application developers
are tending to integrate multiple disciplines together
into a single application.
Clearly in the area of workstations,
we integrate computation and graphics
in a very integrated way.
And in the area of electronic design,
we include things like simulation,
and in the area of mechanical solids modeling,
we very much integrate data management.
Not to exclude the others, such as AI, and testing, and so on.
So the tendency here is very clear,
and that is one of integrating multiple pieces of this puzzle
together into a single application.
What is the problem with this?
The problem simply stated, is that hardware does not
generally map well on to this puzzle.
Hardware, in fact, is going more or less
in the opposite direction, as shown here.
While applications are integrating,
one could say that hardware is somewhat
disintegrating, that is, they're specializing in their design.
So rather than finding a processor or a machine that
can equally well run all of the various generic types
of computation, we find just the opposite,
that products are being developed
to run one type of computation very well,
and neglecting altogether the other types.
And basically developing these components as
servers to be integrated at the network level.
The reason for specialization in the area of hardware
is complicated, but it's very compelling
to look at the results.
This chart compares the price performance ratio
of special purpose machines to general purpose machines,
as a function of a typical figure of merit of computation.
So for example, if the application
requires integer MIPS, we can go to a special purpose computer
and buy it at roughly a 6-to-1 advantage
over a general purpose computer.
If our interest is in megaflops, we can have a 10 to 1
advantage.
If our application is AI-oriented, and therefore
logical inferences per second, we can find a 4
to 5-to-1 advantage, simply by going to a special purpose
computer rather than a general purpose computer.
Similarly for transactions per second,
we have a 12-to-1 advantage, and for events
per second for simulators, MTB for fault-tolerant systems,
vectors per second for graphics systems.
All of these give a significant advantage
when the customer, essentially, buys a special purpose
computer rather than a general purpose computer.
The problem is, of course, that applications don't map well
on to this hardware.
But what we want, therefore, is a runtime environment
that essentially allows for the application shown
on the right, comprised of multiple pieces,
multiple components, to be executing transparently
on the configuration shown on the left.
Assigning, dynamically perhaps, the computational part
of the application to a compute server,
the graphics part of an application to a workstation,
the data management part of the application to a database
server, and so on.
So that here we are able to have the better of both worlds.
We're able to perceive and develop
the application as a single entity on the one hand,
and on the other hand, have its execution
occur on the machine which is best designed
for that type of application.
The challenges are many-fold, I've introduced a few of them
here.
Foremost, perhaps is to leverage the rather significant
investment that the industry has made in the area of software
engineering.
And so, to this goal we have insisted that there be really
no new software engineering concepts introduced
in the network computing system.
We want the software engineer to think of the application
as being singular, integrated together,
and we want the concept of assignment to be dynamic.
We want to have the perception on the part of the user
to be one where the user is not necessarily
aware of where computation is taking place, and so on.
So on the one hand, we want to have the logical advantages
of a single application, and do so
in a manner which does not introduce any new programming
concepts.
The second challenge is to take advantage of the dynamic nature
of networks.
And here we use terms such as accommodate
and exploit to describe our objectives here.
Applications should not be dependent
on any particular network configuration,
but rather, they should accommodate
a variety of configurations and, in fact,
accommodate them in real time as the configuration
of the network changes.
Machines, after all, can go up and they can come down,
networks can break and so on.
So we like to think of the application
rather like an expanding gas, where the gas is rather
contained by the pressure exerted on it through a vessel,
or whatever.
As the pressure is released and the vessel more or less
expands, the gas expands to fill it.
And conversely as the environment exerts pressure
on the gas, the gas contracts.
The metaphor here is applied to networks in the sense
that as networks break, the application
should contract and accommodate whatever environment
that it sees.
And conversely, when the network is repaired,
the application should suddenly somehow expand
to take advantage of that repair.
The network computing system that I
will describe in a little more detail
here exists currently as three major components.
These components exist on not only Apollo computers,
but they exist on most other competitive machines.
They've been ported to, and continue
to be ported to, a wide variety of workstations,
a wide variety of server processors, and so on.
The three components here include a locating broker,
a RPC architecture, and an NDL, or NDL compiler.
The locating broker is a database
in the system which helps facilitate
what we refer to as deferred binding, or dynamic linking.
Binding is a process, as we all know,
of one of linking together, or binding together,
various software modules, typically
subroutines or procedures.
Binding is usually static, that is
to say that developers bind--
or they compile a series of modules,
and then they bind them together into a static executable unit.
Some systems have employed dynamic linking, or deferred
binding, in the context of an operating system to facilitate
linking to libraries and so on.
But by and large, applications have
gone through static binding techniques.
We have implemented a technique of deferred binding,
largely for the purpose of deferring the binding problem
until execution time, where we can take
better advantage of the information
about the state of the network.
So rather than bind two modules together, one on a workstation,
and one on a mainframe, ahead of time,
we would rather defer and make that decision
at execution time, to take advantage of the fact
that maybe the mainframe is down, or too busy
or whatever other dimensions of the problem
might be imposed on it.
So by implementing dynamic binding, or deferred linking,
we can essentially create a much more dynamic environment
and assign the various procedures, or modules,
of the application to the appropriate part of the network
at execution time.
I have mentioned the idea of procedures.
Procedures are the basic building blocks
of applications.
Procedures are generally implemented--
referenced from one module to another through a procedure
call, and we have implemented remote procedure call, largely
as a mechanism to transfer control
from one computer to another.
So the way in which we dynamically assign the program
from one computer to another is at the procedure call level,
and we do it through what's called a remote procedure call
architecture.
RPCs are not new.
They have been fairly well explored
over the last 10 to 15 years.
They've been implemented in numerous systems,
including ours and others.
But the unique thing about the NCS RPC
is the way in which it interacts with the NDL compiler, which
I will describe in a few moments,
so as to provide application-level transparency.
Application-level transparency is required here
because we don't want the software
developer, or the application developer,
to be necessarily aware of how the application is,
in fact, going to decompose across the network.
So we are able, rather than to assign specific procedure names
to do RPC, we are able to allow application-oriented
procedures, such as invert a matrix, or whatever,
to be dynamically assigned to various machines
in a way that is transparent to the rest of the application.
It's important to understand how these three components play
together in the context of a real application.
In order to consider a real application,
let's consider the dimensions of a typical application.
For example, it may be comprised of literally dozens,
or hundreds or more, procedures.
These procedures can in turn be nested to some arbitrary
level of depth.
Procedures can call procedures, which
in turn can call other procedures,
and this nesting of procedure calls can be quite deep.
So in a network computing environment,
when we want to dynamically switch from one computer
to another at the event of a procedure call,
it's pretty clear that we could develop a very, very
complex environment.
Because one procedure call could call another computer, which
in turn could call another computer, which
could call my computer back again,
and this could wind itself into a very complicated state.
Now in order to understand all of that, what I'd like to do
is to describe a very simple application, in fact,
the most trivial application that
involves a procedure at all.
And that's shown on this slide, which at the top center
has one application comprised of a main body program and one
procedure.
So the idea here is that the application developer
think of and design the application
as being, very simply, a main program and one procedure.
It is desirable, however, to run,
for example, the main program on the Apollo
system on the left and the subroutine, or the procedure,
on the Vax computer on the right.
We want to do that in a way that preserves-- totally,
if possible--
the procedure call interface.
The procedure call interface can include parameter passing
and a variety of other things which
can complicate the environment.
We want, further, to perhaps run the procedure not
on a specific Vax, but we may want
to run it on, say, one of a family of Vaxs.
Perhaps the environment has two or four Vaxs.
We might also want to run the procedure
on a mainframe computer, which is not shown on the diagram.
So the policy may be something like run the procedure
on the mainframe if it is available,
and if it isn't available, then contract and run it
on one of the Vaxs, and if they aren't available,
whatever that might mean, then contract and run
the subroutine on the Apollo.
But from the user's point of view,
and from the software developer's point of view,
that assignment is not important.
The point here is that the application,
from both the developer's and the user's point of view
is perceived as a single entity, and the assignment
of the procedure is done dynamically
by the system in conjunction with the locating broker.
The assignment of procedures to other machines
is obviously not trivial.
We have a number of problems to overcome here,
not the least of which is the dealing of parameters, which
in part can be called by value, and part
can be called by reference.
There are other issues, such as dealing with pointer variables,
and variably dimensioned arrays, and things
like that, all of which have to be dealt with by the network
computing runtime environment.
Furthermore, we have differences in machine architecture.
Clearly these two machines have different representations
for floating point, and that turns out
to be a relatively easy thing to deal with.
More complicated, however, is the fact
that the two machines order bytes differently
to form integers.
And so while on the Apollo we form it one way,
the Vax forms it another way.
And so we need a much lower level information
than is typically provided by languages, or by filesystems,
and things like that, to essentially solve
this byte ordering problem.
Obviously, the runtime environment
has to deal with the dynamics and uncertain nature
of networks.
The fact that machines fail while applications are running,
and so the runtime environment has
to monitor the machines to which they have assigned work,
and so on.
There's a high degree of complexity associated
with the runtime environment.
So, consequently, we introduce this concept of a stub.
A stub means that something remains after you break it off.
And so in moving the application to the machine on the right,
or the subroutine to the machine on the right,
there remains a stub on the machine
on the left to totally mimic the missing part on the left.
Similarly, on the machine on the right,
we introduce a stub to totally mimic the missing main program
on the machine on the left.
The stubs then cooperate in dealing
with all of the problems that I have mentioned,
in a way that minimizes, if not eliminates,
all of the additional complexity on the part of the application.
The problem then becomes one of who generates the stubs?
How do we generate them?
Who manages them, who maintains them,
and who guarantees their integrity, and so on.
The stubs are generated by another part of the NCS
architecture, which is called the NDL compiler.
NDL refers to network interface definition language.
The interface definition language
is shown at the very top of this slide in blue,
and basically contains a description and interface
definition of where the application is
to be partitioned.
It contains the names of the various procedures,
contains a list of all the variables that are passed.
Most importantly, it contains type information
associated with each of these variables
so that we can subsequently solve
this problem of byte ordering and different formats
for data types.
The NDL compiler reads the interface definition,
and essentially automatically generates the stubs.
The stubs are then compiled on the various target machines,
in this case an Apollo on the left and a Vax on the right,
and, in addition, it can be compiled
on various other machines such as a mainframe.
The stubs are then compiled and bound together
with the various component of the application
to form a server process.
And so what we have done here is develop
a dualistic view of the world.
One view is one of the application, which
still appears to be singular, that
is we still think of the various application components
as being a collection, or I should say parts,
of a single program.
The other view is that after we run the interface definition
through the NDL compiler and bind it together
with the application component, thereby producing
a server, we at that point have a client-server model
of the world, where one server process is referencing
other server processes, and so on.
It's important to have this latter point of view,
because only in this way can we build a runtime environment
and operate it on top of conventional operating
systems such as Unix, and VMS, and others.
Because most of these operating systems do
embody some form of a server view of the world, clients
and servers and the like.
I'd like to mention a few other aspects of the network
computing system.
The first here refers to the locating broker, which I
have briefly already described.
The functions of the locating broker
are to track network resources, for sure,
and to essentially deal with the dynamics of the network.
The locating broker is best understood
in terms of the client-server model.
The purpose of the locating broker
is to really prevent clients and servers
from requiring complete knowledge about the network.
Rather than having everyone know everything about everything,
we put all of the knowledge in one place,
basically, in the broker.
It behaves then as an object-oriented database,
and is referenced by clients and servers
to obtain information in much the same way
that a broker serves in the transaction of a real estate
sale.
Real estate is listed and sold in a broker,
largely to provide both buyer and seller
with wider knowledge than what they would otherwise have.
The locating broker is made aware of network services
through what is called a register function,
or a registration function.
Basically, as servers are assigned to machines
and they become operational, the first thing they do
is to register their availability with the broker.
Subsequently, when the application is executing,
the locating broker is referenced
to find out what the complete set of information
is relative to that particular service,
and make some policy decision as to which machine to be used.
The policy decision is complicated,
but could include the level of loading
on the various machines, what machines are available,
what networks are available, what sort of special hardware
is available on the machines, and many other issues as well.
Several other aspects of the computer system
is to allow for the execution on a variety of transports,
and to work in a multi-vendor environment, which
is clearly required in order to realize the objectives that we
stated earlier.
We have developed a system so that it
is layered in on top of a number of different types
of protocols.
Basically, the runtime environment
employs what is referred to as a connection-less, unreliable
datagram service, and such a service is generally
found in a variety of protocol suites, including ISO,
and including TCP/IP, and a variety of others.
In this way, we're able to take advantage of not only
the software that has been developed,
but also hardware architectures that take
advantage of those protocols.
Further function is to be transportable to another number
of operating systems.
The specification of the network computing system
is in the public domain, source code
is licensable at a very low cost,
and furthermore, there is no binary license
fee on the part of users, or application suppliers,
or other vendors, to employ this system.
So we have created a fairly complete scenario,
and we expect it to be readily used on various Unix systems,
as well as VMS, and including, in fact IBM PCs running MS-DOS.
I'd like to present an example which
I believe illustrates many of the advantages of network
computing.
In this example, it is one of mechanical simulation used
by automotive industries, aerospace industries, farm
equipment manufacturers, and so on.
The problem is how do you simulate
a very complex mechanical device, that on the one hand
requires mainframe levels of computation
to simulate, and on the other hand,
would be desirable to be able to view the simulation as it
is occurring.
Typically, this is not done, but rather an engineer
employs a series of pre-processors, and simulators,
and post-processors, and generators of animation
sequences, and so on.
With network computing, we replace
all of those various applications
with a single application whose graphics part
runs on the workstation, and computation part
runs on a mainframe.
This really allows the design engineer
to do two things they've never really done before.
First of all, they can, for the first time,
visualize the results of mainframe computation.
As the mainframe is computing, it
is very rapidly making procedure calls to the workstation.
The workstation is then, in real time,
rendering the effects of that simulation
so that what the user is seeing at the workstation
is the visual results, in real time,
of the simulation being performed on the mainframe.
The second thing the design engineer
can do with this application is to begin to interact
with the problem of simulation.
We could envision velocity controls,
for example, that would allow the simulation
to even run in reverse.
We can envision the dynamic adjustment of parameters.
In this case, perhaps the suspension system
of an automobile, to tune it, if you will,
in the simulation without having to iterate over various design
parameters.
Furthermore, with a multi-windowing environment,
we can create multiple windows, each of which
has an aperture into the mechanical model.
We can zoom in on problem areas, and reverse the simulation, run
it in slow motion, and so on.
So the bottom line is that with network computing,
we can bring the resources of the mainframe
down to the desk of the design engineer,
with no real artificial boundaries imposed
by the network.
Bring those computational cycles to the desktop,
and allow them to be applied to what would otherwise
appear to be a graphics-oriented problem.
A further development of network computing
is the ability to run concurrency
in the network computing.
This essentially involves the ability
to run a large number of computers in parallel,
as shown here, dynamically assigning them,
perhaps in fairly large numbers.
As a final thought on network computing,
we'd like to consider many of the operating system
implications.
Once one distributes the upper layer, the application layer,
one develops a lot of problems having
to do with security, licensing, accounting, scheduling,
and the user environment.
Basically, what is going on is the industry
is developing a comprehensive model
to deal with these operating system
functions, re-implementing them, rethinking them, re-engineering
them.
So many of the features found in traditional operating systems
will in the future be placed at the network level,
in terms of vendor-independent, operating
system-independent servers, and thereby reducing
the complexity of the workstation dramatically.
We, in fact, intend that network computing
could be the first environment that would transparently
operate across multiple operating systems, manufactured
by multiple vendors, and applied in a fully distributed
environment.
Licensing servers.
One example of a server-based operating system component
shown here, that will essentially
give application suppliers much more flexibility in how
they license server.
We are beginning to develop equivalent models
for dealing with authentication, accounting, security, the user
point of view, and so on.
So what I have described to you is a network computing
architecture which we believe represents
a new generation of computers, has the advantage
of taking advantage of many different types of computation,
all applied to what would be viewed
as a single problem, or a single application,
by both the application developer and the end user.
I'm Judith Lemon from University Video Communications.
Our first four faculty questions are from the University
of California at Berkeley.
Dave.
Number one.
What do you see is the role of multiprocessor in workstations?
Well, multiprocessors already occur in workstations.
We find, for example, on the one hand,
there may be a main CPU doing general applications,
and on the other hand, a graphics CPU doing graphics.
So what we are attempting to do is
to generalize that dichotomy that already exists,
make these general purpose computers in general,
but making the general purpose computer
more robust in its ability to perform not only computation,
but graphics.
So at the high end, we see a very strong role,
an important role, in multiprocessing.
And, moreover, we see these processors
being generally applied, not only to applications, but also
for high-end graphics processing.
OK.
Karen?
Question number two for you is, do you think RISC ideas
in workstations are a fad?
Well, I'm not sure I would characterize them as a fad.
Clearly there's a lot of merchandising, and so on,
going on associated with RISC.
We think there are a lot of valuable ideas associated
with RISC techniques, but we don't
think that they ought to be exclusively applied
to the design of a computer.
We think RISC is one component in many different components,
all of which can be applied to the design of high performance
computing.
Basically, RISC is the result of there no longer
being importance placed on a machine language architecture
any longer, allowing high-level language compilers
to have direct access to the computer.
OK.
What is the role of mini-mainframe
and supercomputers in workstation environments?
Well, I think the role now we are aware--
we are becoming more and more aware
through network computing and other techniques,
that the role is one of integrating together.
The problem is, and will continue to be,
how do we get the MIPS that the mainframes
and the supercomputers supply, and the databases
that these machines supply, down to the level
of the individual user.
Network computing can be applied to that problem,
and we believe solve it very nicely.
Why does Apollo think that four MIPS is enough in 1987,
but needs significantly more MIPS in 1988?
What demanded this big change?
Well, fundamentally the reason for the disproportionate jump
in performance rates is basically
driven by what technology offers us.
If we take RISC technology, and we
take very large-scale integration of circuits,
and apply them to chips, and do some organizational things
in the design of the computers, along the lines that I've just
mentioned, we believe that technology
will allow us, at the high end, to actually deliver
those kinds of performance levels.
The applications that we envision for this are numerous.
Seismic analysis, finite element modeling, in terms of graphics
would include three-dimensional solids modeling.
There are numerous applications for high-end computing,
and users continue to be demanding
more and more computation.
So there's clearly a market need.
And the basic thing that's driving us
is the availability of the technology
that we see forthcoming.
What do you see as the next generation of computers
beyond workstations?
Well, beyond workstations, I think
that's a very broad and long-ranging question,
I suppose.
But one of the things that I, as a user,
have been interested in for some time
is the application of portable computers to many engineering
problems.
If we think of a workstation as being confined to an office,
and confined to a specific network,
basically, what we want to do is relieve those constraints.
Reduce the confinement, allow the user
to carry the system around with them,
allow the system to automatically know where it's
been, know where it's going.
If it's at home, it should know it's at home.
When it's in the office, it should know it's in the office.
It should be able, through ISDN techniques,
perhaps, be able to connect in a very broad way all
over the globe.
And in a very dynamic way, depending
on the nature of the problem.
So I think we will see in several years, the forthcoming
of very, very capable portable systems
which are really well beyond what we see today
in portable computers, but will include
these characteristics of being able to dynamically adapt
itself to an environment.
I like that idea.
And finally, how do you manage to keep up
with the rapid change in computer development,
and what kind of a framework would you recommend to students
for doing this?
Well, I personally have relied on the idea
of models and trends over long periods of time.
And to look at deviations off of that model.
That is, rather than look at rates
of change in terms of their absolute value,
look at the deviation in rates of change over a fairly
long period of time.
I think it's as valuable to look at the things that
don't change as it is to look at the things that do change.
For example, the cost per pound of a system
is one of the constants that I alluded to earlier.
The 35% per year as a function of time
is another constant that seems to have
prevailed over several decades.
Although in the workstation area, the rate of change
is significantly higher than that.
So basically, I like the idea of developing a very simple model
that is uniform over a long period of time,
and then looking at the deviations
relative to that model.
Well, thank you very much.
Thank you, I enjoyed being here.
And thank you for joining us today.
We invite your comments and questions.
And we hope you will nominate future speakers and topics.
For these purposes, we have provided,
under the label of your video cassette, feedback postcards.
Thank you again.