View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Mon Oct 08, 2018 10:17 am Post subject: Re: |
|
|
John-Silver wrote: | ... you could use the well written and continuously updated program flowchart to understand the code just like we all do ! LOL |
Flow diagrams? They are fine for teaching purposes and for explaining a compact algorithm, but I find them useless for the kind of programs that we are discussing. Here is a link to a machine-generated flow diagram for CDFCOR (upper portions removed):
https://www.dropbox.com/s/ap428qqoaanq8ss/cdfcor.png?dl=0
What would you do with it? It is as useful for navigation as this view of a road junction:
https://goo.gl/images/qEeGt9 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Thu Nov 08, 2018 10:56 am Post subject: |
|
|
I have had a look at the original issue and program posted by mecej4 on this thread but I have not been able to form a clear conclusion as to why the latest releases are much faster. I do recall that there was something wrong with the pointer checking for ALLOCATE/DEALLOCATE in CHECK mode and this seems to me to be the most likely reason for the change.
The check in question relates to "dangling Fortran pointers", that is, checking that ALLOCATEd memory is not used after its DEALLOCATE. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Thu Nov 08, 2018 5:38 pm Post subject: |
|
|
Paul, I am uneasy about drawing conclusions from the timings alone. The test code does not have any of the bugs that /checkmate would have caught. Therefore, if the compiled code simply skipped doing the checks, or did only perfunctory checking, the output would still be correct and the program would just run faster.
I presume that the code for doing the checking is split between code in the user's EXE and in checking helper routines in SALFLIBC64.DLL. Therefore, if the old DLL did thorough checking whereas the new DLL did not, and most of the overhead for checking is incurred in the DLL, the speed difference could be explained.
I don't know how to dig into this question further. Do you think that test code that does have subscript overruns, uninitialised variables, etc., should be used instead? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Thu Nov 08, 2018 6:09 pm Post subject: |
|
|
I am assuming that, one way or another, the problem has been resolved.
I suggest that you check this out again when the next full release becomes available (which will be "very soon"). |
|
Back to top |
|
|
|