I am trying to summarize the results of the discussion about "ftimer.h" the Fortran header file for the Portable Timing Routines. I have to say that the response was very enthusiastic (over 25 messages in under 14 hours :). I hope the interest will continue.
There were a number of issues raised during the discussion. I will try to post some of the rationale behind some of the decisions that were made or at least my understanding of the issues. Please feel free to correct me.
My comments begin with a ">" mark.
Related to compliance with Standards/conventions...
> I think it would make all the definitions consistent. Thanks for pointing it out to me.
> I think Mr. Kesavan gave a good explaination of where each would be useful.
Here is my understanding of the situation. The NOMINAL values are supplied by the vendor. The CALIBRATED values are calculated at installation time, to account for any special configurations of the particular system. The PTR_INIT_???_TIMER routines are used to get the values at runtime. When using different machines that are binary compatible and access the same library these routines would let the user get the values for the particular machine that s/he is using. Also as pointed out in the discussion this would also be helpful in determining the values when other factors like system load are to be considered.
** An additional concern/question **
In addition there are some platforms that require initialization of the timers before they can be read. How do we handle these cases.
Here are some suggestions that Richard Frost had made (earlier). I don't think this was discussed over the reflector/mailing list.
Here's the tradeoffs I see with respect to the timer initialization problem.
1. We could require the users to call an initialization function. Some users will forget and receive anomalous results. Others will be annoyed.
2. We could request/require the vendor to initialize the timer; e.g., the pre-processor would automatically insert this call for the user.
3. We could maintain a static flag variable which determines the initialization state. The overhead of this approach has two effects: (a) the overhead of checking the flag must be subtracted -- along with the subtraction overhead -- from the timer output; and (b) the resolution of the clock will be slightly reduced, causing an increase in the indeterminancy.
4. We could request that the timer be implemented as a global function pointer. For platforms requiring initialization, the initial value of this pointer calls the algorithm described in #3 and then resets the pointer to a streamlined function.
> This is an interesting point. If we have a Nominal and Calibrated value for the Tick period, what about Nominal and Calibrated values for the rest of them.
The reason as pointed out by Mr. Kesavan for this issue is about the correctness of the values. For example, if we have a nominal rollover period it is based on the nominal tick period: rollover period = tick period * no. of ticks that can be stored in the register
So if the tick period changes the rollover period would change. Similarly if the Resolution for a particular machine may be 5 ticks, which would change with the tick period.
***** IMPORTANT *****
Should we have both nominal and calibrated values for all the quantities? Should we have either Nominal or Callibrated values for all quantities? If we have just one kind, i.e., either nominal or calibrated, how do we convey this information to the user? Another Constant maybe... CALIBRATED ???
>Here is the definition of Resolution as presented in the PTR Overview.
The minimal time unit that can be measured with confidence. It will be at least as coarse as the tick period, and probably coarser since many timers operate as step, rather than continuous functions. This value will be nominal (i.e., supplied by the vendor) indicating the number of bits that should be considered valid when calculating elapsed time.
> I don't think this has been discussed in too much detail by the group as a whole. It might be possible to initialize the variables that store the opaque values to a negative number. And if the number remains the same after the routine has executed we might be able to interpret that the value was not updated. But if the value is changed there is nothing to help us determine that the value returned is a valid one and not just garbage.
I guess it might be possible to do some error checking but it would mean additional overhead. I guess if the user really wants to be sure that the calls are working they can initialize the variable as mentioned above and test the values that are returned. I would like to point out that the value will be meaningless (because these will be register contents). Also you could have multiple calls right after one another and check the values to see if the numbers returned are increasing steadily. But other than that I can't think of any error checking for the GET_*_TIME routines.