Hallucinatory run times

Hallucinatory run times

I am finding that the runtime on a code can vary between two "fixed" values. It does a fair anount of computations and it invovles a lot of allcoatable arrays, some designated as volatile.
The runtime can change by as much as 30% (e.g. 1hr vs 40 min)

1. It can change from one "speed" to the next if I recompile with a most insigngficant change in the code yet it is unpredictable.i.e. undoing the change does not give the old runtime back.

2.Once it changes "speed", it tends to stay that way until the next time it decides to change.

3. ONLY once I observed that it changed runtime after a cold restart without a recompile. This could have been a fluke(?).

4. The only unusual aspects to the code are:
(a) it is a comserver called by vba and (b) it in turn calls another dll which happens to contain several allocatables with the volatile attribute.

Has anyone encountered this this situation before?
Is there a way to dig deeper into the cause of such behaviors.

Thanks in advance,
Tim H

3 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

Yes, I have seen this happen. In fact on my 21164 I have seen runtimes vary by as much as a factor of 3 in this way. There is even a thread, "cache/memory effect ?" going on in comp.lang.fortran about effects like this. Knowing the cause may not be of much help in finding a solution, because it is mostly a hardware and OS issue. One way to try to change the runtime is to start some kind of memory hog application like Word or Excel before running the program; when the program is run it will then most likely be issued different pages of memory than last time and this will often change the execution speed. What tends to make this happen is when you have a level of cache that is a physical cache and the set associativity of that level of cache is less than the number of pages mapped by that level, and your code, by chance or design, wants to come quite close to completely filling up that level of cache with its working set. Other stuff is possible in your case, of course: vba may not agree with CVF on how to set up alignment of double precision variables and you may be getting some variables aligned randomly as a consequence (I don't see a runtime check for this in CVF settings, but you could print out %LOC of some double precision variables and see if they're 0 mod 8) and I had another candidate that slips my mind just now.

Thanks for the info,
I will look up this thread. The whole thing seems preposterous: MS at its best.

I can also contribute the tidbit that increasing the committed stack size will not help either.

TimH

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen