This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR 53456 More CPU timing fallbacks
On Thu, May 24, 2012 at 5:37 PM, Tobias Burnus <burnus@net-b.de> wrote:
> On 05/23/2012 10:43 PM, Janne Blomqvist wrote:
>>
>> the attached patch allows the use of clock_gettime() with
>> CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID if the target
>> doesn't have getrusage() or times().
>
>
> It's not completely clear to me whether CLOCK_PROCESS_CPUTIME_ID or even
> CLOCK_THREAD_CPUTIME_ID are always better than "clock()".
AFAICS, CLOCK_PROCESS_CPUTIME_ID should roughly measure the same thing
as clock(), except with higher resolution and no wraparound issues. So
yes, I think it's always better.
Better than CLOCK_THREAD_CPUTIME_ID, maybe not, since that measures a
slightly different thing. But, I'm counting on vxworks being the only
target without getrusage(), times(), or CLOCK_PROCESS_CPUTIME_ID, and
a clock() which always returns error. Hence I put the clock_gettime
block ahead of the clock() block. If a target turns up where this
logic breaks down we can revisit it then IMHO, rather than worrying
prematurely about it.
> In case of VxWorks
> the answer is probably yes as its clock() returns -1 (no per-process clock
> exists), though unless there is a thread, the patch won't change the result
> of -1.
My understanding of the docs was that it would return the CPU usage of
the calling thread; with a process always having >= 1 thread(s). So it
"should" work, although for a multithreaded program the result would
be different compared to the other methods in gf_cputime which all
measure per-process CPU usage.
> I was wondering whether "call cpu_time()" alias clock_gettime with
> CLOCK_MONOTONIC would be better. (Returns time since startup in case of
> VxWorks, but could be also something else like time since the epoch.)
Hmm, for system_clock our first choice is clock_gettime with
CLOCK_MONOTONIC (see gf_gettime_mono in system_clock.c) yes, but I
don't see how that would be appropriate for cpu_time.
> OK for the trunk.
Thanks, committed as r187846.
--
Janne Blomqvist