code speed moving from fortran 77 compiler to f2003 compiler
in [Fortran]
|
From: Lynn McGuire on 15 Jun 2010 18:15 > OTOH, if that memory allocation is at a higher level and you simply pass arrays and look within the subroutines that have those > arrays as dummy arguments, then you may see some benefits of more modern optimization techniques as well as taking better advantage > of current hardware capabilities. Yes, it is. The f77 code never sees the actual memory pointer from malloc or realloc, the f77 code gets an offset pointer to an array in a common block. That offset pointer can be positive or negative ! > We've had the generic discussion multiple times in the past but I've never actually seen any of the code to look at specifically. I'm always willing to show parts of the code but I have no idea what would help. Our main nonlinear solver (we have several in the app), is over 1,000 subroutines and around 200,000 lines of code. It is very difficult to understand the code as the main subroutine is 5000+ lines itself and very featured (complicated). > I'd again reiterate that the only way you'll be able to know for sure will be to take some representative portions of the code that > are able to be compiled and run w/ the two and compare the results empirically. As I mentioned in openwatcom.users.fortran, we are adding a cache to one of nonlinear solvers. This particular function is at the heart of our app with hundreds of thousands of calls to it in a large flowsheet. Thanks, Lynn
From: robin on 15 Jun 2010 21:01 Lynn McGuire wrote in message ... >>> I have tried to port the code to IVF in the past but have run >>> into trouble with the zero initialization code in IVF. >> >> Doesn't "-zero" work? I do not know the code, but some code also needs >> -save. > >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.
From: Lynn McGuire on 16 Jun 2010 11:39 >> 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
From: e p chandler on 16 Jun 2010 13:32 On Jun 16, 11: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 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 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. --- e
From: mecej4 on 16 Jun 2010 13:36
e p chandler wrote: > On Jun 16, 11: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 > > 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 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. > > --- e Let's hope that you and I don't inherit the pleasure of bailing it out :) ! If, if fact, the conjecture that less than 100 variables need saving is near the mark, it is not a monumental task -- non-trivial, perhaps, but not monumental. -- mecej4 |