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: f8x impact on debugging (was: Re: yes vs. no on f8x)
Message-ID: <621@loligo.cc.fsu.edu>
Date: 26 Apr 89 13:16:26 GMT
References: <12170@lanl.gov> <12179@lanl.gov>
Reply-To: mccalpin@loligo.cc.fsu.edu (John McCalpin)
Organization: Supercomputer Computations Research Institute
Lines: 61

In an earlier article, I wrote that I don't expect Fortran-8X to
adversely effect the efficiency of my codes.

In article <12170@lanl.gov>, by jlg@lanl.gov (Jim Giles) Jim replies
that efficiency is a "major problem" with his applications, and
continues: `... This seems to represent the difference between
university computer attitudes and those of the "real world"....'

In article <12179@lanl.gov> dph@lanl.gov (David Huelsbeck) writes:

>I think what John was trying to say was that in his estimation the 8x 
>changes would not impact his efficiency adversely because they
>wouldn't change the way he writes code other than to make some constructs
>much less verbose.  I'm sure John will correct me if I'm wrong.

Yes. In fact, the array notation from 8X should make it much easier for
the compiler to figure out how to run my code efficiently on a vector
machine. 

It is amazing the contortions that programmers are willing to go
through to get vectorizers to understand their codes.  It is equally
amazing the effort that vendors go through to write vectorizers to
infer vector operations from (syntactically) scalar code.  But what is
most amazing is that so few people think that this is an odd approach!

I have suspected that the reason that vector coprocessors are so scarce
on small machines (e.g. Sun's) is that so few companies have the
resources to build a decent vectorizer.  Now perhaps some companies
will be in a better position to produce such things --- the restriction
would be that only explicit vector code would run on the coprocessor.

>Since deprecation etc. is now gone from the draft any of the old hacks
>that improved efficiency should still work.  Further more, no one is
>implying that they're going to be taken away any time soon.

Deprecation is not *gone* from the draft, but no features are currently
included in that list.

>Are there
>any additions that should impact the efficiency of codes that don't use
>them?  I have a copy of the draft but I don't know as much about 
>optimization and vectorization as Jim and Co.

This is the big issue that needs to be addressed here.  I think that the
new draft looks great.  I hear lots of talk that the compilers will not
be able to produce good code, but I have not yet heard any *specific*
arguments.

>Why should people be upset if features that are inefficient only when
>used are added?  Separate compilation limits optimization but I haven't
>heard anybody asking to have it removed (for that reason).

And there is nothing (except money?) stopping vendors from using an
intermediate code to allow interprocedural optimization (a la MIPS).

>-dph
-- 
----------------------   John D. McCalpin   ------------------------
Dept of Oceanography & Supercomputer Computations Research Institute
mccalpin@masig1.ocean.fsu.edu		mccalpin@nu.cs.fsu.edu
--------------------------------------------------------------------