I am finding that f77 coding on matricies sometimes vastly out
performs F90 coding on SGI IRIX6.5 with latest compilers,
for example, given:

q1(2100,2000), q2(2000,2000)

this coding is twice as slow as the f77 coding:

q2(1:2000,:) = q1(1:2000,:)

as compared to f77 coding

do j = 1,2000
  do i=1,2000
    q2(i,j) = q1(i,j)  
  enddo
enddo

is this a problem with the compiler, or the F90 newbie ????

thanks
Robert somerville

news:3D8690AE.9E30EF8C@telus.net...
            ^

Do you really mean 2100? If it's supposed to be 2000, have you tried

q2 = q1  ?

Regards,

Mike Metcalf

no, q1's row dimension (2100), because of math derivation, needs to be
bigger than q2's (2000) , which is used in the next step of the
solution. In this case the f77 is twice as fast as the f90 way i
originally coded it, at least according to the profiler

This looks like a problem with the compiler. However, this is an area
where compilers have improved considerably in the past years. Are you
sure you have an up-to-date version of the compiler in question?

        Jan

Attached you'll find a little test program. Compiling the two files seperately
/fast and linking them with CVF 6.6A, I get the following results:

Loop count:10
   6.960000      for array operation
   6.760000      for loop

Loop count:20
   13.62000      for array operation
   13.50900      for loop

Loop count:30
   20.46000      for array operation
   20.25900      for loop

Loop count:30
   20.40000      for array operation
   20.36900      for loop

So there's a ~2% difference between the two. If I leave out the call to
do_nothing, the run time is always 0.0, as expected 8-|.

        Jan

        program test

        implicit none

        real(8) q1(2100,2100), q2(2000,2000)
        integer start, stop, rate
        integer i, j, c, count

        write (*, "(A)", advance="no") "Loop count:"
        read (*, *) count

        call system_clock (count_rate = rate)

        call random (q2)

        call system_clock (count = start)

        do c = 1, count
          q1(51:2050, 51:2050) = q2
          call do_nothing (q1)
        enddo

        call system_clock (count = stop)

        write (*, *) FLOAT(stop-start)/FLOAT(rate), " for array operation"

        call system_clock (count = start)

        do c = 1, count
          do j = 1,2000
            do i=1,2000
              q1 (i+50, j+50) = q2 (i, j)  
            enddo
          enddo
          call do_nothing (q1)
        enddo

        call system_clock (count = stop)

        write (*, *) FLOAT(stop-start)/FLOAT(rate), " for loop"

        end program test
!
!       must be in seperate file and compiled seperately....
!
        subroutine do_nothing (x)
        real(8) x(*)

        return

        end

yes it is the very latest production SGI compiler release :

f90 -version
MIPSpro Compilers: Version 7.3.1.3m

On Tue, 17 Sep 2002 02:16:47 GMT, robert somerville <somer...@telus.net>
 wrote in <3D8690AE.9E30E...@telus.net>:

        I'd suspect that you're triggering an unnecessary copy to
an intermediate at some level.  Since you're copying to the whole
of q2, does

q2 = q1(1,2000,:)

run any differently.  Alternately, generate a machine-code listing and
inspect that for unnecessary activity.

--
Ivan Reid, Electronic & Computer Eng., Brunel Uni.      Ivan.R...@brunel.ac.uk
        KotPT -- "for stupidity above and beyond the call of duty".

We've found SGI compilers to be quiet poor for certain F90
array constructs.  See

 http://groups.google.com/groups?th=234c8f81140343dc

for some amazing numbers.  (Previous versions of the SGI
compiler were giving F90/F77 near 100 for both the work
and io tests!)

--
Bil

I'll leave the performance comments to others.  I see there have been
some such comments.  I'll restrict my comment to noting that the above
*IS* f90 coding.  It is perfectly legitimate f90 code.  (Indeed, it is
not actually legitimate f77 code, do/enddo being an extension of f77).

Both whole array operations and loops are equally legitimate f90
constructs and they both have their places in f90 code.  Characterizing
loops as non-f90 is simply incorrect.  One might as well characterize
all names shorter than 8 characters as being non-f90.

--
Richard Maine                       |  Good judgment comes from experience;
email: my last name at host.domain  |  experience comes from bad judgment.
host: altair, domain: dfrc.nasa.gov |        -- Mark Twain

well, today I can't reproduce my claim of yesterday  :-( , although i duplicated
  it several times!  possibly interaction of system load & the profiler ???

in any case my results are relatively comparable in relative speeds to yours!
Althougth my slight modification to your code results in a segmentation
fault,which may indicate a problem of some sort with our compiler :

./test14
Loop count:5
Segmentation fault

-----------------------------

        program test

        implicit none

        real*4, pointer,dimension(:,:) :: q1, q2
        real*4, allocatable,target,dimension(:,:) :: x1, x2
        integer start, stop, rate
        integer i, j, c, count

         allocate(x1(6200,6000),x2(6000,6000))

         q1 => x1
         q2 => x2

        write (*, "(A)", advance="no") "Loop count:"
        read (*, *) count

        call system_clock (count_rate = rate)

        call random_number (q1)

        call system_clock (count = start)

        do c = 1, count
          q2(1:6000, :) = q1(1:6000,:)
!         call do_nothing (q1)
        enddo

        call system_clock (count = stop)

        write (*, *) FLOAT(stop-start)/FLOAT(rate), " for array operation"

        call system_clock (count = start)

        do c = 1, count
          do j = 1,6000
            do i=1,6000
              q2 (i, j) = q1 (i, j)
            enddo
          enddo
!         call do_nothing (q1)
        enddo

        call system_clock (count = stop)

        write (*, *) FLOAT(stop-start)/FLOAT(rate), " for loop"

        end program test

In article <ueu1ko7jfq....@altair.dfrc.nasa.gov>,
 on 17 Sep 2002 07:57:29 -0700,
 Richard Maine <nos...@see.signature> writes:

         It seemed clear enough to me.  Would you prefer "f77 style"
and "f90 style"?
         You seem a bit defensive about the fact that f90 style code
is often slower.  In this case this may be due to the fact that f90
array operations were defined (unwisely in my opinion) so as to
sometimes require temporary arrays.  Compilers are not always clever
enough to eliminate these temporary arrays when they are not needed.
This can add considerable overhead.  Some compilers (xlf for example)
have a compiler option which tells the compiler that temporary arrays
are not needed which may allow them to generate better code.
                        James B. Shearer

I'm afraid you miss my whole point.  *BOTH* styles are f90 styles.
This is like asking whether you drink liquid or coffee in the morning
- it is not a meangful distinction because one is a subset of the
other (well, usually :-).  It is true that whole array operations are
not f77-style, but it is misleading to say that DO loops are not f90 style.

There exist people who seem to think it is somehow improper to use DO
loops in f90 - that one must use array operations, no matter how slow
or awkward.  If so, that is their personal style choice - it is
*NOT* a style choice defined by the language.  (Nor is it a style
choice that I personally like).

Yes, whole-array operations are sometimes slower.  I do not argue that
point at all.  I agree with that point.  I argue only that the use of
DO loops does not make a code "f77-style".

--
Richard Maine                       |  Good judgment comes from experience;
email: my last name at host.domain  |  experience comes from bad judgment.
host: altair, domain: dfrc.nasa.gov |        -- Mark Twain

              ================================

    If I read the enclosed code correctly, your "slight modification"
completely changed Jan's example code: since you've commented-out the
calls to the procedure do_nothing, the compiler is free to optimize
your whole program away!!!  And most good compilers will do that...

    Create a skeleton do_nothing subroutine, like that provided in
Jan's example, remove the comments, and rerun your tests.  I can't
guarantee that you'll get the preformance skewing you saw originally,

    -Ken
--
I don't speak for Intel, Intel doesn't speak for me...

Ken Fairfield
D1C Automation VMS System Support
kenneth.h.fairfield#intel.com

In article <ueznueyqut....@altair.dfrc.nasa.gov>,
 on 19 Sep 2002 07:51:54 -0700,
 Richard Maine <nos...@see.signature> writes:

         <snip>

         Considering all the f90 propaganda about what an advance f90
was on f77, it is not surprising that some people think that if f90
provides another way of doing something that you could do in f77 then
the fortran 90 way must be better.  The average user is not aware that
many f90 features were defined in ways that are difficult to implement
efficiently.
                             James B. Shearer

That is part of why I get pedantic about the point of terminology.  I
think that the use of misleading terminology contributes to such
misconceptions.  Describing DO loops vs whole array operations in
terms of f77 style vs f90 style is easily the topmost item on my list
of such misleading terminologies.

I repeat again that whole array operations are not "the f90 way".
They are one of the f90 ways.  If one describes whole array operations
as "the f90 way" then one encourages exactly the kind of misconception
that you mention above.  If one impartially says that f90 provides two
(or more, really) ways to do this, then that encourages the
consideration of which way is better for a given situation.  I think
that your way of describing it encourages the proplem that you
then bemoan.

F90 also allows variable names up to 31 characters long, whereas f77
was limited to 6 (at least in the standard, though extensions were almost
universal in later years).  That doesn't mean that the f90 way is to
use long variable names.  Instead it means that you can choose (within
the limit of 31) how long a name is appropriate for a given situation.
Names pushing the 31-character limit are appropriate for some situations,
and 1-letter names are appropriate for others.  (Names longer than 31 might
even be appropriate in a few situations, though not very many IMO - the
f2k CD raises this to...I think it was 63).  The f90 way here is to
choose whatever length is appropriate based on criteria other than the
language.

Likewise, the f90 way is to choose either DO loops or whole array
operations as seems appropriate based on other criteria.  The standard
itself offers no hint of preference.  Any prejudicial labelling of
only one of these as "the f90 way" is a free (and misleading) extra.

--
Richard Maine
email: my last name at domain
domain: isomedia dot com