How to measure the net time spent in a program?
in [Fortran]
|
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: Richard Maine on 10 Mar 2010 16:37 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > (snip) > > > 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. > > In testing with gfortran/Scientific Linux, it seems that the increment > of CPU_TIME is 4ms. That is a little better than the timing for some > olympic ski events, but I wouldn't call it "precisely measured" > for computer time. So have you submitted a bug report as I suggest above? Or are you trying to say that this somehow contradicts what I said? -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: JB on 10 Mar 2010 16:43 On 2010-03-10, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > (snip) > >> 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. > > In testing with gfortran/Scientific Linux, it seems that the increment > of CPU_TIME is 4ms. That is a little better than the timing for some > olympic ski events, but I wouldn't call it "precisely measured" > for computer time. Yes, because Linux doesn't provide process CPU time accounting at any higher granularity than that [*], so there is nothing gfortran can do about it. For the curious, gfortran's implementation of CPU_TIME uses the getrusage() syscall. [*] Well, it seems to depend on the frequency of the OS timer interrupt. Most desktop Linux systems these days seem to have 1000 Hz, giving 1 ms, 250 Hz (4ms) and 100 Hz (10ms) are common on servers. -- JB
From: glen herrmannsfeldt on 10 Mar 2010 18:08 Richard Maine <nospam(a)see.signature> wrote: > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >> Even worse, CPU_TIME returns a REAL, so about 24 bits on most systems. >> I don't see anything about different KINDs, but maybe. > No "maybe" about it. You are right that it doesn't say anything about > kinds. But that means exactly the opposite of what you seem to think. > That means it is required to work with all real kinds rather than that > it is restricted to one of them. > That's the way that *ALL* the intrinsics are described. Were you under > the impression that TAN, for one example, only supported singleprecision > because it says nothing about kinds? Maybe it is related to it being a subroutine instead of function. Somehow it doesn't seem so strange for a function to return a different type depending on its argument, but it isn't so obvious for a subroutine. -- glen
From: Richard Maine on 10 Mar 2010 18:37
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > > >> Even worse, CPU_TIME returns a REAL, so about 24 bits on most systems. > >> I don't see anything about different KINDs, but maybe. > > > No "maybe" about it. You are right that it doesn't say anything about > > kinds. But that means exactly the opposite of what you seem to think. > > That means it is required to work with all real kinds rather than that > > it is restricted to one of them. > > > That's the way that *ALL* the intrinsics are described. Were you under > > the impression that TAN, for one example, only supported singleprecision > > because it says nothing about kinds? > > Maybe it is related to it being a subroutine instead of function. > Somehow it doesn't seem so strange for a function to return a > different type depending on its argument, but it isn't so obvious > for a subroutine. Obvious to you or not, that is what the specification says. It says it in exactly the same way for functions and subroutines. Any distinction you might be imagining is not one from the standard. The standard *DOES* require that cpu_time work for all kinds of real. There is no "maybe". I can't answer as to why they might seem different to you; the subroutine case seems the simpler one to me. It has no deduction of what the return kind must be based on the arguments (with cmplx being a notable mess in that regard). It just has the arguments, which are what they are; no extra deduction is needed. Your allusion to deducing the return kind (well, you say "type", but you apparently mean kind) skips over the first fundamental part to jump into complications. The fundamental part is not that the return kind can depend on that of the argument(s), but rather that multiple kinds are allowed for the argument(s) in the first place. That is no different for subroutines or functions. Of course, like pretty much everything else in the standard, it doesn't specify that the result has to be of any particular quality. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |