Prev: Correct way to write a wrapper for C functions that accept/return ?strings
Next: Correct way to write a wrapper for C functions that accept/return ??strings
From: Dave Allured on 10 Mar 2010 12:17 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 10 Mar 2010 13:00 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 10 Mar 2010 13:05 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 10 Mar 2010 13:05 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 10 Mar 2010 13:19
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 |