timing codes

[szaghi]

@milancurcic

Hi Milan,

I searched into doc and past issues, but I was not able to find an answer.

Is it possible to use datetime as a tic toc instrumenting-library to profile Fortran codes?

I mean, is it possible to use datetime class to (accurately) measure the time taken from blocks of code?

I am almost sure to have already asked this, but my memory is going to have many IO errors these days...

Cheers.

[milancurcic]

Hi Stefano,

You can use datetime for profiling code but I don't see much benefit from using that over cpu_time. For example elapsed time:

call cpu_time(t1)
! code block to time
call cpu_time(t2)
write(*,*)'elapsed:',t1-t0,'seconds'

Alternatively, with datetime you could do:

type(datetime) :: d1,d2
type(timedelta) :: td
d1 = d1 % now()
! code block to time
d2 = d2 % now()
td = d2-d1
write(*,*)'elapsed:',td % total_seconds(),'seconds'

however the latter is more verbose and less accurate because it includes the overhead from now and - operator invocations.

I see datetime could be more useful for profiling compared to cpu_time in situations where you would do more complex profiling with time accumulators for various code blocks, in that case the timing code would be easier to implement and keep track of compared to cpu_time boilerplates.

[zbeekman]

Shameless plug: may I recommend TAU Commander for your profiling needs.

[szaghi]

@milancurcic @zbeekman

Hi Milan (it is always strange to use your first name.... it seems I am talking to one of our main soccer team, Milan is one of the team of the city Milano :smile: ), thank you for insight.

I was searching for a very simple tic-toc timer that automatically store all couple of tic-toc and print the statistics registered. I am using system_clock over cpu_time, it being more easy (and probably robust if the timed snippet is multi-thread), but what I was searching for is more the automatic registering of t2-t1...I am bored to adapt the such a timer for the current case. Anyhow thank you very much!

Hi Zaak (there is not a soccer team with your name in Italy...), you are absolutely right. In the past, for bigger CFD codes I used similar tools (mainly Totalview on IBM, VTUNE on my workstation and or gprof), but for very simple case this is somehow an overkill: I often want just a raw (but with a minimum of accuracy) estimation of the overhead between different approaches. I like the idea to have a minimal footprint solution in Fortran. For such toy applications TAU seems to be too much (to configure, to learn, to use, to analyze). The pseudo code of Milan is almost what I am searching for such a scenario, Consider this like the zero-th step of a real profiling: if I need a more in depth view then I'll go with TAU & Co, Anyhow, thank you very much too!

Cheers.

[milancurcic]

@zbeekman A dedicated profiling tool is of course preferred for diagnosing performance and identifying bottlenecks. There are some situations when using a profiler is not desirable and Stefano described one of them. Another situation that comes to mind when implementing your own timing and clocks is in daemons, or programs that run persistently and interact with the filesystem or the network. Sometimes the program has to wait for data to come from an external server, and make decisions based on how long it took. I found datetime very useful with these kinds of tasks.

[zbeekman]

@milancurcic sure, I certainly was not trying to question the utility of datetime. It sounded as though Stefano was trying to do some profiling which is why I suggested TAU Commander. I often have chaining PBS scripts that time the execution of the last job and then submit the next one based on the wall time that the previous job took, to get more accurate wall time estimates, and higher priority in the queue. (Typically there is a weighting like requested-time/time-in-queue so if your requested time is more accurate, this weighting becomes larger faster.)

@szaghi yes it might be overkill. Please note, however, that TAU Commander is more user friendly than TAU and that some other tools (like gprof) may give less accurate results because of instrumentation overhead. TAU has good automatic throttling and lets you setup selective instrumentation files so that you only time the slow/important routines resulting in low overhead. (less than 0.01% typically, if you configure the selective instrumentation correctly)

Another useful feature is the ability to collect hardware counter information via integration with PAPI. This will give insight into whether the code is memory bound or compute bound, whether the compiler is successfully vectorizing, etc.

Any way, good luck with your profiling needs Stefano!

[szaghi]

@zbeekman

Thank you for your insight! The queue trick is very nice, stolen! The next time Cineca will give me a grant I'll climb their queue as spiderman!

Interesting the TAU Commander features (I am almost sure that you had already tried to teach it to me, sorry for my bugged memory). When (if) I'll pass this period of exams/tests I'll try to study it. For now, I have very poor profiling needs (but soon with FOODIE used in a real code the game could change). All depend on how the exams will be...

Thank you again!

Cheers.