Re: IVF is a wonderful compiler (was IVF continues to disappoint (relatively))

There, that's better.

Joost wrote:

Greg Lindahl wrote:

In article <1148140178.003452.172670@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Joost <jv244@xxxxxxxxx> wrote:


In my experience, for well written code, g95 will typically be within
+-30% of the fastest compilers *except* if the hot loops involve array
syntax. In quite a few of these cases g95 is still unable to detect
that these can be correctly evaluated without introducing a temporary
array.

Er, that doesn't make any sense. I can write F77 equivalent code for
array syntax. You're saying that g95 won't do well on that F77 code,
either. Lots of competing compilers rewrite all array syntax into F77
and then optimize the F77 -- so they can elimiate the temporary array
in both the array syntax case and the F77 case.

And yes, I've seen real users write F77 loops with unnecessary
temporary arrays.


well. F77 code with unnecessary temporary arrays is not what I call
well written code, and indeed, I'm rather sure that won't be optimised
by g95 (nor g77). F90 that uses array syntax can be well written code
(in particular if it is obvious to the programmer that it can be
evaluated without temporary e.g. v(:)=v(:)+f(:) where v and f can't
alias) but currently can run slowly with g95 because the front-end
might insert a temporary (which won't be removed by the backend). I'm
sure you don't need the example but g95 will translate the above array
syntax to something like

allocate(tmp(N))
DO I=1,N
tmp(I)=v(I)+f(I)
ENDDO
DO I=1,N
v(I)=tmp(I)
ENDDO
deallocate(tmp)

and the backend won't make
DO I=1,N
v(i)=v(i)+f(i)
ENDDO
out of this. I agree that it would be nice to have the backend do this
(because in badly written code this might explicitly occur) but the
choice in gcc seems (so far) to be different, and relies on the
front-end to provide a clean intermediate representation (as far as I,
as an outsider, can tell).

Joost



--

Gary Scott
mailto:garyscott@xxxxxxx

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.


If you want to do the impossible, don't hire an expert because he knows it can't be done.

-- Henry Ford
.

Relevant Pages

  • Re: IVF continues to disappoint (relatively)
    ... In quite a few of these cases g95 is still unable to detect ... array syntax. ... You're saying that g95 won't do well on that F77 code, ...
    (comp.lang.fortran)
  • Re: Passing subsections of arrays in f77
    ... I guess I'll go ahead and post it anyway, along with a short f77 ... The hack is that you pass an array element as the actual argument. ... that the OP's ais not a proper syntax for an array element. ...
    (comp.lang.fortran)
  • Re: IVF continues to disappoint (relatively)
    ... In quite a few of these cases g95 is still unable to detect ... array syntax. ... You're saying that g95 won't do well on that F77 code, ... Lots of competing compilers rewrite all array syntax into F77 ...
    (comp.lang.fortran)
  • Re: Use and misuse of derived data types
    ... only way to do it in f77. ... Looking at the syntax of an individual line is not ... It seems to me that, having, for example, an array of gamma values is a ... derived type, that makes it explicit that they go together. ...
    (comp.lang.fortran)
  • Re: .join() !== + a + b; // for some a and b
    ... The one seemed obvious until your more detailed explanation below, ... that made it necessary to look deeper into the syntax. ... one an Array object reference and one ... seems wrong with the expression evaluation on the left side of the logical ...
    (comp.lang.javascript)