CPU_TIME() is intended to measure the time spent by the CPU on the process
being timed, as opposed to SYSTEM_CLOCK() or DATE_AND_TIME() which clearly
are intended to give elapsed real time. In many cases, the distinction
blurs, as the resolution of process time is quite poor on many systems,
varying from 0.010 to 1.00 seconds on linux and Windows. SYSTEM_CLOCK() is
difficult to use in any portable manner where the default integer is 32 bits
and thus overflows frequently if it has satisfactory resolution, so
approximations to CPU_TIME() which measure elapsed real time may be useful.
Yes, it is confusing to talk about elapsed processor time.
----- Original Message -----
From: <[log in to unmask]>
To: <[log in to unmask]>
Cc: <[log in to unmask]>
Sent: Tuesday, October 24, 2000 12:32 PM
Subject: Re: Timing subroutines
> Craig,
>
> I have to disagree with some of your definitions as I use the terms -- I
do not
> know how they are defined in the standard, except that they are allowed
not to
> be defined :-)
>
> > The best standard procedure for this purpose is the Fortran **95**
> >subroutine
> >CPU_TIME. It takes a single real argument, which is the elapsed
processor time
> >in
> >seconds. The exact definition of the processor time is left imprecise.
If you
> >want to time a procedure, you need to call CPU_TIME twice, with two
separate
> >actual
> >arguments.
>
> (My mail has re-formatted, I've just added a chevron to each line.)
>
> The terms "elapsed" and "processor" time to me are different. Elapsed is
> wall-clock, and includes all the overheads that a user experiences.
Processor
> time is (if returned by the OS) a measure of the CPU and is what I use for
> comparing timing of algorithms. The former is irrelevant for determining
CPU
> intensive algorithms; it is also biased by how many users are active on
the
> system.
>
> > Other alternatives include the F90 SYSTEM_CLOCK subroutine and the
> >DATE_AND_TIME subroutine. If you want to time sections of code, you will
again
> >need to call either of these subroutines twice, with separate sets of
arguments
> >for
> >the beginning and the end.
>
> These all give (what I term) elapsed time. Not a true analysis of the
merits of
> different algorithms -- unless on a single user system with no other
processes
> running.
>
> > There is no standard way in F9x to start a timer at one point and
then read
> >that timer later on. You will need to create your own timer using one of
the
> >subroutines I mentioned above.
>
> I dunno :-) :-)
>
> :-) Assuming CPU_TIME returns meaningful results (else use elapsed time),
I
> would have thought the following code is standard -- but not a one-liner:
>
> CALL CPU_TIME(T1)
> CALL ROUTINE_TO_MEASURE
> CALL CPU_TIME(T2)
> WRITE(*,*) 'Time taken ' , T2-T1
> :-)
>
> Hmmm, I'm not a UNIX person ( -- VMS), does the time command measure CPU
time or
> wall-clock time? If the latter, it is **not** a good measurement of
relative
> algorithms on a multi-user system. Using elapsed time, I can see
situations
> where bubblesort could beat quicksort. {On a multi-user system heavily
loaded,
> a batch process running quicksort on a low priority could take longer
wall-clock
> than an interactive bubblesort on a higher prority -- I frequently see
similar
> situations on my production machine.]
>
>
> >varadharajan wrote:
> >
> >> Hello!
> >> I wanted to know if there is some F90 command to time subroutines and
> >> functions withing programs. Whole programs can be timed by the time
> >> command in unix but what about subroutines within? Is there such a
> >> facility?
> >>
> >> Regards,
> >> Varadharajan S
>
> Regards, Paddy
>
> Paddy O'Brien,
> Transmission Development,
> TransGrid,
> PO Box A1000, Sydney South,
> NSW 2000, Australia
>
> Tel: +61 2 9284-3063
> Fax: +61 2 9284-3050
> Email: [log in to unmask]
>
> Either "\'" or "\s" (to escape the apostrophe) seems to work for most
people,
> but that little whizz-bang apostrophe gives me little spam.
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
