MINUTES OF BCS FORTRAN SPECIALIST GROUP MEETING HELD AT BCS HQ, 13 MANSFIELD STREET,
LONDON ON 25 JULY 1986
Present: Mick Carter - UK Met Office
F E Cox - Swifte Computer Systems Ltd
Miles Ellis - Oxford University
W Flexner - Retired
Mike Geary - NAG
Ross de Havilland - CDC
Carol Hewlett - LSE
Peter Holland - SS(E)L
Chris Lazou - ULCC
Clive Massey - SWURCC
George Mozdzynski - CDC
David Muxworthy - Edinburgh University
Keith Normington - Coventry Polytechnic
Mike Nunn - CCTA
T L van Raalte - MOD
John Reid - Harwell
Angela Smith - UK Met Office
J Stratford - QMC CC
Alison Wearing - NCC
Tony Webster - Salford University
Paul White - UK Met Office
John Wilson - Leicester University
John Young - MOD (PE)
Addresses:
Chairman: John Wilson
Computer Centre
University of Leicester
LEICESTER LE1 7RH
Tel: 0533 554455 ext 9137
Vice-Chairman: Keith Normington
Computer Centre
Coventry (Lanchester) Polytechnic
COVENTRY CV1 5FB
Secretary: Mike Nunn
CCTA
Riverwalk House
157/161 Millbank
LONDON SWlP 4RT
Treasurer: John Dyke
Huntingdon Research Centre
HUNTINGDON PEl8 6ES
1. APOLOGIES FOR ABSENCE
Apologies were received from Lawrie Schonfelder (Liverpool University).
2. MINUTES OF PREVIOUS MEETING [17 March 1986]
2.1. Paragraph 6.2 "depreciated" should be "deprecated".
2.2. The Chairman expressed his thanks to the Vice-chairman for taking the
chair in his absence at several recent meetings and to the Secretary for the
comprehensiveness of the newsletters.
3. MATTERS ARISING
3.1. The Secretary was drafting a membership application form for newcomers,
to the Group. It would also be used to collect annual dues (currently £5) from
non-BCS members.
3.2. The Group would need to consider framing a request from BCS for an
increased budget. The Chairman would discuss this with the Treasurer.
3.3. The Secretary explained that the intended visit to European Weather Centre
(originally expected for June) had had to be put back to 16 October to fit in
with availability of accommodation and personnel there. The meeting scheduled
for Coventry Polytechnic would now take place in December and was hoped to
include talks on Toolpack, Fortran - C conversion and a NCC demonstration
workshop.
3.4. On 30 July there was to be an "open" meeting of the BSI panel at which
people were welcome to put forward their views on the draft proposed for "8X".
There would then be a BSI feedback based on the tenor of this into the next
X3J3 meeting at Halifax, Nova Scotia from August 25-29. X3J3 welcomed views
from the BCS Fortran Group and also from individuals. The BSI meeting was taking
place at BSI HQ, 61 Green Street with David Muxworthy (Edinburgh University) as
convenor.
3.5. A letter had been received from BCS HQ advising on possible financial
sponsorship for supported activities and guidelines on how they could be used.
3.6. BCS Specialist Groups Board had undergone a metamorphosis. There would
now be a Specialist Group Management Committee reporting to a Technical Board.
The minutes of the latter were circulated to our Chairman.
3.7. Documents recently received included:-
Draft for industrial real-time Fortran;
Definition of GKS binding.
3.8. A new Specialist group had just been set up. "PARALLEL PROCESSING
SPECIALIST GROUP". [Its activities are described in Appendix A]. The
Fortran Group would add the new Group to our newsletter list. Several of our
members, including John Reid, would be active in the Parallel Processing Group.
Its next meeting would be on 25 September at Imperial College consisting of an
all day Seminar "Languages for ParallelProcessing" chaired by Prof. Perrett
(Queens University, Belfast).
3.9. The 10th IFIP world computer congress would be held in Dublin from
1-5 September 1986.
4. PROGRESS AT X3J3 ON FORTRAN 8X
4.1. John Reid (Harwell), a regular UK member of X3J3, summarised the main
happenings of the recent June meeting in New York. It was very important in that
a compromise was needed in order to get the necessary 2/3 vote in favour before
the draft "8X" document could be released for public comment. At the previous
meetings the main areas of contention were:-
(i) the size of the language; and
(ii) deprecated features.
Walt Brainerd, who missed the meeting previous to New York, was very much against
the new idea of only removing things about 20 years ahead, which he regarded as
not meaningful in terms of progress.
4.2. John Reid asked for peoples' views on the new "8X" philosophy. Opinions
expressed:-
Keith Normington - it is difficult to understand or remember the nuance
of the difference between deprecated and obsolescent
features.
Carol Hewlett - presumably IBM's objections to the size of the
language were because they would have to go on
offering previous compilers as well as "8X" otherwise
if they took things out previous programs would no
longer work.
4.3. The X3J3 chairman wanted two more editorial meetings and asked whether
New York attendees would then vote "Yes" for releasing "8X" draft for public
comment once these editorial changes alone had been made. On a vote there were
only 4 "Nos" to this.
Walt Brainerd will produce a new typeset "8X" draft document for the coming
Nova Scotia meeting. Soon after "8X" goes out for public comment - probably
late 1986 or early 1987 - the BCS Fortran Group will organise another "Fortran
Forum" at which it can be presented by X3J3 members and commented on by
attendees.
4.4 In New York X3J3 members were asked which features they felt very strongly
about and would therefore determine whether they would vote "Yes" or "No" for
public release. The intention was to have an appendix to define certain features
with explanations that X3J3 had looked at these but decided not to include them.
This appendix would be included in the public comment document for sure but might
also be included in the final "8X" Standard document as well. Most of the members
of our Group tended to feel it was OK for the public comment draft to have an
appendix of "candidate" features which had eventually been left out but thought
it inappropriate to put this into a Standard document as well.
4.5. Possible future timescales (if the next two X3J3 meetings go OK):-
A 1 year public comment period;
"8X" just possible to appear in 1988 (but more likely 1989).
4.6. A glossary of technical terms relating to "8X" will be distributed with
the draft for public comment. [This is reference "S11"].
4.7. General views on the "8X" draft release:-
Miles Ellis - "8X" was overdue already and it was important to get
the draft out for public comment as soon as possible.
Keith Normington - X3J3 was to be congratulated on putting out the draft
with an appendix of considered but rejected features
as an "Aunt Sally" because it would allow them to be
replaced if the consensus of opinion was in favour.
(However Miles Ellis thought such an appendix would
encourage people to say "put them back" with few
saying "leave them out").
John Reid - thought IBM will vote "No" and DEC will be willing to
compromise.
- CRAY put forward the compromise; they themselves are
not attracted to having to introduce a large number
of new things into their compilers all at once.
David Muxworthy - one could not take IBM's objections seriously; they
just did not want to have to write new compilers.
4.8. John Reid has as usual kindly provided a detailed report on the New York
meeting - see Appendix B.
5. ANY OTHER BUSINESS
5.1. David Muxworthy asked about other peoples' experiences with installing
and using Toolpack. Keith Normington said the accompanying documentation had
been found inadequate at his own Polytechnic and they had therefore developed
his own which he was willing to give a copy of to anyone interested. Apparently,
NAG accepted the documentation was less than perfect. John Reid had found it
very frustrating trying to put Toolpack up on an IBM system. The trouble was
one needed to read a 90 page document and go through a pre-processor before
even starting. Chris Lazou, who had installed it on ULCC Amdahl under MVS,
offered to help.
6. THE NEW ETA 10 SUPERCOMPUTER
In the afternoon George Mozdzynski (Control Data Ltd) gave a talk on the new ETA 10
Supercomputer. A detailed summary appears in appendix C.
7. DATE OF NEXT MEETING
The next meeting will take place from 11.00 am to 4.00 pm on 16 October at European
Weather Centre. Details are with attached agenda. All those wishing to attend must
return the enclosed booking form to the Secretary by 29 September.
MIKE NUNN
Secretary
29 August 1986
PARALLEL PROCESSING SPECIALIST GROUP
A new specialist group is being formed within the British Computer
Society, on Parallel Processing. Our objectives are to promote
the development of parallel architectures, languages and
applications in the U.K.; to act as a focal point for the
dissemination of information about Parallel Processing and to
further commercial benefit to the U.K. for home-based research in
Parallel Processing.
The group will be hosting evening and one-day meetings in its
first year. We are planning at present a one-day review of
commercially available Parallel Processors in the early summer and
a one-day meeting on languages for Parallel Processing in the
early autumn. There will also be a series of early evening talks,
probably initially based in London.
We will be publishing_ an annual Directory of Members and
occasional newsletters. We are also seeking to establish a
central repository for technical material relating to Parallel
Processing.
Membership is open to all interested parties, membership of the
BCS is not a prerequisite. Student members are also invited at a
reduced rate.
Application Forms are available from the Secretary,
Dr. Nigel D. Tucker
Paradis Consultants
East Berriow
Berriow Bridge,
North Hill,
Nr. Launceston,
Cornwall, PLl5 7NL
To: BCS, NAG, etc.
From: John Reid
Date: 21 June 1986
Subject: Report on X3J3 meeting at Mount Kisco, New York
Note: This is a personal report of the meeting and in no sense
does it constitute an official record of it.
References: [1] 100(*)KH-1 Deprecated features proposal
[2] 100(*)WSB-2 The Decline of Western Civilization
[3] 100.JLW-2 Fortran 8x/99
[4] 100(l3)JKR-2 S8 Glossary of technical terms
[5] 100(l9)JKR-3 Taming REAL(*,*).
1. Summary
This was a critical meeting. There was a real possibility of
reaching deadlock on the overall content of Fortran 8x, with more than
a third of the members unwilling to vote the standard out for public
comment either because it was too large or because too many wanted
features had been removed. Also the near-unanimity at the April
meeting in Scranton on the changes to the deprecated features had been
lost. However, the changes to the deprecated features were passed
(see section 2) and a proposal on reducing the size of the language
(see section 4) was accepted after some significant changes. A first
cut at the set of changes needed to the document was accepted and it
is the Chairman's aim that two more meetings (in August and November)
devoted to editorial changes will produce a document that at least
two-thirds of the committee accept for release for public comment.
When asked how they expected to vote in November, 22 members said
'yes' and 4 said 'no'. It will be tough to get the document into
shape by then, but at least the committee appears to have avoided the
possibility of deadlock on the technical content.
Other actions taken during the week included minor editorial
changes, resolution of the REAL(*,*) problem (see section 5),
discussion of storage mapping (see section 3), discussion of data
initialization (see section 6), adoption of a glossary (see section 7)
and adoption of some changes in the i/o area (see section 8). The
committee was addressed by two Fortran 77 compiler writers, Tom Lahey
and Stu Feldman, both of whom argued for a reduction in the size of
the language. Tom was critical of the quality of the current
document, did not like so many intrinsics being accessible at compile
time, and wanted hooks to other languages. Stu was critical of
dependent compilation and wanted the underlying model to be explained
explicitly.
2. Obsolete, obsolescent, and deprecated features
The committee adopted (l7-11) a formal proposal [1] to split the
deprecated features into two categories. Those to be called
'obsolescent' have replacements in Fortran 77 and may be removed from
Fortran 9y if their use has become insignificant. The rest continue
to be called 'deprecated' and may be moved to the obsolescent list in
Fortran 9y for possible removal from Fortran 102. At the April
meeting in Scranton, the change was regarded as satisfactory by all
members except one. However, Walt Brainerd, who was not at Scranton,
meanwhile made a strong plea [2] for leaving the deprecated features
alone. He wants to permit a faster evolution of the language. A few
of the members that were at Scranton changed their votes and a few not
at Scranton voted against it with Walt Brainerd, which is why it did
not achieve the near-unanimity that it had at Scranton. Later in the
week, the committee considered dropping the idea of obsolescence and
deprecation altogether or keeping only obsolescence. It rejected both
changes overwhelmingly (4-18-2, l-20-4). I would have been very
unhappy with either of these changes because I think we need an
evolutionary path.
Later it was decided to add an empty list of 'obsolete' features
to be removed from Fortran 77 and to modify the obsolescent list to
the following: arithmetic IF, real and double precision DO control
variables, loop termination other than on a CONTINUE or END DO
statement, terminating more than one DO loop on a single statement,
branching to an END IF statement from outside its IF block, alternate
RETURN, PAUSE, and ASSIGN and assigned GOTO. The last three are
additions to the tentative list established at Scranton.
3. Storage association
For several years the committee has been working with the
assumption that COMON, EQUIVALENCE, and all forms of storage
association are deprecated because of the portability problems they
bring. This assumption was challenged during the discussions at
Scranton and Mike Metcalf was asked to look into alternatives for the
bit-mapping capabilities of storage association. The committee
preferred the idea of adding some bit-mapping intrinsics (possibly
subroutines), but snags were found in Mike's proposal. He will bring
a fresh one to the next meeting. A formal vote on removing storage
association from the deprecated list failed (11-l5).
4. Size of the language
A major attempt was made at Scranton to find a compromise
position on the contents of Fortran 8x that all or most of the
committee could accept. This was summarized in my last trip report
and in a paper [3] written by Jerry Wagener. Some major variations
were explored early in the Mount Kisco meeting, but the proposal that
was eventually accepted (25-4) was a relatively minor variation. The
changes were the following:
(1) Not to move to the appendix:
(a) user-defined operators
(b) array constructors
(c) RANGE.
(2) To move to the appendix
(a) BIT type
(b) variant structures.
(3) Not to add pointers to the appendix.
(4) To reduce storage mapping to a bit-transfer capability.
(5) To unify IDENTIFY with RANGE.
(6) Not to separate the two forms of DO.
There was some sentiment for the appendix becoming an addendum
to the draft standard, but removed from the final version. This would
mean that the features in the appendix were quite clearly not a part
of the standard. It would also mean that they were less visible to
implementors designing extensions. The committee chose to stay with a
conventional appendix (l4-8-7).
Keeping user-defined operators but not operator overloading
represents a compromise that I am willing to accept. We have, after
all, lived a long time spelling '<' as '.LT.'. One or two members
were concerned at the lack of safety involved in operator overloading
- the user may not get the result that he or she expects. I was also
happy to see pointers not being included in the appendix, because they
would represent a major addition that would substantially delay the
release of the draft for public comment.
There was concern about the loss of facilities for skew arrays,
and I believe that item (5) was intended to address this loss. George
Paul presented some ideas, but they seemed to offer little
simplification over the present form of IDENTIFY and exposed differing
views on what item (5) implies. In a private discussion after the
meeting, George Paul, Alan Wilson, and I explored the removal of all
alias and many-to-one properties from the IDENTIFY statement. This
idea looks hopeful, but has no official status.
I was pleased to see the abandonment of the separation of the
two forms of DO. The problems have more to do with the formal
description of the facility than any genuine difficulties.
The proposal passed involves the following:
1. Move to appendix:
(a) treating arrays of arrays as higher-rank arrays
(b) CONDITION and ENABLE
(c) operator overloading
(d) structure constructors
(e) the intrinsic functions DIAGONAL, RANK, REPLICATE,
PROJECT, FIRSTLOC, and LASTLOC
(f) nesting internal procedures
(g) passing internal procedures as actual arguments
(h) FORALL
(i) IDENTIFY/ALIAS
(j) vector-valued subscripts
(k) variant structures
(l) BIT type
2. Simplify internal procedures, modules, and USE.
3. Add bit-transfer capability.
4. Remove significant blanks and insignificant underscores.
5. Replace name-directed i/o with NAMELIST.
6. Unify IDENTIFY with RANGE.
5. Real(*, *) combinatorial explosion
My proposal [5] to limit the number of versions of a procedure
having dummy arguments with passed-on precision to the number of
native precisions on the computer was accepted (23-1). It limits the
number of such arguments to one and allows others to have their
precisions linked to it. It was criticized for the clumsy notation as
exemplified by
.....
REAL(6) A(100)
REAL(EFFECTIVE_PRECISION(A)) B(lOO),C
CALL DOT(A,B,C)
.....
SUBROUTINE DOT(A,B,C)
REAL(*) A(:)
REAL(EFFECTIVE_PRECISION(A)) B(:),C
If the calling procedure is changed so that B and C are declared with
precision 6, the program will conform to the standard only on
processors having a representation with effective precision 6. Some
people felt that the argument conformance rules should be relaxed to
require conformance only of effective precision, but then conformance
would still sometimes be processor dependent. Carl Burch is looking
at the problem.
6. Data initialisation
Ivor Philips suggested several possible simplifications or
combinations of the INITIAL attribute and the DATA and INITIALIZE
statements. The committee favoured spelling them all DATA and
extending the INITIALIZE statement to include the implied DO construct
applied to arrays and array sections.
7. Glossary of technical terms
I proposed a glossary [4] of technical terms for an appendix to
the draft standard. It was welcomed, apart from a few terms whose
meaning altered with the change to the meaning of deprecation.
Several people were concerned about possible inconsistencies between
it and the main text, so it was agreed that the glossary should be a
new standing document (S11) rather than an appendix. It was adopted
(20-1), and I was asked to revise it to reflect proposals passed at
the meeting.
We also had a discussion about some terms that are currently
used with inconsistent meanings in different parts of S8. We agreed
that 'array' is a generic term that includes, for example, array
sections; and that 'constant' is a generic term that includes literal
and symbolic constants; we decided to use 'named' in place of
'symbolic' and to use 'designator' for a string representing an array
section.
Earlier in the week it was agreed (l9-2-6) that the
simplifications to modules and internal procedures lead to our having
three kinds of procedures: an internal procedure is one whose
definition lies inside another procedure, a module procedure is one
directly hosted by a module, and an external procedure is one that is
not contained in a module or another procedure.
8. Changes in i/o area
Lloyd Campbell voted 'no' in his ballot because the default for
a formatted read that goes beyond the end of a record is not to pad
with blanks, but to regard this as an error. Many existing
implementations automatically pad with blanks. In Fortran 8x, this
effect can be obtained with the specifier PAD='YES', but it is not the
default. A proposal to remove the PAD= specifier and always pad with
blanks failed(11-12). Several people felt that it should be possible
to run in a mode that regards this situation as erroneous. The
proposal to change the default to PAD='YES' passed (16-5).
In response to requests from the ISO group in Bonn, Carl Burch
proposed adding the RECL= specifier to OPEN and INQUIRE statements for
sequential files, to return the maximal record length that can be read
from or written to the file. This passed (l7-0). Unfortunately it
does not address the problem that I believe the Bonn people had in
mind, which is to provide a facility to find out how long the next
record is. Carl has a simple proposal for this, which he intends to
bring to the committee.
9. Next_meeting_of X3J3
The next meeting will be in Halifax, Nova Scotia, Canada,
August 25-29. The premeeting distribution deadline is July 21.
THE NEW ETA SUPERCOMPUTER - Talk by George Mozdzynski (Control Data Ltd)
History
ETA Systems is a company set up by CDC in 1983 with an objective to design and
develop the fastest and most reliable supercomputer in the world. Located in
St Paul (twin city of Minneapolis) ETA Systems can be regarded asa separate company
from CDC in some respects although CDC owns 89% of the share equity. The ETA 10
supercomputer that has been developed is marketed by ETA Systems in the USA but by
Control Data Ltd in the UK.
Objectives
A good definition of a supercomputer would be a computer that is one of the very
fastest at any point in time. ETA Systems was set up with the strict goal of developing
the fastest machine of all and that it must be available in the field within three
years. That objective has been achieved with the machine now operational and the first
delivery soon to take place.
Progress
Three customers have already signed contracts to buy the ETA 10. The first system
comprising a 4-processor model will be delivered soon to Florida State University.
ETA 10 is a multi-processor computer incorporating up to 8 cpus. The first three
systems delivered will be 4, 4 and 8 processor configurations. The first prototype
code name Cygnet (with 1 cpu) was turned on at the ETA laboratory in St Paul on
29 May. It only took 5 days to run diagnostics, a vast improvement compared with the
Cyber 205 where 9 months were needed to complete diagnostic runs. The speed-up is
due to the technology employed. The operating system is being checked out over the
period July-September 1986 and at the same time the Florida State machine is being
built. It should be delivered in November or December.
Future
ETA 10 design target was originally for a 7 nsec clock cycle time. This has not yet
been achieved because of problems with getting sufficient yield of chips of the
right quality. So the initial machine will be delivered with a 10.5 nsec clock.
But by July 1987, ETA Systems expect to have a 7 nsec clock machine available. By
extending the same technology clockspeed will be down to 5 nsec in 1988 and larger
memories will also be available.
Packaging/Environment
The cpu is just 22" x 16" comprised of a single printed circuit board with 240 chips.
This is interesting to compare with the Cyber 205 which, although offering processing
power of only one third of one ETA processor, occupies space the size of a medium
size room. Shared memory between the ETA processors is comprised of 256 K chips with
a 1 megaword memory module occupying just a 4 inch cube. ETA 10 can run at normal air
temperature, but runs twice as fast at -194°C using liquid nitrogen cooling. It is
the first system to use this type of cooling.
Configuration
A system can comprise between 1-8 cpus, all having both a scalar and 2-pipeline vector
processor. Each cpu has its own 4 million 64-bit words of memory. There is also
between 32 and 256 million words of shared memory between the cpus. A system supports
between 2 and 18 I/O units - so in theory one could have up to 1,000 disk drives
attached. Magnetic tapes and networking are also supported.
Benchmark Performance
Using Argonne Laboratory's Linpack benchmark a single processor ETA 10 has been
measured using a simulator at 195 megaflops. (Peak performance of a single
processor ETA 10 is 570 megaflops). A CDC benchmark showed it as 3.5 x the power
of a Cyber 205. By comparison with rival supercomputers ETA 10 and Cyber 205 have
the advantage that they can use both 32 and 64-bit arithmetic.
Software
ETA 10 will operate under either VSOS (the Cyber 205 operating environment) or Unix
(AT&T System V.2). Programming languages supported are Fortran, C and Pascal. A
multi-tasking library is provided to allow user applications to make use of the
multi-processor facility in an ETA 10 configuration.
Supercomputer Performance Issues
Delays in logic circuits can be due to:-
(i) gate delays - a function of the material and depend on the speed
of electrons through it;
(ii) propagation delays - depend on distance and signal propagation speed.
ETA Systems decided to use CMOS rather than Ga As because it allows thousands of
devices on a single chip whereas Ga As only permits a hundred or so. And if you cannot
get enough logic onto one chip you inevitably encounter communication delay in
connecting to other chips. [Relative delay times would be chipl , PC board 10,
coax 30]. By 1990 CMOS technology will have advanced to 100 k gates/chip so it will be
possible to build a cpu with just 40 chips.
Ga As is in fact of two types:-
"depletion mode"; and
"high energy molecular technology" (HEMT).
The latter will be available in the 1990s. HEMT more resembles CMOS than depletion
mode, eg it offers the same number of gates per chip. ETA Systems has the choice in
the future of moving to Ga As or staying with CMOS.
ETA 10 Technology
The cpu comprises a single 42-layer printed circuit board containing 250 CMOS chips
each with approximately 20,000 logic gates. Each chip has self-test diagnostics,
which accounts for how ETA Systems could check out the whole machine in 5 days. Each
chip has about 280 pins.
The cpu is immersed in liquid nitrogen at -194°C. As the liquid warms it turns to
gas and is fed round the cryogenic unit. Power used by the cpu is only 700 watts
(about 20-30 times less than the Cyber 205). The machine can plug into a normal
wall socket. The cryogenic generator however needs quite a lot of power so that total
system requirement is 160 KVA (but still only 25% of the Cyber 205).
Cpu memory is 4M word of 64 K static MOS RAM. Memory addressing logic supports
64 M words ( 64 M word cpu memory will be available by 1988). Shared memory between
the cpus consists of between 64-256 words of dynamic MOS RAM. Bandwidth between cpus
and shared memory is very high (9.1 G bits/sec). Instruction set is compatible with
Cyber 205 but includes extra ones as well.
A system can support up to 18 I/O units which enable attachment of disks, magnetic
tape units and networks. Between the I/O units and shared memory transfer rates can
be sustained at UUOM bits/sec. Device capacity for each physical disk is 600 M bytes
or 1.25 G bytes. Burst transfer rates are 12 M bytes/sec and sustained transfer rates
10 M bytes/sec. All data communication between processors is via shared memory and
processor can also share information via a communication buffer. Shared memory serves
the purpose of both acting like a CRAY solid state device (SSD) and as a paging device.
Each cpu has one scalar and a 2-pipeline vector processor. This combination was
chosen because, unlike a 1 scalar/4-pipeline mix, it could be implemented on a single
board and also offered a better balance. Both 32-bit and 64-bit arithmetic working
is possible. Each user can view the ETA 10 hierarchical memory as one large virtual
address space.
Flexible scheduling options allow the multiple processors of the ETA 10 to be either
applied in parallel to provide high performance to a single application process or
to be applied individually to sets of jobs and so provide high system throughput.
Networking
The ETA 10 offers two types of networking:-
(i) LCN - existing CDC network with bandwidth up to 50 M bits/sec;
- consists of a variety of network access devices (NADs)
interconnected by coax using proprietary transmission
mechanisms and protocols, eg allows connection to IBM and DEC;
(ii) TCP/IP - Ethernet trunks (IEEE 802.3 based) each supporting 256
terminals;
- TCP/IP is the DOD protocol allowing connection of variety
of devices to Ethernet and ETA 10;
- allows direct connection of terminals to ETA 10 (a big
advance compared with Cyber 205).
Software - Operating System Environment
Two operating systems are available:-
(i) UNIX - AT&T System V.2 with Berkeley extensions;
(ii) VSOS - offering compatibility with existing Cyber 205 sites.
ETA Systems believe that most interactive access will be via Unix. They are also
looking at offering a NOS/VE environment as well.
Fortran
Two Fortran implementations are offered:-
(i) FTN 200 - this is Cyber 205 F77 and is offered for compatibility;
- automatic vectorising could be better;
(ii) Peritus International are developing the ETA Fortran compiler. It will
be the first one able to vectorise all the Livermore loops. Array
extensions anticipated for "Fortran 8X" have been built in. Other
features incorporated are Cyber 205 vector notation and common vendor
extensions, eg IBM type declarations. ETA Systems believes the compiler
also offers good scalar optimisation. Pacific Sierra are developing an
automatic Fortran vectoriser for ETA 10 based on their VAST product.
Initially automatic vectorisation will be achieved (as VAST does at
present) by running a program through the compiler via a batch-type
interface. But fairly soon there will be an interactive vectoriser which
will prompt the user on paths and vectorisable constructs associated with
achieving high optimisation. Other goodies offered will be a symbolic
debugger and post-mortem dump with traceback (not available on Cyber 205).
Multi-Tasking
ETA Systems strategy for multi-tasking is via calls inserted by the user into his
Fortran source code. Although some automatic partitioning ("microtasking") is available
it is more difficult to achieve speed up at multi-tasking comparable with that achieved
by vectorisation. In fact as Fortran is not a language suited to multi-tasking ETA
Systems is interested in providing an outer layer on top of Fortran to provide this. A
multi-processor interactive debugger will be offered. The multi-tasking library
allows a program to be written in any language eg C, Pascal and use this library.
Performance
A simulator for multi-processing the ETA 10 which runs on the Cyber 205 has produced
the following results:-
Application Number of ETA 10 Speed up
Processors in Compared with
Configuration Single ETA 10 Processor
Matrix multiplication 2 2.0
(1000 x 1000) 4 3.9
6 5.9
8 7.8
Matrix transpose 8 7.0
(4000 x 4000)
Gaussian elimination 4 3.2
[NB: Overheads of multi-tasking have been included in the simulator].
Pricing
Two series of machines are to be announced:-
1. 'E' Series (with 10.5 nsec clock)
Performance 0.8-3.2 G flops
Cpus 1-4
Shared memory 32-128 M words
Pricing £3.6 M - £8 M
The first three systems delivered to the Universities of Florida State,
Minnesota and Pittsburgh will be 'E' Series.
2. 'G' Series (with 7 nsec clock)
Performance 4.6-9.2 G flops
Cpus 4-8
Shared memory 128-256 M words
Pricing £8.6 M - £14.6 M
'G' Series machines are scheduled to be available in July 1987.
Logic chips being developed by Honeywell for ETA 10 are valued at $2,600 so a single
cpu contains chips worth $0.5 M.
Serviceability/System Redundancy
ETA 10 was designed to offer full redundancy so that if any part fails the system
will still operate. MTBF for an individual cpu should be about 1 year. It will be
possible to replace a cpu within 3 hours even though the liquid nitrogen coolant
needs to be cycled up and down from its 77°K operational temperature to allow the
replacement to take place. It should be noted that liquid nitrogen is a far more
reliable medium than air.
Competition
George Mozdzynski says that main competition is likely to come from CRAY but that the
ETA 10 outperforms both CRAY X-MP and CRAY 2 and also offers at least a 2:1 price
performance advantage in comparison with them. One could only guess at performance,
price, timescales etc of CRAY Y-MP (1987?) and CRAY 3 (1988?).
Summary
Key benefits of ETA 10 are:-
1. Better price/performance than today's competition.
2. Reliability because of - built in redundancy;
- environment cpu runs in;
- high density 20 K gate chips with few
connections [connections are trouble];
- MTBF for cpu of 1 year.
3. Can operate with or without front-end system.
4. Upgradeability - easy to add in further opus to configuration
(and without even needing to bring system down).
5. Maintenance - very little preventative maintenance needed and not
necessary to have engineer on site.
6. Enhancement - compatible successor products will be offered using
technology such as HEMT.