forall Vs Do...enddo Vs Where
in [Fortran]
|
Prev: Order Oxycontin cod overnight delivery. No prescription Oxycontin fedex delivery. Buy Oxycontin money order. Buying Oxycontin overnight delivery.
Next: generic interface with procedure in used module
From: " --MM-->>" on 6 Jan 2010 05:40 Tim Prince ha scritto: > <<--MM-->> wrote: > >> >> I read about Forall and Where in some paper/tutorial for the fortra95, >> and in any case isn't clarifly the real difference, but the idea >> suggested was that the compiler can optimize the internal code. >> I mean in Do loop on an array a(i,j) I use normaly a sequencing via >> the fast coordinate >> >> do i=.... >> do j=... >> a(i,j)=... >> enddo >> enddo >> >> when the software is increasing I use FORALL e WHERE in order to >> reduce the lines of code. >> >> But now I discovered that in this case I can lost the efficency. >> >> Is it true also for dual core or quad core processor? > Your pseudo-code contradicts what you said. Yes, you are right, it was a mistake (change i to j and viceversa)
From: m_b_metcalf on 6 Jan 2010 10:13
On Jan 6, 2:34 am, Ron Shepard <ron-shep...(a)NOSPAM.comcast.net> wrote: > In article <hhvt2u$1c...(a)online.de>, > hel...(a)astro.multiCLOTHESvax.de (Phillip Helbig---undress to > > > > > > reply) wrote: > > In article <1jbt60e.k9bpesczgc7wN%nos...(a)see.signature>, > > nos...(a)see.signature (Richard Maine) writes: > > > > I don't know why you > > > would think that forall was somehow inherently more optimizable than DO > > > loops. > > > > DO is a looping construct. Forall and Where are array assignments. That > > > is a really fundamental difference. > > > Maybe that is the reason he thought it would somehow be inherently more > > optimizable. DO implies doing things one after the other. If the > > compiler can prove to itself that parallel execution is OK, then it can > > do that optimisation. However, with FORALL and WHERE, there is no > > serial implication, so the compiler can perhaps optimise a bit more > > aggressively. > > The semantics that we all wanted back in the 80s when the next > fortran revision (f88 :-) was being discussed was exactly what you > say above, a looping type construct in which the order of execution > is unspecified. That matched the vector hardware of the time. > Unfortunately, FORALL adds a little more, and it is that little bit > extra that gets in the way of optimization. In particular, the > problem seems to be the requirement that the statement is evaluated > "as if" everything on the right hand side is stored into a temporary > array of the appropriate size and then assigned to the left hand > side target array. If the compiler can't figure out that the > temporary array is unneeded and assigns results directly to the > target array (which seems to be somewhere between "always" and "too > often"), then it actually does allocate a temporary array to hold > the intermediate results. It is that allocation and deallocation > that seems to be the problem with optimization of FORALL. > > The looping construct we wanted would have required the programmer > to make sure that the order of execution was not important. > Sometimes that is obvious for a statement or group of statements, > sometimes it isn't, so this was a potential source of coding errors > for programmers. FORALL does the arbitrary-order part, but it > provides the safety net of evaluation-before-assignment so that the > programmer cannot possible make a mistake. It is that safety net > that seems to be the cause of the optimization and performance > problems. > > At this point, I don't know what the best solution is. Should a new > DOALL construct be added that works the right way? Should a > compiler directive be specified somehow in the standard to tell > FORALL to behave correctly? There doesn't really seem to be a good > solution to the problem. In hindsight, the FORALL semantics was a > bad choice, but once it was in the language it is practically > impossible to remove it, so we are stuck with it in the language > forever. > > BTW, when FORALL was added, I thought it was what we all wanted. I > did not recognize that such a seemingly minor difference between > what we really wanted and what we got would have such major > consequences. As a result, I tend to avoid FORALL for all but > trivial statements. If a loop is important to performance, I tend > to use old fashioned DO loops, or a mixture of DO loops and simple > array syntax. Even if a FORALL behaves well on one compiler, you > can't rely on it working well on the next one. > > $.02 -Ron Shepard- Hide quoted text - > > - Show quoted text - Is the DO CONCURRENT of Fortran 2008 what you want? Regards, Mike Metcalf |