Adding /check causes EXE to run 800 times slower

Quoted from JohnCampbell ...The most glaring slow down is at lines 2601:2605 call spot_time (24, '<conlor> set f 24') do i = 1, 3*nbb a1nbb(i) = zero end do call spot_time (43, '<conlor> zero f 24') I have calculated that each iteration of the do loop can take up to 150,000 processor cycles !!!

Thanks a lot for your investigative work!

Perhaps I should look into why this simple loop (whose purpose is to zero out an array) can take up so much time. Perhaps, /check causes the allocation status to be checked during every iteration of the DO loop.

/timing is a very effective FTN95 option for detecting slow performance, as it identifies the routines that have long run times and that call other routines. It requires no change to the code; only to the compile options. My approach is to first use /timing on everything, then identify utility routines that may be called millions++ of times, these can be moved to another file that is not compiled with /timing. The first use involves no change to the code.

The use of spot_time (which is based on the RDTSC timer) is also useful for timing parts of the routine. It requires only a set of suitable calls to be placed in the code. It reports both seconds and processor cycles, which can be a useful measure to compare to expected operations counts.

This was my first use of /64 /check /timing, so was good to see this combination has been ported to 64-bit.

(Not sure why the 10 second calibration is still required, as you can use the program run time for that. I also posted test_timer_64.f90 which demonstrates reasonable calibration can be achieved in .0001 seconds comparing RDTSC_val@ to 256 QueryPerformanceCounter 'ticks')

I hope this demonstrates a way of easily identifying where programs use the most time, so where the best gains can be made.

John

Some further thoughts...

It is beginning to look like the calls to __pcheck may not be useful for ALLOCATABLE objects, in other words (as the documentation says) it should be for POINTERs only. This being the case, there are two things that need fixing: a) FTN95 where it plants calls to __pcheck and b) the extremely poor performance of __pcheck in clearwin64.dll.

The coding for /timing was provided by a third party (not Salford Software/Silverfrost) so the motivation behind the calibration loop can only be guessed. It may be that the loop is useful because of a) other background processes that are running and b) because of the unknown effects of multiple CPU cores. So I am not sure that simple clock timing would be appropriate. Then there is always the risk that we might break something that already works quite satisfactorily.

Quoted from PaulLaidler ... there are two things that need fixing: a) FTN95 where it plants calls to __pcheck and b) the extremely poor performance of __pcheck in clearwin64.dll.

With regard to Item a): FTN95 /check is doing fine in 32-bit mode; could the same strategy be followed with /64, assuming 64-bit versions of the necessary support routines are already present in clearwin64.dll?

Thanks.

At the moment FTN95 uses the same 'frontend' code in this context, independent of whether it is 32 bits or 64 bits.

The 64 bit implementation of __pcheck can be fixed to make it perform well. For safety, the FTN95 frontend will not be changed for 32 bits but it might be changed for 64 bits if the check is considered to be redundant (it might, for example, relate to an earlier Fortran standard where automatic deallocation was not in the standard).

An ALLOCATABLE object that is referenced after deallocating is trapped in a different way (as a result of it being nullified). So it may be that this check is redundant and only needed for Fortran POINTERs.

It's one of those decisions that could go either way but since it is early days for 64 bit FTN95 it might be wiser to leave it out until we can find a context where it would be useful.

Quoted from PaulLaidler and b) because of the unknown effects of multiple CPU cores. So I am not sure that simple clock timing would be appropriate.

Paul,

I am not sure what you mean by this comment. Are you implying that /timing is thread safe ?
Or is it the uncertainty of which core is used for RDTSC ticks ? My impression is that /timing is using RDTSC ticks as an accurate elapsed time allocation and it is not thread safe. I thought /timing had two timing approaches; one worked in a similar way to my spot_time, which allocates accumulated ticks to each routine, (which would not be thread safe) and the other accumulates total time from entry to exit, accumulating clock time of other routines being called. This could be thread safe.

John

John

I can't claim to understand why the calibration loop is applied rather than a simple clock test. The coding was written by someone like you who has a better understanding than I have of these issues.

At the moment it does not seem that it warrants committing resources to researching this and making changes.

mecej4

I notice that this program does not run with /UNDEF. I am impressed with the way that SDBG64 highlights the problem. 64 bit FTN95 seems to be doing better than 32 bit FTN95 in this case.

Paul, I agree, and I look forward to the release of 8.30 Personal for that reason.

However, in the actual application (rather than the abbreviated version that I created for this post), one of the subprograms uses ENTRY, and that made it impossible for me to make much progress using /undef, because of the bug that I separately reported in https://forums.silverfrost.com/Forum/Topic/3332 .

This issue has now been fixed for the next release of clearwin64.dll.