On Mon, 21 Sep 1998 11:39:13 -0400 Peter Shenkin
<[log in to unmask]> wrote:
> On Sep 21, 10:08am, Pierre Hugonnet wrote:
> > Subject: Re: performances, again.....
> > Dan Nagle wrote:
> > > My gripe with IBM's xlf compiler is that it's a great compiler, provided
> > > one writes a novel on the command line ...
> ...
> > That's true that despite the novels on the command line, xlf is one
> > of the best f90 compilers, if we consider the balance between
> > performances (good), reliability (excellent: almost no bug),
> > and easy-to-use (the novels...)
> ...
>
> I have also found xlf90 to be robust and reasonably efficient.
>
> > The problem is not to find a good f90 compiler -I'm conviced that
> > they exist-, but rather to to be sure that the code you write
> > will be efficiently compiled on various machines with various
> > compilers, which is fundamental when working in heterogeneous
> > environment.
>
> This will inevitably take time for F90.
>
> ...
> > Wouldn't it be possible to introduce in the standard the concept
> > of "performance issue", by clearly saying that a given construction
> > is provided to make easier the code generation, but is not likely
> > to be efficient (pointers vs arrays, assumed shape vs explicit
> > shape,...) ?
> ...
>
> I would be against this. There are many constructs which will
> in fact be inefficient on many, most or all compilers, but
> which could in fact be efficient if the compilers went to the
> trouble to do a better job of optimization -- as they will
> be programmed to do, over time.
>
> Books on F90 might profitably point such things out, however.
>
> The problem still remains: what about a construct which
> is optimized well on compiler X but not on compiler Y? Should
> the user stick with the F90 subset that optimizes well on both?
> And then what if a member of this subset optimizes poorly on
> compiler Z, which the user has just decided to port to?
>
> Finally, one thing that I've learned since beginning to use
> Fortran 90 is that though many things are gained, some are
> lost. One is a rather close correspondence between what
> the user code looks like and what the compiled code is doing.
> I don't want to exaggerate the closeness of this correspondence
> in F77 -- which, like all computer languages, has its share
> of "gotchas" -- but F90 introduces many more.
>
> A simple statement like "A = B" may, especially with defined types,
> be hiding an extremely complex sequence of events. The naive user
> of a library using these types is unlikely to be aware of this.
i don't know if you can reconcile higher levels of abstraction
with efficiency and getting the end user to learn enough
to fully appreciate what is going on behind the scenes.
i have a pathological C++ example that i ask the students
to predict what will happen when the program executes.
there are a small numbers of functions called that all
involve constructors being called behind the scenes.
there are no exact signature matches and predicting what will
happen is quite difficult.
> In F90, it is very easy to write code that looks simple but
> does very complicated things. This is usually viewed
> as an advantage; what's lost is that it's not obvious
> to the user that complicated things are being done
i agree but isn't that a problem with a black box - and we all
rely on them to some degree. i'm just as lazy as some of the
user community i critcise at times.
; there
> may be far more efficient ways of doing things.
>
> Simple example:
>
> REAL :: A( 100 ), B( 100 ), C( 100 )
>
> A = B + 2
> !!! intervening statements
> C = B * 3
>
> Is the F90 compiler going to be smart enough to know when the
> two implicit DO-loops can be fused?
>
> How about if A, B and C are ALLOCATABLE (and are all ALLOCATEd
> to the same shape)?
>
> The F77 programmer would naturally be looking for opportunities
> to carry out the two operations shown above in the same DO-loop;
> so if the F77 compiler doesn't know how to do loop fusion, it's
> not as big a deal; but depending on what the intervening
> statments look like, it might be difficult for an F90 compiler
> to generate code as efficient as that which the F77 programmer would
> have written.
>
> The worst F90 gotcha I've encountered in practice is the
> deceptively simple syntax for automatic arrays. The problem is that
> if the implicit allocation request cannot be satisfied, there is
> nearly no way to reliably diagnose the problem from within
> the program and exit gracefully with an informative message;
> usually, a SEGV occurs, but a SEGV can also arise from other
> causes. This is just awful.
maybe some of this will be addressed by newer texts. there is now a
lot more hard evidence about f90. i liked the ideas of modules
having had to support modula 2, but had little idea what was going
to pan out in fortran 90 in practice. better education always helps.
also is some of the above quality of implementation? the
you asked for it your going to get it approach really makes
the language suffer. things surely could be better than a core dump?
rm core
is one of the first things i teach :-)
>
> -P.
>
>
> --
> *** "Freedom's just another word for nothing left to lose." (B. Yeltsin)***
> *Peter Shenkin; Chemistry, Columbia U.; [log in to unmask] (212)854-5143*
> *MacroModel WWW page: http://www.columbia.edu/cu/chemistry/mmod/mmod.html *
----------------------
Ian Chivers
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
