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
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
> Regards,
>
> Mike Metcalf
Jan
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
f90 -version
MIPSpro Compilers: Version 7.3.1.3m
>q1(2100,2000), q2(2000,2000)
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...@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 am finding that f77 coding on matricies sometimes vastly out
> performs F90 coding on SGI IRIX6.5 with latest compilers,
> for example,...
> as compared to f77 coding
>
> do j = 1,2000
> do i=1,2000
> q2(i,j) = q1(i,j)
> enddo
> enddo
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
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
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
> In article <ueu1ko7...@altair.dfrc.nasa.gov>,
> on 17 Sep 2002 07:57:29 -0700,
> Richard Maine <nos...@see.signature> writes:
> >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....
> 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.
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".
Rob Somerville wrote:
> 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
================================
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
<snip>
>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).
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
> ...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.
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