Re: [OT] Funny

From: James Van Buskirk (not_valid_at_comcast.net)
Date: 02/19/04 

Date: Wed, 18 Feb 2004 23:57:20 GMT

"Rich Townsend" <rhdt@barREMOVEtol.udel.edu> wrote in message
news:c10kh9$ad8$1@scrotar.nss.udel.edu...

> Richard Maine wrote:

> > Rich Townsend <rhdt@barvoidtol.udel.edu> writes:

> >>I was under the impression that assumed-shape
> >>dummies had just the same liability -- if the real argument is
> >>non-contiguous, then copy-in/copy-out occurrs,

> > I have never once seen that happen in any compiler. Well,
> > the NAG compiler does have a switch to allow you to tell it
> > to do that, but that is only at your explicit request (presumably
> > you know that the benefits of contiguity will outweigh the
> > costs of the copy); it isn't the default.

> Well, blow me down; I've learned something new today! It appears that
> compilers are cleverer than I thought -- when using an assumed-shape
> dummy within a routine, they have to do all the index arithmetic with
> non-unity strides and whatnot. I always thought they went for the easy
> solution which copy-in/copy-out provides; but it seems not.

It's not a question of compilers being clever: if both the actual
and dummy arguments have the TARGET attribute, the compile must at
least emulate all the index arithmetic with non-unity strides.
The reason for this can be seen in the following program:

module copy_it
   implicit none
   contains
      subroutine copy_me(x, p)
         integer, target :: x(:)
         integer, pointer :: p

         p => x(2)
      end subroutine copy_me
end module copy_it

program copy
   use copy_it
   implicit none
   integer, target :: a(5)
   integer i
   integer, pointer :: q
   character(80) fmt

   a = (/(i,i=1,size(a))/)
   call copy_me(a(::2), q)
   q = 7
   write(fmt,'(a,i0,a)') '(',size(a),'i2)'
   write(*,fmt) a
end program copy

The output must be:

1 2 7 4 5

or the compiler simply isn't conforming. I'm curious as to
whether NAG, with the switch Richard Maine described above
just ignores the switch and fails to make the copy, makes
the copy but does some wierd gymnastics to get q to point at
the right target, or creates non-conforming (you asked for
it with the switch, right?) code.

> Time to update my code, then -- assumed-shape dummys here I come! I'll
> be interested to see if any performance increase ensues -- I'll let the
> newsgroup know what I find.

Copying can improve performance, and not just because it avoids
more arithmetic in computing addresses of array elements -- dis-
contiguous arrays can have problems in that "adjacent" array
elements can live in different cache lines and even on different
pages so that working with them can cause a cache line or even
TLB refill on every access. One of my favorite axamples of this
is the CAPACITA benchmark from the Polyhedron suite, see
http://www.polyhedron.com . The subroutine fourir has assumed-
shape dummy arguments A and B; when invoked as part of a 2D FFT
in the code, the result is almost a TLB miss per array access;
the code runs faster if rewritten to use adjustable arrays and
even faster with dedicated copies that attempt to move an
entire cache line at a time.

That having been said, the usual circumstance is as Richard
Maine has pointed out: someone writes code that requires
copying of a large array just to touch a couple of its elements
at a time, and is completely blind-sided by the performance
drop. Maybe that would be a good example to put on my website
if I weren't so overburdened with everything else just now...
I just wanted to point out that when you get used to it, you
can both avoid wasteful copies and force beneficial copies
if sufficient attention is paid to these issues. 

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Relevant Pages

  • Re: How to initialise arrays to zero?
    ... but it is valid Fortran. ... error message of the NAG compiler? ... DIMENSION:: Array ... I also like the NAG compiler although it is not really cheap to buy it ...
    (comp.lang.fortran)
  • Re: Idea for ECMA/C# Standard - compile time hash for performance
    ... I agree with you the chance of a compiler change is slim, ... and then delegating to the standard hash for fields accessed less frequently. ... or the array lookup which would require the ... > 64-bit architecture) for each enum value that doesn't map to anything. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Q: Checking the size of a non-allocated array?
    ... an actual argument is already invalid ... First note that you don't have an unallocated array in the subroutine. ... it is comparable to disassociated or undefined pointers. ... Obviously the compiler has ...
    (comp.lang.fortran)
  • Re: Windows array allocation problem
    ... array reference has to have a 64-bit index or array subscript triplet? ... to fit in one. ... That assumes, of course, that your compiler ... limits on just about anything. ...
    (comp.lang.fortran)
  • Re: Error handling library
    ... which lets the compiler catch out-of-range usage. ... and assuming that a higher int means "more dangerous error" ... with a comment warning that one is used as an index into the array ... languages while running (an array of languages, ...
    (comp.lang.c)