Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!gatech!prism!loligo!mccalpin
From: mccalpin@loligo.cc.fsu.edu (John McCalpin)
Newsgroups: comp.lang.fortran
Subject: Re: yes vs. no on f8x
Message-ID: <620@loligo.cc.fsu.edu>
Date: 26 Apr 89 12:34:33 GMT
References: <590@loligo.cc.fsu.edu> <12170@lanl.gov>
Reply-To: mccalpin@loligo.UUCP (John McCalpin)
Organization: Supercomputer Computations Research Institute
Lines: 58

In article <12170@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <590@loligo.cc.fsu.edu>, by mccalpin@loligo.cc.fsu.edu:
>> I happen to work in vector-supercomputer-land, where efficiency is
>> not a problem.  My codes will simply change from several thousands
>> of lines of sequential DO loops to a few thousand lines of array notation.

>I happen to work in vector-supercomputer-land - and efficiency is _the_
>major problem.  This seems to represent the difference between university
>computer attitudes and those of the "real world".

Almost.  It is closer to being the difference in attitudes between
those who are able/willing to re-write their codes from scratch to
perform well on a given architecture, and those who are not
able/willing to do so.  Obviously, I list myself in the former group,
but there are also many university users who belong to the latter.

For my codes (which are essentially 100% vector instructions), the 
new Fortran should compile into code which is just as efficient as the
old FORTRAN, but with a lot less compiler effort.

I suspect that Jim has to work on codes that are substantially larger
than what I have to deal with. My current code is about 5000 lines of
FORTRAN-77, or about 1300 lines of Fortran-8X. (This excludes the
machine-dependent part, such as optimized FFT's, which I count on
someone else providing).  The code was also designed with 8X in mind.
I'm sure I would feel differently if I had >10,000 lines of old code to
deal with - especially if I did not write it....

>> heard it rumoured that DEC opposes the array notation because the need
>> to pass an array descriptor (rather than just a pointer to the start of
>> the array) forces one more level of indirection in array references,

>Pass the whole descriptor by value.  The level of indirection remains
>the same.  This can be done because the rank (number of dimensions)
>of the array is known at compile time.  Therefore the size of the
>descriptor is also known at compile time, and the correct code can
>be generated for the call.

Yes, that is the obvious answer, but it seemed to me that the overhead
is still a bit high because the descriptor is not trivially small.
I'm not sure exactly what needs to go into the descriptor, but I think
that at least the following are necessary:

	pointer to beginning of array section
	number of array dimensions (n=<7)
	size of dimension 1
	size of dimension 2
	  "   "     "     "
	size of dimension n	(n=<3 most of the time)

Increasing the size of argument lists is usually a bad thing,
performance-wise, since it means that you can often not pass the
arguments in registers.
-- 
----------------------   John D. McCalpin   ------------------------
Dept of Oceanography & Supercomputer Computations Research Institute
mccalpin@masig1.ocean.fsu.edu		mccalpin@nu.cs.fsu.edu
--------------------------------------------------------------------