Add realtimer_ preprocessor variable

[tueda]

Adding realtimer_, similar to timer_ but in the real time, would be nice. What I suppose for an applications is to compute form units using the real time, without external scripting. For other cases, e.g., normal statistics, one can use on finalstats, on wtimestats or #printtimes.

It would be a 1-3 days work, which has a less priority than other many things.

• Add a new preprocessor variable at the startup.
• Implement the variable in the preprocessor.
• [parform] Broadcast the value on the master to the slaves, just in case. (Or already implemented in a timer routine?)
• What happens for .clear and checkpoints?
• Fix the build script (where no APPLE32 or APPLE64, as it shouldn't) for timers on Apple (which I don't know the problem and I can't test). See f06a641f3a3629525125cb420a2885a64fa8522a.
• Write documents for the variable and #reset.

(Perhaps writing an external script is easier.)

[tueda]

@vermaseren So, what was the timing bug for Apple? Was it some missing POSIX feature that we should check in the configure script?

[vermaseren]

The Apple problem is that I could not get the CPU time for each of the threads individually. It would only give me the sum time of all threads together.

Jos

On 16 jun. 2017, at 15:31, Takahiro Ueda notifications@github.com wrote:

@vermaseren https://github.com/vermaseren So, what was the timing bug for Apple? Was it some missing POSIX feature that we should check in the configure script?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/173#issuecomment-309026775, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEuvgxvYttihYmiRo2L4_0E0Uovvxks5sEoOUgaJpZM4MeB9e.

[tueda]

Was it fixed? Or still you get a wrong timing? Because

#if ( defined(APPLE64) || defined(APPLE32) )
        mastertime = AM.SumTime + TimeCPU(1);
        return(mastertime);
#else

doesn't make sense to me for the total CPU time.

[vermaseren]

I never found a solution. Maybe there exists one by now, but I have to admit that I did not look during the past two years.

Jos

On 16 jun. 2017, at 16:31, Takahiro Ueda notifications@github.com wrote:

Was it fixed? Or still you get a wrong timing? Because

if ( defined(APPLE64) || defined(APPLE32) )

  mastertime = AM.SumTime + TimeCPU(1);
  return(mastertime);

else

doesn't make sense to me for the total CPU time.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/173#issuecomment-309041555, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEsTwZU1ZSgxbSCFC1-wO6PiiJwsEks5sEpHEgaJpZM4MeB9e.

[tueda]

Well, I thought you solved it because you wrote "Repaired a timing bug for Apple" last year f06a641f3a3629525125cb420a2885a64fa8522a.

[vermaseren]

That was not the one. If my memory serves me right it had more to do with the representation of the final output.

Jos

On 16 jun. 2017, at 16:42, Takahiro Ueda notifications@github.com wrote:

Well, I thought you solved it because you wrote "Repaired a timing bug for Apple" last year.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/173#issuecomment-309044729, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEmHZvYZYGlaVdDZAXKGl4YXb2u8vks5sEpRvgaJpZM4MeB9e.

[tueda]

Maybe https://stackoverflow.com/a/25843585 would work?