code speed moving from fortran 77 compiler to f2003 compiler
in [Fortran]
|
From: e p chandler on 16 Jun 2010 19:26 "GaryScott" <garylscott(a)sbcglobal.net> wrote in message news:9f8b26e5-52ba-4a15-ae54-4b22abd95522(a)q29g2000vba.googlegroups.com... On Jun 16, 10:39 am, Lynn McGuire <l...(a)winsim.com> wrote: > >> It does but only mostly. I cannot remember at this time but > >> some variables (maybe arrays ?) were not initialized to zero > >> and that killed my app. > > > What killed your app was uninitialized variables, > > which is a programming error. > > The remedy is, of course, to initilaiize them. > > Uh yes, sure. All 300,000 of them. While differentiating > the ones that need to maintain their values between subroutine > calls. > > It is not a trivial task. That is why the save and zero init > work so well for us. And, I suspect that the number of variables > that need their values saved between subroutine calls are actually > less than 100. > > Thanks, > Lynn ? Initializing with a data statement only initializes them once, first time the procedure is called, not upon every entry. I think the behavior Lynn is depending on is having the variables initialized to zero once, then having them saved there after.
From: Richard Maine on 16 Jun 2010 19:55 e p chandler <epc8(a)juno.com> wrote: > I think the behavior Lynn is depending on is having the variables > initialized to zero once, then having them saved there after. Her situation sounds like a nightmare to me. From prior posts, I think I recall that it wasn't even affirmatively known what was going on. If it were known, then it would seem much more straightforward to fix. Rather, I recall that things failed when the magic compiler switches (notably save and zero-init kinds of switches) were not used, or even on some compilers where those switches were used. I don't consider that affirmative knowledge of what is going on, but instead deduction from observed program behavior, along with speculation to correlate the failures with the details of how different compilers implement the magic switches. I'd worry (a *LOT*) that this implies portions of the code are just being used as a "black box" without actually having a detailed understanding and documentation of exactly what the code is doing. It seems to me that a detailed understanding/documentation would inherently include information about what program state was initialized/saved. That's sure part of what I'd consider critical documentation of any code I wrote. I'd hate for my job to depend on such a "black box." Since my work products could cause airplane crashes and kill test pilots if sufficiently badly messed up (and not otherwise caught - fortunately, there was lots of checking involved), I'd have even more hated for my work products to depend on something that wasn't documented better than it sounds. I suppose it probably isn't as bad as the impression I sometimes get from the postings. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Gary L. Scott on 16 Jun 2010 21:29 On 6/16/2010 6:26 PM, e p chandler wrote: > > "GaryScott" <garylscott(a)sbcglobal.net> wrote in message > news:9f8b26e5-52ba-4a15-ae54-4b22abd95522(a)q29g2000vba.googlegroups.com... > On Jun 16, 10:39 am, Lynn McGuire <l...(a)winsim.com> wrote: >> >> It does but only mostly. I cannot remember at this time but >> >> some variables (maybe arrays ?) were not initialized to zero >> >> and that killed my app. >> >> > What killed your app was uninitialized variables, >> > which is a programming error. >> > The remedy is, of course, to initilaiize them. >> >> Uh yes, sure. All 300,000 of them. While differentiating >> the ones that need to maintain their values between subroutine >> calls. >> >> It is not a trivial task. That is why the save and zero init >> work so well for us. And, I suspect that the number of variables >> that need their values saved between subroutine calls are actually >> less than 100. >> >> Thanks, >> Lynn > > ? Initializing with a data statement only initializes them once, first > time the procedure is called, not upon every entry. > > I think the behavior Lynn is depending on is having the variables > initialized to zero once, then having them saved there after. > Exactly, so a data statement coupled with a global save seems to do exactly what is required. >
From: Ron Shepard on 16 Jun 2010 21:55 In article <hvb6sf$onc$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > > It would be a nice feature to have in at least one compiler. > Another possibility would be a source to source translator > that would take Fortran source as input and generate Fortran > source with the appropriate checks as output. In this case, > it would have to initialize all variables to some rare value, > and then IF statements before every access to check for that > value. Not easy, but not so hard, either. Some compilers have options that allow memory to be set by default to particular values. A particularly useful value on IEEE machines would be signaling NAN. These values produce errors the first time they are used, allowing the uninitialized values (in fortran) to be identified. $.02 -Ron Shepard
From: Lynn McGuire on 17 Jun 2010 11:21
> > Initializing with a data statement only initializes them once, first > > time the procedure is called, not upon every entry. > > I think the behavior Lynn is depending on is having the variables initialized > to zero once, then having them saved there after. Very true. That is the behavior that our code relies on now. When I come up for air in our current tasks, I am going to turn off the zero init and the automatic save in the open watcom f77 compiler and see what happens. Thanks, Lynn McGuire |