From: Dave Allured on
Gordon Sande wrote:
>
> On 2010-03-09 15:13:48 -0400, Arjan <arjan.van.dijk(a)rivm.nl> said:
>
> > Until now I monitor the performance of my application by measuring the
> > real time spent by my program and subtract the value from the former
> > iteration from the latest estimate. This gives me the number of
> > seconds per iteration of my process. I have only 1 CPU, so the
> > available time is distributed over all processes. My current
> > application uses a lot of CPU and produces only a tiny bit of output,
> > so I/O-time is not restrictive. How can I measure the net cpu-time
> > spent by my program per iteration of my calculation, i.e. corrected
> > for the fraction of CPU assigned to the process?
> >
> > A.
>
> Isn't "cpu_time" intended to give your the cpu time for your process?
> This assumes that the system is capable of keeping track of the time used
> by each process. Noted as new so must be F95.
>
> Real time is usually understood to be wall clock as given by "date_and_time".
> There is also "system_clock" which gives the processor clock in processor units
> but is still a real time clock. Both part of F90.

My reading of the F95 standard for cpu_time is (1) it probably returns
values related to real time, i.e. wall clock; and (2) the definition is
so vague that you can't be sure what is really being measured. Arjan is
seeking a measure of process time, not elapsed time or real time; so
cpu_time is not adequate, especially on a busy computer. By "process
time" I mean processor time spent in the user's actual code, not in
unrelated code on a multiprocessing system. This is a very reasonable
request.

You might look at the nonstandard etime function in gfortran. It
advertizes to return time in two components, "user time" and "system
time", neither term defined. If you are lucky then "user time" may have
some relationship to process time on your system.

http://gcc.gnu.org/onlinedocs/gfortran/ETIME.html

Apparently other compilers also have etime, but with varying definitions
of what is being measured. For more on this topic, including some
ranting about the vagueness of cpu_time, see this:

http://www.megasolutions.net/fortran/How-to-measure-the-time-a-subroutine-takes_-49933.aspx

--Dave
From: glen herrmannsfeldt on
Dave Allured <nospom(a)nospom.com> wrote:
(snip)

> My reading of the F95 standard for cpu_time is (1) it probably returns
> values related to real time, i.e. wall clock; and (2) the definition is
> so vague that you can't be sure what is really being measured. Arjan is
> seeking a measure of process time, not elapsed time or real time; so
> cpu_time is not adequate, especially on a busy computer. By "process
> time" I mean processor time spent in the user's actual code, not in
> unrelated code on a multiprocessing system. This is a very reasonable
> request.

> You might look at the nonstandard etime function in gfortran. It
> advertizes to return time in two components, "user time" and "system
> time", neither term defined. If you are lucky then "user time" may have
> some relationship to process time on your system.

Unix based systems keep track of "user time" and "system time," as
well as I know it "user time" is execution of your code, "system time"
is system code processing your requests.

I first understood this running metafont on a Sun 4/110. The early
SPARC processors didn't have a MULTIPLY instruction, but instead
instructions that could be combined to generate a product.
It seems that SunOS did multiply through a system call, such that
it counted as "system time." Normally it should be mostly I/O
related CPU usage. I believe it doesn't count time (even CPU time)
spent swapping virtual storage around, but I am not sure about that.

I usually just add user and system time together.

-- glen
From: Richard Maine on
Dave Allured <nospom(a)nospom.com> wrote:

> My reading of the F95 standard for cpu_time is (1) it probably returns
> values related to real time, i.e. wall clock;

I'm not sure why you would think that. The name sort of gives a strong
hint that it is about CPU time. The standard uses the term "processor
time", which is about as close as one can come to CPU time, as CPU isn't
a term defined in the Fortran standard. The note in the standard
specifically says that it might have 'no obvious connection to elapsed
"wall clock" time.'

I can assure you that the intent is that it be more like a CPU time than
a wall clock time. Thus the name and the note partly quoted above. While
there are uncertainties about intent of some language features, that
isn't one of them. I was there and I'm quite sure there was no
suggestion that wall clock time was what was desired. There was the
posisbility that wall clock time might be as good as you could do, and
thus viable as a last resort, but that certainly isn't supposed to be
the first resort. No, the standard doens't demand that a vendo do a good
job. Call it a quality of implementation thing.

> and (2) the definition is
> so vague that you can't be sure what is really being measured.

That part is intentional, as described in the note. Basically, it is
hard to precisely define the concept of CPU time in a
hardware-independent way. That is just well outside the bounds of the
Fortran standard.

Plus, even to the extent one can define it, some processors might not
have a handy way to measure CPU time.

But if there is a well defined concept and way to measure CPU time, then
the intrinsic ought to use it. If it doesn't, submit a bug report.

> You might look at the nonstandard etime function in gfortran.

I repeat my recommendation to use the facilities defined in the
standard. If CPU time can be precisely defined and measured on a system,
and the vendor's implementation of the CPU_TIME intrinsic doesn't get
it, then I suggest submitting a bug report to the vendor. If you can get
something adequate in some other way, then there is no reason the
compiler vendor couldn't do the same.

> Apparently other compilers also have etime, but with varying definitions
> of what is being measured.

So you get no guarantees with etime either, and it is not available at
all on some compilers. Back to my prior post, I'll claim that

"I head somewhere that some implementations of CPU_TIME might not do
what I want, so I'll use the nonstandard etime, which also might not do
what I want and which isn't available at all in some places"

doesn't fit my criterion for a good specific reason not to use CPU_TIME.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: aerogeek on
On Mar 10, 11:00 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu>
wrote:
> Dave Allured <nos...(a)nospom.com> wrote:
>
> (snip)
>
> > My reading of the F95 standard for cpu_time is (1) it probably returns
> > values related to real time, i.e. wall clock; and (2) the definition is
> > so vague that you can't be sure what is really being measured.  Arjan is
> > seeking a measure of process time, not elapsed time or real time; so
> > cpu_time is not adequate, especially on a busy computer.  By "process
> > time" I mean processor time spent in the user's actual code, not in
> > unrelated code on a multiprocessing system.  This is a very reasonable
> > request.
> > You might look at the nonstandard etime function in gfortran.  It
> > advertizes to return time in two components, "user time" and "system
> > time", neither term defined.  If you are lucky then "user time" may have
> > some relationship to process time on your system.
>
> Unix based systems keep track of "user time" and "system time," as
> well as I know it "user time" is execution of your code, "system time"
> is system code processing your requests.
>
> I first understood this running metafont on a Sun 4/110.  The early
> SPARC processors didn't have a MULTIPLY instruction, but instead
> instructions that could be combined to generate a product.  
> It seems that SunOS did multiply through a system call, such that
> it counted as "system time."  Normally it should be mostly I/O
> related CPU usage.   I believe it doesn't count time (even CPU time)
> spent swapping virtual storage around, but I am not sure about that.
>
> I usually just add user and system time together.
>
> -- glen

In my previous assignment, in windows environment, i used Vtune
Performace Analyzer by intel extensibly to identify hotspots in my
fortran application. That time it was also available as evaluation
version.

From: Tim Prince on
On 3/9/2010 11:32 AM, Gordon Sande wrote:

> Real time is usually understood to be wall clock as given by
> "date_and_time".
> There is also "system_clock" which gives the processor clock in
> processor units
> but is still a real time clock. Both part of F90.
>
>
system_clock became more useful when certain compilers implemented the
f2003 requirement to support larger than default integers, and took
advantage of it to return full system clock resolution (typically
microseconds) without incurring early wrap-around to negative numbers.
I believe gfortran made this change in recent 4.5 updates.

--
Tim Prince