University video communication is pleased to present this
video tape edition of the Distinguished Lecture Series ,
industry leaders in computer science and electrical
engineering.
Speakers and topics in this series
have been nominated by University faculty who
want industry material for use in their courses.
Today's presentation, parallel processing
is by Tilak K. Agerwala.
An IEEE believe fellow, he received his Bachelor
of technology in electrical engineering
from the Indian Institute of Technology,
and his PhD in electrical engineering
from Johns Hopkins University.
As a member of the corporate technical committee
in the science and technology department at IBM
corporate headquarters, one of his current responsibilities
is for corporate wide assessment of parallel processing at IBM.
UVC is happy to introduce to you Dr. Tilak Agerwala.
It's a pleasure to have this opportunity to speak to you
on one of my favorite topics namely, parallel processing.
The presentation today will be a tutorial presentation
where I will try to give you an overview of some
of the important trends in this area of parallel processing.
Now many of you are quite familiar
with the various motivations for parallel processing,
I would on this particular slide emphasize two.
The performance potential of parallel processing
is one of the key motivations.
And the performance aspects are really common to flavors.
One can talk about the maximum performance possible ,
the maximum absolute performance,
one can also be motivated by the ability to back a lot
of performance in the small package,
and one typically may want to do that in workstations.
There is a potential for improved cost performance,
to provide scalable performance, and the other one
on this list that I really do want to emphasize
is reduce development cost.
And reduce development costs also comes in two flavors.
Sometimes it's possible to get significant performance
without developing very sophisticated technologies
and very sophisticated packages that are developed for very
high performance machines.
Secondly if one is interested in really providing
a very wide range of performance for example in IBM,
we cover the range of systems from personal computers
to supercomputers, then one is faced
with the question of how many unique uni-processor designs
should one develop to cover that range of performance.
And clearly with parallel processing
then one has an added dimension so
that the number of unique processor designs
can be reduced and the range can be
covered with the use of parallel processing.
Increased availability is also an important consideration
and is very important in today's systems.
There has been a huge amount of progress in computers.
Generally, I'd just like to state
that the driving force behind much of this progress
is really progress in micro-electronics.
And this the slide illustrates what some of the trends
are in the area of memory, CMOS, and bipolar technologies.
I should emphasize that this slide is not just
obtained by sitting down with log paper
and projecting into the future by drawing straight lines.
This graph is obtained by a very thorough evaluation
of the problems that are likely to be faced in the future
and by considering the solutions that one may use to address
some of these problems.
And the basic message that I want to give you on this slide
is that technology at this level is going straight ahead
and there's no end in sight.
Now, the basic technology capability for example
then translates into the ability to build processing systems.
And what I am illustrating on this slide
is the evolution of microprocessor systems,
that the systems that can be built on a single chip
or on a small collection of chips.
And with 1 micron CMOS technology today,
we are essentially sitting in the range of 20 to 30
million instructions per second and this will steadily
move into the 50 to 70 range.
I should emphasize that this performance comes--
these numbers are based on the assumption
of having a machine organization that
can deliver approximately 1.2 cycles per instruction
for average workloads.
If one uses more sophisticated machine organizations
and we certainly know how to do that,
these numbers can increase significantly.
Furthermore another factor of two
can be obtained by using liquid nitrogen cooling
and by using some of the developments
in high density, low power, bipolar technologies.
It's certainly feasible in the early 1990s
to get into the 100 million instruction per second range.
I really want to make two points over here.
Firstly that the building blocks that we have available to us
now are becoming powerful enough so
that the small MIPS effects that one would encounter with lower
performance microprocessors are no longer
coming into the picture.
And secondly that with a 40, 50, 100 million instruction
per second building block, one does not
have to go to very high levels of parallel processing
to get fairly significant systems.
So 16 way and 30 way parallelism with 100 microprocessor
puts you into a very interesting range.
Of course, to get the supercomputing kinds
of capabilities as I'll point out one
can use higher levels of parallelism.
Now let me then talk about some of the important trends
in parallel processing.
And this slide will indicate to you
that I am in fact viewing parallel processing
in a very broad sense to cover clustering, multiprocessing,
and very highly parallel processing.
And I will spend the next few minutes defining these terms
and giving you some examples of systems in each of these areas.
In clustering, one typically connects a number
of complete computers that is processor and memory
pairs together to disks.
The key motivation for clustering
is to obtain improved capacity and improved availability yet
at the same time to provide a single system image.
That is the key challenge.
One is trying to develop a system that
consists of multiple processors but looks
like a single computer system to the operator
and to the end user.
Now what do I mean by a single system image?
I basically mean the following, that the system
should look like one computer system
from an administrative point of view.
It should have a single file system.
Users who log on to the system should not
be aware of the particular computer
that they end up executing on.
And the system should provide a high degree of availability
and graceful degradation.
Now, in clustering, this is attained
not by having one single operating system that executes
on all the machines, but rather by having
multiple copies of the operating systems
that exchange information typically at the page level,
and thereby software synchronization techniques
are adequate.
Let me just point out that examples of clustering
are the transparent computing facility, which
is part of IBM's UNIX systems.
And I will talk about that later.
Systems like tandem and vax cluster
are also examples of clusters.
Now, the situation in multiprocessing
is a little different.
Here you have processors that share
information at very high speeds, typically
by executing loads and stores against a single memory system.
The synchronization between the processors
is provided at the hardware level,
because the exchange information at these very high speeds.
As a result of this hardware synchronization,
the extensibility is typically limited.
So these systems are restricted to the 8, 16, 32 processor
range and typically will not go significantly beyond that.
Now the goal here really is to get the multiprocessor
to look and behave exactly like a uniprocessor system.
So all the subsystem interfaces, all the application interfaces
to the operating system should be
identical to what they are in a unique processor.
And this really means taking a unique processor operating
system and having the single operating system execute
across the multiple processors.
And this involves implementing mutual exclusion that
involves analyzing the data structures,
understanding how they're used, and providing
the appropriate levels of process synchronization.
The key, of course, is to do all of that
and yet obtain very high efficiency.
Now multiprocessing is being applied
across a very wide range of systems,
all the way from workstations to high end machines.
The motivations in each case are slightly different, of course,
they are all related.
In high end systems, the overall goal
is to provide levels of performance
beyond that achievable by the highest performance
uniprocessor at any given point in time.
So the key high end issue is really performance.
All the other issues and motivations
that I talked about earlier, do apply as well
but the performance issue I believe dominates.
In the mid-range again performance
comes into the picture but the goal here
is really to provide high levels of performance
without necessarily getting into very high performance
uniprocessor development, without getting
into the high performance technologies and packages that
characterize very high performance uniprocessors.
And at the same time horizontal growth
is a key issue in the mid-range.
Now the workstations the motivation
is to provide the highest levels of performance
in a very small package.
And there's really a fairly interesting trend
that is taking place in the workstations, which
to a large extent is driven by this technology
of parallel processing.
And the situation is as follows, by taking
some of these high performance microprocessor systems that
are under 20, 30 million instructions per second range
and implementing them, a system consisting of 4 or 8
microprocessors, one can get into performance ranges that
were typically characteristic of supercomputers of a few years
ago.
Now, the workstation however, has an additional capability.
These MIPS can also be used to provide graphics
and to provide user interface processing.
And since the computing engine is now
very close to the user interface,
they can be connected together by very, very high bandwidth
interconnects.
And you can typically now get levels of interactivity
between the compute engine, which is in the workstation,
and the graphics processor, which is in the workstation
significantly beyond what is possible by having
a thin pipe that connects your workstation to a supercomputer
in the background.
So this is a key trend that is happening in the workstation
arena, which I think is being driven significantly
by this technology of parallel processing.
Now let me just give you a few examples
of systems in these areas.
In the high end IBM 3,090 mainframes
are multi processors as other carriers
and as will be the SS1 machine from Steve Chen's company.
In the mid-range the machine systems
like the 4,381 alliant and convex
are examples of systems that use parallel processing.
And at the workstation we see a numerous systems today
examples addent, stellar, and silicon graphics.
Now we move on to the area of highly parallel processing.
As many of you are aware, there's
an incredibly large variety of architectures and systems
that are being developed and studied both in universities
and in the industry.
And it is not my intention here to go
into a very complicated taxonomy that
describes these various parallel processors.
What I would like to do, though is
take these highly parallel processing systems
and put them into two very general categories
that I call specialized and multipurpose.
And let me just make a few comments about each of these.
In the case of specialized parallel processing,
the technology is very well understood today
and highly parallel specialized processes today
are being used to solve important problems.
Problems that are either economically important
or of scientific importance.
And I will talk about two examples that we have developed
and are working on in IBM, the logic simulation
machine and the GF11.
Characteristic of these machines is
that they are intended to solve just one single problem or one
single well understood algorithm.
And as a result, you don't require
very sophisticated programming environments and compilers.
This allows you to develop these machines
without great development costs.
It's my estimate that machines that
can deliver hundreds of gigaflops or even a teraflops
are quite feasible and will be used over the next few years
and such machines can have a very significant impact
on science and on engineering.
But I would like to make another point, which
is that there are other specialized machines
and I've given you one example on the slide, the database
machine, which is a little different from a logic
simulation machine or a machine for a physics application.
These may be used by very few people.
But a machine that can do a complex query very rapidly
is performing a specialized function
but it's performing a function that
will be important to a very large class of users.
In fact, I believe this is an example of a more general trend
where clearly subsystems are being identified
and database is one of them, which are often accessed
by through very well defined interfaces,
for example a SQL query, which are amenable to being addressed
by a special hardware in the case of SQL machine
by a highly parallel processor.
And this is an important trend because it's
a specialized function but it's a function
that will be of use to a large number of people.
I think the whole area of specialized highly parallel
processors is an important one and we
have to start understanding the role
that these machines will play in general computing environments.
Now on the other hand, the area of
multipurpose parallel processing though it
has significant potential, I believe
is also an area where a significant amount of research
still remains to be done.
I will talk about this a little more later on
when I describe the RP3 machine that we are working on at IBM.
I would like to make two points at this stage, though.
One is that the availability of hypercubes
has really been very important.
The second point I would like to make is that in my estimate
the area of data flow computing is very important
because it provides the potential
to exploit massively parallel unstructured parallelism.
I believe more work needs to be done in this area
but the potential is very significant.
And to end this introductory section,
let me just say that in addition to the various classes
of machines the two uses of parallelism
to high level uses of parallelism
that we should distinguish between, one of them
I call system parallelism.
And this is the ability to take different users' applications
or different database transactions
and run them in parallel.
This does increase throughput.
It doesn't make any single application run faster.
A big advantage is that it requires no change
to user programs.
And typically, this class of parallelism
is obtained through multiprocessing
and through clustering.
The other kind of parallelism is application parallelism.
And here the goal is really to take
a single job or a single transaction or a unit of work
and break it up into little pieces
and run all these pieces in parallel.
This doesn't make any individual application run--
this does make individual applications run faster.
It may not increased system throughput
and it may require changes to the user's program.
Typically, multiprocessing and highly parallel processing
have the potential to provide this kind of parallelism.
And this indicates also multiprocessing
is a very important systems trend because it
does address both systems parallelism and application
parallelism.
What I would like to do next is to illustrate
some of the concepts I have talked
about with specific examples.
I've chosen examples from IBM because those are the ones
that I am more familiar with.
So we start off with clustering.
And that's part of IBM's UNIX offerings.
An IBM UNIX is called AIX.
We have a system called the transparent computing facility.
This system provides a single system image of the type
that I had discussed earlier, across
heterogeneous processors.
The processors can be either system 370 machines or PS2
machines.
Now a single system image in this case
means what I had said earlier that is you get a single file
system, you get log on transparency,
you also get a certain amount of local remote execution
in a transparent manner.
For example, you could be developing and editing
your program on a workstation.
The program could be compiled on a mid-range 4,381 or 9,370
and could be executed on a high end 3,090 system.
And all of this would happen in a manner transparent to the end
user.
The second important point is that these systems
can be connected in a variety of ways, either through channel
to channel attach or using local area networks.
Let me move on now to mainframe parallelism.
And let me talk about the 3,090 model 600,
which is a six-way tightly coupled multiprocessor.
These processes have gaseous and there's very extensive
hardware gas coherence that is provided in a system like this.
The boxes labeled SCEs are storage control elements
and are very complex switches that
bring the processes and the channels
together and provide a coherent view of the shared memory
system.
Now, in many ways in a system like this also
some of the key challenges and some of the key issues
are really software issues.
And we have made a tremendous amount of progress
in obtaining true symmetric multiprocessor
capability in our MVS and VM operating systems.
Furthermore this multiprocessor capability
is exploited by subsystems like IMS and GICS
to get system parallelism.
We have made extensions to the Fortran language.
And together with the automatic detection of parallelism
we can now exploit application parallelism
across this six-way tightly coupled multiprocessor.
There's been a fair amount of work
on subroutine libraries for our vector machines.
And these subroutine libraries are now
being extended to provide support for parallel processing
as well.
The point I want to make is that the six-way,
for example in this case six-way tightly coupled
MP is a very well understood technology that
is being exploited both for system parallelism
and for application parallelism side IBM.
Just to give you a brief example of the kind of speedups
that we are capable of getting by the use of parallel Fortran,
here's a slide that shows three applications of varying degrees
of utilization but you can essentially get 4 to 5
and 1/2 way speed up on a six processor system.
Another system that we have we are working on,
which is an experimental prototype
is a combination of concepts and we are calling it form coupling
for the lack of a better name.
This is really taking two 3090 600 complexes
and connecting them at the shared electronic level
with very high bandwidth fiber optic interconnections.
This as I said should be viewed as an exploratory system
and we are trying to understand the various ways in which it
can be used.
Some of which I have listed on the slide.
So you could use one side of the system for application
parallelism, the other side for system parallelism
or you could use both sides for application parallelism
or you could try to take one job and split it across all 12
processes and get application parallelism across 12
processes.
Using the system to address some of the operating
system and compiler and language issues that would
be involved in form coupling.
Let me move on to workstation parallelism.
We have developed in researched a vehicle,
which is again an experimental vehicle
to understand some of the important issues in this area.
In this particular case, what we would like to do
is we would like to study how best parallel workstation can
be used--
how parallelism can be used and exploited in a workstation.
Again the various forms of parallelism
that one could exploit, either the system parallelism
or the application parallelism.
And this is a vehicle to start studying some of these issues
from a software point of view.
The vehicle consists of eight IBM risk microprocessors,
each with floating point capability and each
with about 8 megabytes of memory.
There's 32 megabytes of shared memory capability.
This machine does have a shared address, a global address
space.
The memories and processors are connected together
by a high speed 80 megabytes per second bars.
Again since this is a research vehicle,
we have provided a real-time hardware monitor
that will allow us to make measurements
on various parts of the system as the software as executing.
Let me now move on to the area of highly parallel processing.
And I will start with specialized highly parallel
processing and I will go through very briefly two examples,
the engineering verification engine
and the GF11 parallel processor.
Now what was the problem that we were
trying to address with EVE, the Engineering Verification
Engine.
The problem is really that of logic simulation.
And in this particular case, the goal
is to simulate the logic of a high pros--
high performance processor, one of our high end machines.
And logic simulation is a very important part.
And it's the front end part of the design process.
The goal is the following.
The goal is to try to simulate at the logic level processor
yet to be designed, which is in this case
approximately 300,000 gates and to simulate
5 minutes of execution of that process that
remains to be designed.
Now to do this.
This was the problem we faced in the late '70s and early '80s.
And basically to simulate the next generation
high-end machine for five minutes
would take a 1980 mainframe approximately 100 years,
and this is obviously impossible.
The EVE machine will do this in six weeks.
This is an important example of how
you can use parallel processing to take a problem that
is an important design problem, which is essentially impossible
and to make it very practical.
And that's what EVE achieved.
It achieved this by using a highly powerful processor
but a very specialized processor.
That consists of 256 elementary processing elements connected
together by a crossbar switch.
Now each of these processors, these elementary processors
is really a very simple computing element.
And what it does is to read from an instruction memory
and then do very simple logical operations on a data memory.
And it does these operations one at a time.
That is, it'll take four digit items do a logical operation
on them and produce a result, which either goes back
into a local data memory element or goes across the crossbar
to one of the remote processors.
So it's a very simple architecture conceptually.
And the key, of course, is the following.
The key is to avoid the bottleneck of event driven
simulation and to take a logic network
and actually compile onto this simple little structure.
Again, some of the key problems are really
in the software compilation.
These problems were addressed and solved
and we were able to meet the overall goals of logic
simulation that we started with.
The engineering verification engine as the slide says
has a peak rate of about 2 billion gates simulations
per second.
It is operational at several IBM locations.
Some of these machines have 256 processors, some have less,
the smallest one has 64 processors.
And this is possibly one of the earliest production
uses of a highly parallel processing element.
We have been using these EVEs for a few years
now in our development laboratories
to do logic simulation.
The second problem is different.
The second problem is a scientific problem
and it's the problem of quantum chromodynamics.
The theory of quantum chromodynamics deals
with the forces that exist inside the nucleus
at the quark, antiquark level.
So there's a chromoelectric field
that is hypothesized to exist, which
is very similar to the dynamic field that
exists between electrons and the nucleus.
The chromoelectric field exists inside the nucleus.
QCD gives you the transition probabilities
between quark and antiquark configurations
at various points in space and time.
From these transition probabilities,
from first principles one can compute the mass of the proton.
So the goal is to compute the mass of the proton, which
is a known quantity and to see whether the computation matches
what we know the mass of the product to be.
If it does, then we have a certain amount of confidence
that QCD is correct.
If it doesn't match, then we know that QCD is wrong.
Now, this is a structured and regular computation
but the physicists involved with this particular theory at IBM
estimates that 3 times 10 to the 17 operations
would be required to compute the mass of the proton.
On a machine that could sustain 100 flops
this would take 100 years.
And again, is quite impossible.
On the GF11 this problem can be solved in approximately one
year.
This is another somewhat dramatic example
of the use of parallel processing
to take an important problem and this is
an important scientific problem and bring it
into the realm of possibility.
A problem that for all practical purposes today is intractable.
The GF11 architecture is an ASMD architecture,
that is there's central control that broadcasts instructions
to 576 processors.
Now each of these processors is a fairly powerful machine
it's not a little microprocessor.
Each processor has the capability
of executing 20 mega flops, that is 20 million floating point
operations per second.
It can do I/O at the rate of 20 megabytes per second
and it has the capability also of doing 20 million fixed point
operations per second.
If you multiply all that by 576, you
end up with over 11 gigaflops--
over 11 billion fixed point operations
per second and a total bandwidth of 11 gigabytes per second.
Now it is not our claim that you can
get that level of performance on any arbitrary problem,
but we do believe that on QCD we can get up to 90% utilization
and therefore can sustain a computation
rate of 10 gigaflops per second, which would be required
to solve the QCD problem and compute
the mass of the proton in approximately one year.
The other important feature of this machine
is the interconnection network.
The interconnection network works as follows.
Before you start the problem, you
can select up to 1,000 of the factorial 576
possible permutations.
And then you can actually provide
each one of these permutations every 200 nanoseconds
at execution time.
Now QCD itself does not require that much generality
for the computations, yet this computation network
and the ability to have these various permutations
is important because you want to be able to separate
the physical interconnection of the processors from the way
they are used logically.
And this is important if you want
to be able to operate in the presence of processor failures.
And that is an important consideration
in this architecture.
I'm also using the word permutation somewhat loosely,
you can also provide broadcast every 200 nanoseconds.
And this is one of the features that
will make the GF11 actually suitable for a wider
variety of problems than just the QCD problem.
Let me now move on to the area of multipurpose parallel
processing.
As I said in my introductory section,
I believe this is a very important area,
but I also believe that there are many open questions that
remain to be answered.
We are slowly answering these questions but a lot of work
remains to be done.
How much parallelism is there in applications,
what is the granularity of this parallelism,
how should the parallelism be specified?
Should it be specified explicitly,
should it be implicit in the language,
should it be derived by compilers?
What are the appropriate resource management
and scheduling approaches?
From what class of problems do you need a global address space
for what kinds of problems will explicit message passing be
good?
What is the impact of communication latency
and bandwidth on performance.
And the bottom line really is what kind of performance
can you sustain across a wide range of applications
on a given architecture.
As a community we are making progress on these questions
but I believe a lot more work remains to be done.
Now two or three years ago the situation I believe
was as follows.
We as a technical community had done
a lot of analysis and simulation to start
understanding the answers to some of these questions.
But what was really required was a non-trivial prototypes,
on which we could run real applications
and perform real measurements.
Approximately four years ago, we started down
the path of building a set of prototypes in IBM
to start answering some of these important questions.
I will come to the RP3 program in a minute,
but before I get to that, let me mention that we also
have a message passing parallel processor at IBM
research called Victor.
A 32 node MIMD system has been operational
since the middle of 1987.
This is based on the mass transmuter
and is programmed using C Pascal Fortran outcome.
Victor was and it is a very quick and inexpensive approach
to putting together a parallel process very rapidly.
It has been shown to be exceedingly
good for a variety of applications
where there's a huge amount of parallelism.
Some of these applications are those
that use Monte Carlo methods, ray tracing and fractals.
We are currently implementing circuit simulation on Victor
and we'll use Victor as an experimental vehicle
to study the area of message passing.
A much bigger version of Victor will also
be operational fairly soon.
Moving on then to the RP3 program, our goal in 1984
was really two-fold.
One was to establish the feasibility of building
a multipurpose parallel processor out
of conventional microprocessors and the second
as I said was to provide a set of tools for research
on applications algorithms languages and architectures.
Here's a block diagram of the RP3 machine.
In its initial formulation RP3 was a 512 way parallel
processor and we have actually implemented 1/8 of this 64
processor version of RP3.
Let me just very quickly go through some
of the key attributes of this machine.
First of all, we were really after a very, very powerful
network and the network is built out of the highest performance
bipolar technology and package that was available to us
in that time frame.
The network was also initially the 512 way
and was supposed to have combining basically
lets you access a global memory location that
is end processors can access a global memory
location essentially in constant time for a given machine
and not an order of end-time as would
be the case without combining.
We did not feel that combining was necessary
as part of the 64-way machine and so combining
was not implemented in this version.
So the first important characteristic of RP3
was the switch.
The second important characteristic
was the overall approach to managing caches and managing
memories.
So, cache management was done under software control
hardware mechanisms were not provided,
but essentially data could be tagged as being
cachable or non-cachable.
The memory system was unique in the following sense
even though, the whole machine has a global address space,
this address space can be broken up
into a local address space and a global address space.
And the amount of local and global
can be changed dynamically at runtime
on the program controlled.
So the two extremes of this would
be to have all the memory configured
as part of the global address space in which case,
it becomes a true shared memory machine.
The other extreme would be to configure the address
space as pieces of local address space
only without any shared address space and in that case,
the machine becomes similar to a message passing machine.
So part of the motivation for doing repeat three
was to build a machine that was a flexible tool for studying
various classes of architectures.
A third important feature of RP3 was very extensive
built in monitoring capabilities.
These monitoring capabilities allow us to measure things
like the ratio of local to global memory access, the cache
ratios, instruction frequencies, delays
caused due to network access and so on.
There's a processor as part of every one of these--
there's a chip which is part of each processing element
that gathers this data while the machine is executing.
So these were some of the important features of the RP3
program.
We also felt initially that it was
important to get a level of performance high enough to make
the machine interesting.
And the initial levels of performance
were to get roughly a billion instructions per second
by the use of 512 processors.
In addition to the hardware there
was a fairly extensive undertaking
in terms of developing software and to develop
software tools that would allow us
to experiment with parallelism.
One of these tools as we VM/EPEX, which
allows experiments with parallelism on a 370
multiprocessor as opposed to the RP3.
It was developed to allow us to do
the necessary work and languages and applications
while RP3 was being developed.
As a side effect this piece of software
also provides real speed up on a 370 multiprocessor.
And this is been operational at several sites.
Together with VM/EPEX we've also developed several tools
which allow us to do post-mortem analysis of applications
that are run under VM/EPEX in a parallel way.
So what you can do is you can take an application,
you can run it under VM/EPEX, you
can gather trace information about the execution,
and then you can run that trace information
through various simulators and schedulers
to try to understand what the effect of the switch would be,
and to try to understand what efficiency you would get out
of an RP3 like machine.
This particular slide is not important
but it shows the kind of information
or one example of the kind of information one
can get out of VM/EPEX and these various tools that I described.
To summarize then, I said earlier
that we had two overriding goals for the RP3 project.
One was to construct a multipurpose parallel
processor.
And the features that make RP3 multi-purpose
are listed on the slide.
It uses a general-purpose microprocessor,
it's an MIMD structure, it has a very low latency,
high bandwidth, self-loading network,
and it provides for flexible local and global addressing
mechanisms together with a fairly general I/O subsystem
that I didn't talk about.
What makes RP3 an experimental facility?
The system monitoring facilities is the fact
that it uses standard operating systems,
it has a UNIX based operating system that
uses conventional programming languages,
and we have a fairly extensive suite of application
development and analysis tools.
The RP3 also has adequate system reliability
to serve as an experimental facility.
And I'd like to make two points.
One is that this whole area is extremely
important to our industry.
If I were to net it out I see two very important trends.
One is the area of mainframe parallelism.
Here we will construct the highest performance
uniprocessors and we will use parallelism
to get performance levels beyond that possible
with a uniprocessor.
To a large extent, this will rely
on advances in technology and packaging
and that's where the risk will be.
To a large extent mainframe parallelism
will use evolutionary software.
The other very important trend is the whole area
of microprocessor-based parallelism, where
we will use commodity parts and higher degrees of parallelism.
And the key issue here will be advances in software
that will be required to make these efficient use
of these higher degrees of federalism.
The second sort of summary comment I would like to make
is that parallel processing is important today.
It's starting to be used.
And I believe that this technology will be
very pervasive in the future.
This is one of the key systems issues that we have to address
and we have to solve all the way from workstations
to supercomputers.
I would also like to leave you with the thought
that we are actively pursuing in IBM
several different systems approaches.
I've tried to identify and briefly explain
most of these to you.
And some of these are being pursued as products
and some of them are in research.
That brings me to the end of my talk
and I will now take questions.
And the first question from Gordon Bell at Arden computer.
Why did the GR11 and RP3 parallel machines
take so long to develop, and what did you learn?
I think the basic reason why we have spent more time
than we initially anticipated on board these machines is
that they are both in their own way very complex,
large systems.
In neither case did we really exploit the CMOS building block
replicated to produce a very high performance machine.
The RP3 became complex for a variety of reasons.
There was a significant amount of basic logic design
that we ended up having to do.
A lot of this was in the cache and memory system.
We also ended up using multiple technologies and multiple power
supplies all of which contributed
to the overall complexity of the machine.
In the case of GF11 also we didn't use a standard building
block.
We ended up building our own uniprocessors that
were fairly significant in their complexity
and we ended up building a fairly complex interconnection
network.
For myself Gerald Maguire at Columbia University.
For such calculations as used in QCD, for computations
run for a long period of time, what
is the reliability of the machine, what about the problem
of detecting faults?
That's a very good question.
As you probably know the GF11--
that the QCD competition is basically
a fairly stable competition and it's a Monte Carlo computation.
In fact, the physicist on the project
has always had the view that if you randomly lost a bit once
and away, once in a meaning let's say once
every day or every several hours,
it wouldn't in fact significantly affect
the competition.
That's point 1.
Point 2 is that the GF11 is designed
so that you can do a dump of the entire memory state
of the system very rapidly.
So you can dump the entire state in approximately 12 seconds.
And therefore one could very frequently
checkpoint the system.
So I think basically the way one will end up
doing the QCD computation is either
to do every computation twice and compare the answers,
or to split the machine into two pieces and run the problem
and compare processor by processor of the results.
That's how you get your basic error detection.
And with that, you would do two things.
You would look at the errors and you
would see if they were truly just random errors
or there was some pattern.
If there was a pattern there would be a problem.
Secondly, you could always back up
and restart the computation because of this check
pointing capability.
So I think we'll end up running GF11 and its architecture
to do that basically split the machine into
and run the identical computation on both sides
and compare the results of processors.