BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP
MINUTES OF MEETING HELD AT BCS HQ ON 26 OCTOBER 1983 [actually September]
Present: S G Brazier - United Glass
Chris Burse - ULCC
P C Chapman - Retired
Stephen Evans - London Hospital Medical College
Bill Flexner - Retired
D P Fordned - BBC
C Hall - NPL
Chris Lazou - ULCC
David Lomas - UMST
D J Holmes - Rolls Royce Ltd, Bristol
Mike Metcalf - CERN
A Mason - ULCC
K Normington - Coventry Polytechnic
Mike Nunn - CCTA
T L van Raalte - MQD
J Roberts Jones - Liverpool City Council
Nick Saville - Private Consultant
J L Schonfelder - University of Liverpool
Alan Wilson - ICL
John Wilson - Leicester University
Address: Chairman - John Wilson
Computer Laboratory
University of Leicester
Leicester LE1 7RH
Secretary - Mike Nunn
CCTA
Riverwalk House
157 Millbank
London SW1P 5RT
Treasurer - T L van Raalte
Atomic Weapons Research Establishment
Aldermaston
Reading
APOLOGIES FOR ABSENCE
Apologies were received from Dave Vallance (Salford University).
1. Minutes of Previous Meeting [6 June 1983]
Correction of last paragraph of "Treasurer's Report" on p3:
"idea forum" should read "ideal forum"
2. Matters Arising
(i) "British Standard Fortran"
An OSI/5 sub-committee has been set up to work on the BSI Fortran proposal
called "Standard Method for Specifying FORTRAN Language Processors". Its
membership comprises:
D Muxworthy
B Meek
J Wilson
I Hill
with T Clarke and T Addyman as correspondent members.
They are working on a draft which will be issued for comment. Bill Flexner said
he would like to hear examples of how this proposal worked as compared with the
Standard itself, eg could he be shown concretely how it would improve Standard?
John Wilson said that in any area of the Standard. where there could be problems
with portability, implementors would need to either declare their interpretation
or give the user various options. To what extent the new BSI proposal document
could define all such situations was still under discussion. As soon as it was
satisfactorily drafted it would be brought to the attention of X3J3.
Lawrie Schonfelder wanted to make two general comments viz (i) there were loose
areas in the Standard because competing manufacturers represented on X3J3 did
not want a stricter definition in particular areas which would present them with
difficulties and (ii) X3J3 did not want the language "cast in concrete" because
they wanted it to be upwards buildable upon.
Nike Metcalf did not think the effort being put into the new BSI proposal worthwhile.
If it was going to be about 1986 before it came to fruition, 8X features will
already be on offer by then from many companies. Also being mainly USA based
they just would not be interested in the BSI effort.
(ii) Fortran 77 Compiler Validation At NCC
Mike Nunn told the meeting that NCC, backed up by funding from DOI, will start
validating F77 compilers in the UK starting from October. They will be using
the same suite of test programs as the USA government's Federal Software Test
Centre (FSTC). Although the first compilers validated by NCC will be of UK origin,
they will also be testing American ones as well by arrangement with FSTC who
have more compilers awaiting test than they can cope with.
After FSTC have tested a compiler they produce a summary report which after
defining
(i) the compiler version and origin
(ii) the hardware tested on
(iii) the operating system used
reports the errors found (if any) in running the test site against the compiler.
For the foreseeable future NCC can supply summary reports on compilers tested by
either themselves or FSTC for free. Anyone interested in obtaining them should
contact:
Vony Gwillim
Senior Consultant
Standardisation Office
The National Computing Centre Ltd
Oxford Road.
Manchester M1 7ED
Phone 061-2286333
A list of compilers certified by FSTC is in appendix C. The first UK compiler
scheduled for test by NCO is ICL's for the 2900. This is expected to be about
mid January 1984.
(iii) Treasurer's Report
A cheque for £50 has been received from Academic Press who sponsored the
sending out of the last newsletter in return for enclosing a publicity notice for
Mike Metcalf's book on "FORTRAN Optimisation".
BCS have now accepted our accounts for the last financial year.
Non-BCS members are reminded that there is a £2 annual fee for membership of
the FORTRAN Specialist Group which automatically provides regular copies of the
newsletter giving minutes of meetings. Anyone who has not paid for this year
by 31 December will unfortunately have to be removed from the membership list.
Outstanding cheques should be sent to the Treasurer, Mr T L van Raalte.
3. BCS Business
There had been no Specialist Groups Board meeting since the last FORTRAN Group
meeting.
In future a separate page in "Computing" will be devoted to Specialist Groups
activities. "Computer Bulletin" will devote a double page as well.
Dr Lawrie Schonfelder (Liverpool University) and Dr John Reid (UK Atomic Energy
Authority) have been attending X3J3 meetings regularly. Lawrie described the
main discussion at the latest August meeting at Los Alamos. John Reid provided
a written summary. A combined synopsis of John and Lawrie's reports is in
5. Any Other Business
(i) A new pocket book is appearing soon called
"Pocket Guide to FORTRAN77" by Clive Page, (Physics Department
Leicester University)
(ii) The next FORTRAN experts meeting will be held at CERN in Geneva in
April. The dates provisionally agreed are the 9-12th and its hoped
to make these firm soon.
6. Date of Next Meeting
5 December 1983 at 10. 30 in Room 4D, Birkbeck College, Malet Street, London WC1.
In the afternoon Lawrie Schonfelder will give a talk on Derived Data Types
in FORTRAN. By courtesy of IBM a film will be shown on the "History of FORTRAN".
7. Talk on "Fortran optimisation"
In the afternoon Mike Metcalf of CERN gave a talk on Fortran optimisation. This
is summarised in Appendix B.
Mike Nunn (Secretary)
18 November 1983
SUMMARY OF X3J3 METING NO 87 AT LOS ALAMOS, AUGUST 1983
1. FORTRAN Information Bulletin
A lot of time was spent by both the full committee and its sub-groups in
discussing and improving the "FORTRAN Information Bulletin" which summarises
whats been passed so far for FORTRAN 8X. It is required by the parent committee
X3 but will be given a wider circulation and is likely to be more suitable
than S6 or S7 to those interested. It includes syntax charts developed by
Jerry Wagener a very clear and simple Bachus - Naur form which will eventually
appear in the Standard. It is hoped it will be approved at the next meeting.
2. Standing Documents S6 and S7
A revised cop of S6 containing all the changes s0 far approved from F77 was
handed out. The new working document is S7 and attempts to merge the new
proposals with the old F77 Standard but maintaining the structure of the F77
document. However it has become clear that this structure is not ideal for F8X.
So Jerry Wagener and the Editorial subcommittee are considering a restructure
which will reflect the central role of TYPE and bring together in one place the
notions of TYPE and DERIVED DATA TYPES in particular. The next few meetings
will be used to (i) expressing correctly in S7 material already passed and
(ii) considering new material altogether.
3. Derived Data Types
Proposals for derived data types have now been passed which provide for strong
typing of data structures. Declaration of the form of a data structure, now
termed a "type", must occur once only in any program scope. Function overloading
becomes legal and infix operators can be overloaded by an operator attribute being
added to the function statement for explicit functions. The proposals are the
work of Brian Smith, John Reid and Lawrie Schonfelder.
4. Bundles and Modules
After much discussion it was decided on a 12-9 vote to rename 'bundles' as
'modules'. It was felt the name 'bundle' would not be taken seriously but those
against the change pointed out that 'module' was already used elsewhere with
different meanings.
5. Event Handling
A form of the proposal passed at the last meeting, but reworded for 8X, was
passed after some detailed changes. A straw vote favoured activate/deactivate
being a block construct or a compiler directive.
An alternative approach to event handling was suggested by Kurt Hirchert who will
be discussing his ideas with the EWICS group in the hope of reaching an agreed
compromise.
6. Array Proceasing
John Reid's proposal to remove the - * section selector and write the * selector
as:,was passed by 24-1. Some concern was expressed in the subgroup that this
will make it more difficult to distinguish between array sections and character
substrings. The full committee was concerned at the loss of convenience (but
not functionality) in removing - *.
User elemental functions are now deleted because they could not be expressed in
a satisfactory way. A proposal from John Reid to allow zero length arrays
(termed "zero sized") was passed without opposition.
7. Character Data
The length parameter in character data will now have a form analogous to the
PRECISION or RANGE attributes of REAL viz:
CHARACTER (LEN = length)
8. Other Items
Time was spent on detailed I/O changes including the problem of handling variable
length records input from terminals. At the next meeting a proposal for intrinsic
functions for date and time will be considered.
ARRAY SUBGROUP
John Reid has attended all the meetings of the array subgroup. Discussions have
centred on the proposals put to the full group described in appendix A section 6
and on modifying the FORTRAN Information Bulletin. It was agreed that names of
keyword arguments should be used in the descriptions of the array intrinsic
functions and that several functions such as RANK and EXTENT should be extended
to all data. types. J Reid undertook to produce formal proposals to put before
the next meeting.
TALK ON "FORTRAN OPTIMiSATION" BY MIKE METCALF (CERN)
1. Mike related there was a myth that a famous guru had two basic miles:
(1) Do not optimise
(2) If you must - do it tomorrow!
Mike believes such people are living in an unrealistic world; with codes as
large as ones in use at his home base of CERN optimisation is really important.
He himself runs courses there on optimisation but with time also devoted to
portability and F8X.
2. Why do we need to optimise?
This could be answered from three viewpoints:
The individual user
(i) Mainframes users who can shorten their jobs will be allowed into job
classes with better turnround times.
(ii) In a virtual machine environment a VM demanding too much cpu time
will be penalised by the scheduler and its turnround time will be
degraded.
(iii) Extra-large jobs become possible within the machine time available.
Management
(i) Better use will be made of expensive resources (despite fall in
hardware costs).
(ii) Congestion on the system will be relieved.
The user community
(i) Optimising the few large programs which use a substantial part of
total computer resources will benefit the turnround time of everyone.
3. The cost balance
There is no point in making expensive improvements to programs if new hardware will
arrive next year needing to run the non-optimised version.
4. Various Issues
(a) Algorithm Search
- This could be called the most important optimisation method
ie there is no point in optimising until you have the best algorithm
for the job in hand.
- You need to refine algorithms and check their sensitivity to data.
- They must be appropriate to task eg very general ones may have
features that are slow for specialist applications.
N
Example To sum the series S = Σ (-1)I .I
I=1
we could simply write in FORTRAN:
S=0
DO 1 I=1,N
S=S+(-1)**I*I
1 CONTINUE
but we could to better by summing odds and evens separately:
S=0
DO 1 I=1,N,2
S=S-I
1 CONTINUE
DO 2 I=2,N,2
S=S+I
2 CONTINUE
[This would only be about 5% of the original time for N=100,000]
but better still by inspection would be:
S=N/2
IF (MOD(N,2) .EQ. 1) S=S-FLOAT(N)
[This might be 100,000 times faster still]
(b) Rules of thumb
(1) 10% of the code very often uses 90% of the time
(2) for short programs - code first, optimise later
(3) for large programs - much more important to apply optimising
techniques at the design stage.
Identifying "hotspots"
Tools - static counts of operations (in loops etc)
- dynamic counters (insert counters at strategic points in programs and
print their values on completion)
- clock routines to time sections of code
- statement counters (print analysis of how many times each statement
executed)
- address histograms (eg on same CDC machines one can inspect the address
of the current program instruction at a frequency which allows the
address to be entered into a histogram covering the program's address
space. Peaks will indicate areas which need attention),
(d) Clarity
Clear code helps the compiler to optimise.
However optimisation can lead to unclear code - is it worth it?
One should use plenty of comments but you could decide optimised code
is not worthwhile because of difficulty in understanding.
(c) Portability
Use of
local bit handling features
machine code
fast I/O facilities
aids optimisation but leads to non-portable code!
∴ use these sparingly, comment well and also provide the standard FORTRAN equivalent
code so that users understand what the original was designed to do.
[The unusual section labelling both here and below is a true copy of the original
typescript.]
(f) Space optimisation
Although main memories have become larger as memory became cheaper
the size of problems being attacked are now larger as well. So
space optimisation is still important and causes little conflict
with time optimisation. In fact optimising compilers produce
faster code primarily via their transformations of source and
intermediate text and their superior choice of machine instructions
which actually result in fewer and faster instructions being generated
in the object code, and therefore require less space. [There may be
exceptions when heavy use of in line code is used but this is usually
avoided when using the highest optimisation level in a compiler.]
Ways of space saving include:
placing infrequently used arrays on backing store
compressing large arrays containing lots of redundant information
packing several data items to a word
sharing storage between different program parts using a
"dynamic memory manager" (data is kept in banks and when no
longer needed the banks can be re-used)
using overlays
5. Ways to Optimise
(i) Avoid DO loops. [because they require the following steps:
calculating number of iterations
test for zero (and branch if necessary)
retaining value of control variable
decrementing loop counter and incrementing
control variable
test for loop completion]
NB: The overheads on small loops can exceed the execution time for
the loop body!
(ii) Nest loops where possible so that the most repeated loops are
the innermost ones.
eg DO 1 I=1,100 No of initialisations = 1
DO 2 J=1,10 100
DO 3 K=1,2 1000
. Total 1101
.
3 continue No of tests for loop completion = 2000
2 continue 1000
1 continue 100
Total 3100
Had these loops been tested in reverse order the total initialisations would be
reduced from 1101 to 23 and completion tests from 3100 to 2022.
(iii) Combine loops (to reduce loop processing overheads)
(iv) Remove invariants outside loops or use IF ...THEN...ELSE
(v) Unroll short loops
(vi) Reduce strength of operators
(vii) Branching instructions- be aware of their relative execution speeds
Rough order (starting with fastest):
Unconditional GO TO
Assigned GO TO
Logical IF
Arithmetic IF
Computed GO TO
In particular testing against zero is usually fast:
eg IF (I.NE.0) will be better than IF (I.EQ.1)
With multiple condition logical IFs order the conditions so that for:
Multiple ANDs - place the condition first that is most likely to fail
Multiple ORs - place the condition first that is most likely to be satisfied.
(viii) Avoid mixed mode arithmetic, as the conversions required impose overheads
(ix) I/O
(a) Use unformatted I/O in preference to formatted where possible
(formatted requires conversions)
[Also if you must have formats prefer explicit ones to avoid evaluation
at execution time.]
(b) Use simple I/O lists
eg: WRITE (NOUT) A ............ may generate 1 call to output
routine but WRITE (NOUT) (A(I), I=1,50)
...................may generate 50 calls to
output routine on some compilers.
(c) Use simple FORMAT statements:
eg: 1 FORMAT (10F11.3)
is more efficient than either
1 FORMAT (1X, F10.3, 1X, F10.3)
or
1 FORMAT (10 (1X, F10.3))
as the space is included in the edit descriptor, and the repeat
count is explicit.
(x) Usually (but this is a complex subject) its faster to use COMMON rather
arguments to transfer data. between subprograms.
(xi) Where possible initialise variables at the beginning of a program by a
DATA statement rather than using an explicit assignment at execution
time.
6. Optimising Compilers
(i) To achieve the greatest optimisation:
- use an optimising compiler at the highest level
- switch off debugging aids
- turn off traceback
- choose inline intrinsic function generation
- switch off array bound checking
(ii) Improvements which optimising compilers make include:
reducing strength of arithmetic operations -
replace divisions by multiplications
eg X = Y/2 -> X - Y*0.5
replace exponentiation by repeated multiplication
eg A***5 -> (A*A)*(A*) *A
[sic, but it doesn't make sense]
on machines with faster additions than subtractions
eg -A-B -> - (A+B)
change multiplications in some cases to additions
eg 2* X -> X+X
(iii) Help the compiler recognise repeated calculations and remove repetitions
eg (a) A = X*Y + 2.0 + Y*X
should appear as
A =(X*Y) + 2.0 +(X*Y)
(b) in the sequence
A = B-C
.
.
.
D = C-B
the second statement should be D= -(B-C)
(iii) Regroup expressions to save numbers of divisions
eg X = Y*Z/A
T = Y*V/A
should be rewritten
X = (Y/A) * Z
T = (Y/A) * V
Footnote:
Those particularly interested in the subject of optimisation are recommended to
read the book by Mike Metcalf called:
"FORTRAN Optimisation" published by Academic Press (cost £12.80)
The book covers more aspects of optimisation, and in a lot more detail than that
given in the above summary of Mike's BCS talk.
CERTIFIED FORTRAN COMPILERS ORGANISED BY LEVEL
This section identifies the current list of certified FORTRAN compilers by the
level for which they are certified. [Nb. Some compilers listed will be error-
free,others will contain errors. The summary reports will detail them.]
Subset Level
Apple APPLE /// FORTRAN Version 1.0
Burroughs B20 FORTRAN Release 3.0
Conv. Tech. CT FORTRAN 8.0
Cray Research CRAY FORTRAN Translator (CFT) Version 1.10
DEC PDP-11 FORTRAN Version 4.1
DEC DECsystem-10 Model 1091 FORTRAN-10 Version 7
DEC DECsystem-20 Model 2020 FORTRAN-20 Version 7
NCR Office Sys NCR FORTRAN Release 3.0
NCSS IBM VS FORTRAN Release 1
TRW DATACOM TRW FORTRAN Version 8.0
Full Level
Burroughs Large Systems FORTRAN 77 Version III.4
Burroughs Medium Systems FORT77 Version 6.6
Burroughs Small Systems FORTRAN 77 Release 10.0
CDC CDC CYBER FORTRAN 5 Level 587
CSC CSTS FORTRAN Release FTN148
Data General AOS FORTRAN 77 Revision 2.11
Data General AOS/VS FORTRAN 77 Revision 2.11
DEC DECsystem-20 2060 Model B FORTRAN-20 Version 7
DEC VAX-11 FORTRAN Version 3.0
Gould, SEL Gould FORTRAN-77+ Release 3.1
Gould, SEL Gould FORTRAN 77/X32 Release 1.1
Harris Harris H800 FORTRAN 77 Version 2.1 (SAU)
Harris Harris H800 FORTRAN 77 Version 2.1 (Non-SAU)
Honeywell Level 6 Advanced FORTRAN Release 2.0
Honeywell DPS 8/44 FZ2.0 FORTRAN
Honeywell Multics FORTRAN Version 10
Honeywell DPS 8/44C FORTRAN 77 C00
IBM VS FORTRAN Release 3.0
MODCOMP MODCOMP NASA Extended FORTRAN 78
NCR VRX FORTRAN Ver. 23
Perkin-Elmer FORTRAN VII Release R05-01
Prime Prime FORTRAN 77 Rev 19.1
Sperry Univac 1100 Series ASCII FORTRAN Level 1OR1A
Stratus VOS FORTRAN Release 2.4a
United Info CDC Cyber FORTRAN 5.1 Level 552