reshape efficiency
in [Fortran]
|
Prev: Clarify An Old Question: define a user data containing array with ?dimensions decided in running time
Next: Clarify An Old Question: define a user data containing array with dimensions decided in running time
From: Richard Maine on 19 May 2010 12:02 Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: > You can tell what is happening in any specific case by using the > nonstandard, but common, LOC() function. But be aware of a caveat of such use. I recall one case here where someone reported what seemed to me to be surprising behavior in regards to when their compiler(s) made a copy of an argument (not related to reshape in that case, but rather to assumed shape dummy arguments). They were using a LOC function to determine whether or not a copy had been made. It turned out that they drew a completely incorrect conclusion, pretty much exactly the opposite of what was actually happening. They were mislead because the call to LOC involved a COPY in some cases. They hadn't realized that was where the copy was happening. I forget all the details involved; it might be that they were using some non-intrinsic version of LOC that the compiler didn't know to treat specially. But I do recall them having been seriously mislead. I recall that because their reported results were extremely surprising to me (and it was a "regular" here who is pretty reliable). -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Ron Shepard on 19 May 2010 12:56 In article <1jiqdyt.14lgbhj1lk8pe6N%nospam(a)see.signature>, nospam(a)see.signature (Richard Maine) wrote: > It turned out that they drew a completely incorrect conclusion, pretty > much exactly the opposite of what was actually happening. They were > mislead because the call to LOC involved a COPY in some cases. Yes, I think I remember that too. I think the workaround to get the correct result was to pass an individual array element to the LOC() function, not the entire array. $.02 -Ron Shepard
From: James Van Buskirk on 19 May 2010 13:00 "Ron Shepard" <ron-shepard(a)NOSPAM.comcast.net> wrote in message news:ron-shepard-E138B8.10103619052010(a)forte.easynews.com... > For example, if A(:,:,:,:) were a dummy argument rather than a local > array, then the compiler could not know that the first D**2 elements > all have the same spacing, so a copy would almost certainly have to > be made by the reshape. For programmers who were adept as using > storage sequence association in their f77 codes, this was (and is) > an important restriction in using array syntax and deferred shape > declarations in the newer versions of the language. There is also the issue about what happens when the ORDER optional argument is present. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: Jim Xia on 19 May 2010 23:45 > One of the new features of f2008 (which I don't use yet, so I may > get some details wrong) is that you can assign pointers of higher > rank to 1-D arrays. The 1-D array will always have a fixed spacing > between the elements, allowing storage association magic to work > again. This would allow you, for example, to allocate the array as > A(D**4), and assign A2(:,:) or A4(:,:,:,:) pointers to that array. > Those pointers could then be used in the PROCA() call in the usual > way, avoiding the array copies in many cases. I assume you mean code like this? program PROG real, dimension(:,:,:,:), allocatable :: A real, dimension(:), pointer :: B real, dimension(:,:), pointer :: C integer ::D D=... allocate( b(D**4)) b(:) = ... c (1:d**2, 1:d**2) => b call PROCA(c) contains subroutine PROCA(A) real, dimension(:,:) :: A ! dimension(D**2, D**2) ! ... end subroutine PROCA end program This is an F2003 feature, not F08 feature. If D is large, and reshape may become expensive, then this pointer choice could save memory usage and speed as well. XLF supports this feature since V11.1. The downside, of > course, is that using the pointer arrays and the target attributes > suppresses many of the optimizations that are allowed otherwise, so > the programmer must be aware of the tradeoffs if efficiency is > important. In the worst case, your fortran program could end up > being as slow as a C program, and we wouldn't want that, right? :-) Not general the case. For compilers, the Fortran pointers are C-like structures that maintain the internal book-keeping of the memory. The use of pointers itself shouldn't prevent optimizations since Fortran has rigid rules against "invalid aliasing" and good compilers should have sufficient information on the usages of all the pointers. What's bad about the pointers are the manual memory management by users. And memory leaks are a major source of concern in large scale applications. Allocatables are a far more user-friendly language feature. However to the compiler, optimizing allocatables are just as hard as optimizing pointers most of times. Under the hook they're very much similar, except compilers have to actively manage memory for allocatables. The only advantage in allocatables is that it's known to be contiguous. F08's CONTIGUOUS attribute may give pointers a performace boost. Cheers, Jim
From: Richard Maine on 20 May 2010 01:49
Jim Xia <jimxia(a)hotmail.com> wrote: > The > use of pointers itself shouldn't prevent optimizations since Fortran > has rigid rules against "invalid aliasing" and good compilers should > have sufficient information on the usages of all the pointers. Except that most of those Fortran rules about "invalid aliasing" are for non-pointers. If both sides of an alias are pointers, then that usually makes it "valid aliasing." Admitedly, if you take a pointer and pass it as an actual argument to a non-pointer dummy, then the non-pointer rules do come into play. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |