code speed moving from fortran 77 compiler to f2003 compiler
in [Fortran]
|
From: glen herrmannsfeldt on 16 Jun 2010 14:53 Lynn McGuire <lmc(a)winsim.com> wrote: (snip, someone wrote) >> 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. I do wonder how hard it would be to write a program to read the source, and then insert the appropriate DATA statements to zero and SAVE all such variables. Somewhat easier for variables that already have a declaration. > 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. -- glen
From: glen herrmannsfeldt on 16 Jun 2010 14:58 e p chandler <epc8(a)juno.com> wrote: (snip) > Is there some practical way to run individual routines though a > checkout compiler so that you can at least find those variables that > are NOT initialized? > IIRC Watfor had this capability. I don't know about Open Watcom. I once ran a few thousand line program through WATFIV to find uninitialized variables. Compared to Fortran H it compiled about ten times faster, and ran about ten times slower. > I realize that this is a monumental task, but it's sort of like the > national debt. It just keeps getting bigger, it's too large to fail, > and eventually it will have to be dealt with. 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. -- glen
From: dpb on 16 Jun 2010 16:20 glen herrmannsfeldt wrote: > e p chandler <epc8(a)juno.com> wrote: > (snip) > >> Is there some practical way to run individual routines though a >> checkout compiler so that you can at least find those variables that >> are NOT initialized? > >> IIRC Watfor had this capability. I don't know about Open Watcom. > > I once ran a few thousand line program through WATFIV to find > uninitialized variables. Compared to Fortran H it compiled about > ten times faster, and ran about ten times slower. > >> I realize that this is a monumental task, but it's sort of like the >> national debt. It just keeps getting bigger, it's too large to fail, >> and eventually it will have to be dealt with. > > 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. While I've not tested them, specifically, the Polyhedron comparison chart of features says NAG and Silverfrost (nee Salford) both do both static and runtime initialization checks for almost, if not quite all. I've suggested to Lynn in the OW forum the investment in another compiler that has such facilities would likely pay a significant ROI. --
From: Lynn McGuire on 16 Jun 2010 17:11 >> Uh yes, sure. All 300,000 of them. While differentiating >> the ones that need to maintain their values between subroutine >> calls. > > I do wonder how hard it would be to write a program to read > the source, and then insert the appropriate DATA statements > to zero and SAVE all such variables. Somewhat easier for > variables that already have a declaration. I have no idea which are the 100 of the 300,000 variables that we need to save between the subroutine calls. That is the tough part. Otherwise the init to zero data statements are a simple perl script. The determination of the 100 (or 1000, I really have no idea) will require removal of the global save command and then massive testing ... and then determination of what went wrong in some weird part of one of our nonlinear solvers. Some very tough work ! Thanks, Lynn
From: GaryScott on 16 Jun 2010 18:03
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. |